tarasv> Главная проблема реляционок не нелинейный рост времени выполнения запросов с ростом размера данных (пишите блжад правильно!), а то что нагрузка не может быть распределена между большим количеством серверов из за основополагающих принципов лежащих в архитектуре реляционной базы.

почему не может? есть же MPP (massive parallel processing) RDBMS

Сергей-4030> Спокойный Тип говорил что greenplum обещает scalable SQL - что-то очень сложно мне представить такое. Вот когда greenplum займет хоть сколько нибудь значимую долю рынка, тогда и поговорим.

Google F1 и Spanner повех которого она работает. Не чистая реляционка по Кодду но уже гораздо лучше и с масштабированием по сравнению с чистыми реляционками и целостностью данных по сравнению с масштабируемыми NoSQL.
Но в целом CAP theorem пока никто не опроверг и прорыва не предвидится. Как обычно - выберите два из трех и про третье забудьте.

с.т.> почему не может? есть же MPP (massive parallel processing) RDBMS

Мне бы конкретные имена а то это очень расплывчате понятие. Я надеюсь это не Teradata?

Сергей-4030>> Я сказал "в среднем". Это вовсе не только поиск.
tarasv>Главная проблема реляционок не нелинейный рост времени выполнения запросов с ростом размера данных (пишите блжад правильно!), а то что нагрузка не может быть распределена между большим количеством серверов из за основополагающих принципов лежащих в архитектуре реляционной базы.

Я не вижу разницы. По-моему, я написал именно это. Not scalable. Рост нагрузок приводит к необходимости менять сервера на более производительные, вместо добавления дешевых. Впрочем, я вижу, на самом деле разницы во взглядах на проблему у нас нет. Вы, очевидно, тоже считаете, что SQL not scalable, так что я закругляюсь.

tarasv> Мне бы конкретные имена а то это очень расплывчате понятие. Я надеюсь это не Teradata?

а чем тебе терадата не нравится?
TASM вообще произведение инженерного искусства я считаю.
вот логотип зря поменяли, оранжевый мне больше нравился.

tarasv>> Мне бы конкретные имена а то это очень расплывчате понятие. Я надеюсь это не Teradata?
с.т.> а чем тебе терадата не нравится?

В контексте этой ветки тем что она скорее OLAP а не OLTP. И с эффективностью масштабирования на много серверов в разных датацентрах там, как я понимаю, все очень неплоско. Но запросто могу и ошибаться с ней работали BIщики из соседней команды.

tarasv> В контексте этой ветки тем что она скорее OLAP а не OLTP. И с эффективностью масштабирования на много серверов в разных датацентрах там, как я понимаю, все очень неплоско. Но запросто могу и ошибаться с ней работали BIщики из соседней команды.

ну я знаю в РФ инсталляции и в разных ДЦ - хотя bynet через WAN не прокинуть

ps вообще возможность масштабирование на узлы находящиеся в разных ДЦ - те которые оптикой прямой не подключить - это же вопрос, для любой технологии. так или иначе накладные расходы на репликацию данных становятся высокими.

с.т.>> почему не может? есть же MPP (massive parallel processing) RDBMS
yacc> Как правило MPP в хранилищах данных - Data Warehouse.
yacc> С OLTP несколько повеселее - это будет что-то типа Oracle RAC

ну в перспективе OLTP и DWH будут сливаться в active datawarehouse - витрины которые будут в nearrealtime рассчитываться а не раз в сутки, так что мы вполне в контексте, собственно для этого и нужно масштабирование.

с.т.> ну в перспективе OLTP и DWH будут сливаться в active datawarehouse - витрины которые будут в nearrealtime рассчитываться а не раз в сутки, так что мы вполне в контексте, собственно для этого и нужно масштабирование.

Это хорошо для BI но не решение проблем высоконагруженных систем. Да и паровоз во многом уже ушел. Методы написания приложений поверх БД без поддержки целостности отработаны и возврт назад к использованию только реляционных баз в высоконагруженных приложениях не имеет особого смысла.

tarasv> Это хорошо для BI но не решение проблем высоконагруженных систем. Да и паровоз во многом уже ушел. Методы написания приложений поверх БД без поддержки целостности отработаны и возврт назад к использованию только реляционных баз в высоконагруженных приложениях не имеет особого смысла.

у высоконагруженных систем "горячих" данных не так много, они на обычные кластеры влазят - на сегодняшний день.
а так да, нужно смотреть на задачу, если не нужны навороты - значит не нужны.
так в РФ достаточно много инсталяций терадаты и количество их увеличивается , рефреши идут, оракл с экзодатой в ту же нишу метит, большой голубой друг тоже старается.
давай посмотрим, я бы не спешил насчёт ушедшего паравоза.
вот санкции от США могут радикально всё обрушить - это да.

с.т.>> ну в перспективе OLTP и DWH будут сливаться в active datawarehouse
yacc> Что-то как-то хреново я это представляю для транзакций...

посмотрим, мир так быстро меняется...там ещё сбоку был машин лернинг который рулил всеми процессами...в общем интересные концепции

Unix> а сколько тебе лет?

Блин, вот скрыл же. Реклама. А ты берёшь и разговариваешь.

Mishka> Блин, вот скрыл же. Реклама. А ты берёшь и разговариваешь.

Oops ... извиняйте

Но таки раньше - сносили вЪ ... ну и "заблудилася я"©