Главный архитектор СУБД Tarantool покинул Mail.Ru

(1) Почему меньше, из-за реляционной структуры?

(1)NoSQL базы - это как раз СУБД которые изначально проектировались для работы с гигантскими в т.ч. распределёнными объёмами данных - а классчиеские СУБД для этого изначально не проектировались (там другие задачи в приоритете) и сейчас испытывают эволюционные трудности - в попытке притянуть возможность обработки очень больших объёмов данных. Только в среде учета задач (которые сейчас решаются на платформе 1С Предприятие или могли бы решаться в будущем) таких объёмов попросту нет (ну редкие исключения думаю всегда найти можно), т.к. это объёмы которые только начинаются от нескольких терабайт на таблицу, а так могут исчисляться и петабайтами, а в будущем и эксабайтами - условно на таблицу (хотя для NoSQL понятие таблица совсем уж условно). Но, всё-равно - к 1С прикручивают NoSQL базы для решения некоторых аналитических задач (скорее лишь потому, что возможности самой платформы по эффективному взаимодействия с современными реляционными СУБД очень ограничены, а не в силу недостаточного потенциала производительности реляционных СУБД; ну или надо просто подключаться к другим проектам, изначально которые работают не на 1С Предприятие 8)

Вообще - у NoSQL очень большой потенциал, но пока он востребован только в достаточно специфических проектах. Ну и надо не забывать - что у NoSQL есть свои слабые места - и не для всех зада он хорошо подходит. Поэтому, например, SAP HANA - высокопроизводиельная и универсальная учетная система с гибоидной интегрированной прямо в ядро СУБД - включающей как возможности работы с реляционной моделью таблиц, так и колоночную архитектуру. И это здорово. И 1С бы стоило тоже подумать о таком развитии - в будущей 1С Предприятие 9 использовать как работу с реляционной моделью (причём, например, MS SQL Server умеет строить колоночные индексы прямо поверх реляционной БД), так и более продвинутые возможности NoSQL - например сетевую архитектуру (или документную) - чтобы можно было для разных задач прямо в платформе 1С Предприятие выбирать разные виды метаданных. Но это только мечты... которые у конкурентов уже становятся реальностью

(3) Ограничения - так только по мощности сервера и объема хранилища. Но чем меньше база, тем быстрее поиск. Даже при использовании индексов все равно меньше база - будет быстрее искать.

(7) там завезли новый механизм, что-то типо "копии баз данных" или как-то так, короче репликация но встроенная в платформу. Я подробнее не копал еще.

(7)Знаете - в мире учета, далёком от 1С - это вообще-то обычная практика - когда для решения разного рода задач применяют разные СУБД, но там - чаще всего так же как в 1С - одна система не умеет универсально со всеми СУБД работать - и там применяется принцип интеграции - разного рода задачи решаются в своих отдельных учетных системах - которые между друг другом интегрируются - и в этом, то как раз, не ничего плохого. Вот, почему такая практика не прижилась для платформы 1С Предприятие - мне непонятно - тут друг с другом интегрируются в основном только сами конфигурации 1С, и намного реже - другие продукты - обычно через на коленке прикрученную к 1С шину транспорта данных - с которой эти другие продукты как раз уже из коробки умеют эффективно взаимодействовать!
Так может и 1С Платформу не стоит использовать как микроскоп, которым нужно построить дом и забить сваи! А нужно организовать лабораторию при стройке - где под микроскопом можно изучить гвоздики или структуру кирпичей, а сваи всё-таки забивать копером? То есть - для 1С Предприятия нужны более эффективные средства интеграции с известными шинами транспорта данных? По сути, тут всё можно было бы решить и внешними компонентами и кодом на языке 1С - вот только порознь - это опять будет прикручивание на коленке - нужна стандартизация... ну и гибкость в выборе нестандартных провайдеров взаимодействия - кому надо будет...