NoSQL vs SQL

Теги:SQL, NoSQL
 
1 2 3 4
US спокойный тип #12.11.2018 17:59  @tarasv#12.11.2018 17:42
+
-
edit
 

спокойный тип
Спокойный_Тип

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

почему не может? есть же MPP (massive parallel processing) RDBMS
эволюционируй или вымри  52.952.9
CA tarasv #12.11.2018 18:00  @Сергей-4030#12.11.2018 09:26
+
-
edit
 

tarasv

опытный

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

Google F1 и Spanner повех которого она работает. Не чистая реляционка по Кодду но уже гораздо лучше и с масштабированием по сравнению с чистыми реляционками и целостностью данных по сравнению с масштабируемыми NoSQL.
Но в целом CAP theorem пока никто не опроверг и прорыва не предвидится. Как обычно - выберите два из трех и про третье забудьте.
 70.0.3538.7770.0.3538.77
CA tarasv #12.11.2018 18:07  @спокойный тип#12.11.2018 17:59
+
-
edit
 

tarasv

опытный

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

Мне бы конкретные имена а то это очень расплывчате понятие. Я надеюсь это не Teradata?
 70.0.3538.7770.0.3538.77
US Сергей-4030 #12.11.2018 18:30  @tarasv#12.11.2018 17:42
+
-
edit
 

Сергей-4030

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

Я не вижу разницы. По-моему, я написал именно это. Not scalable. Рост нагрузок приводит к необходимости менять сервера на более производительные, вместо добавления дешевых. Впрочем, я вижу, на самом деле разницы во взглядах на проблему у нас нет. Вы, очевидно, тоже считаете, что SQL not scalable, так что я закругляюсь.
 70.0.3538.7770.0.3538.77
RU спокойный тип #12.11.2018 20:29  @tarasv#12.11.2018 18:07
+
-
edit
 

спокойный тип
Спокойный_Тип

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

а чем тебе терадата не нравится? :eek:
TASM вообще произведение инженерного искусства я считаю.
вот логотип зря поменяли, оранжевый мне больше нравился.
эволюционируй или вымри  63.063.0
Это сообщение редактировалось 12.11.2018 в 20:42
CA tarasv #12.11.2018 22:06  @спокойный тип#12.11.2018 20:29
+
-
edit
 

tarasv

опытный

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

В контексте этой ветки тем что она скорее OLAP а не OLTP. И с эффективностью масштабирования на много серверов в разных датацентрах там, как я понимаю, все очень неплоско. Но запросто могу и ошибаться с ней работали BIщики из соседней команды.
 70.0.3538.7770.0.3538.77
RU спокойный тип #12.11.2018 22:18  @tarasv#12.11.2018 22:06
+
-
edit
 

спокойный тип
Спокойный_Тип

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

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

ps вообще возможность масштабирование на узлы находящиеся в разных ДЦ - те которые оптикой прямой не подключить - это же вопрос, для любой технологии. так или иначе накладные расходы на репликацию данных становятся высокими.
эволюционируй или вымри  63.063.0
Это сообщение редактировалось 13.11.2018 в 09:36
RU yacc #12.11.2018 23:04  @спокойный тип#12.11.2018 17:59
+
-
edit
 

yacc

старожил
★★☆
с.т.> почему не может? есть же MPP (massive parallel processing) RDBMS
Как правило MPP в хранилищах данных - Data Warehouse.
С OLTP несколько повеселее - это будет что-то типа Oracle RAC
 
RU спокойный тип #13.11.2018 22:30  @yacc#12.11.2018 23:04
+
-
edit
 

спокойный тип
Спокойный_Тип

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

ну в перспективе OLTP и DWH будут сливаться в active datawarehouse - витрины которые будут в nearrealtime рассчитываться а не раз в сутки, так что мы вполне в контексте, собственно для этого и нужно масштабирование.
эволюционируй или вымри  52.952.9
CA tarasv #13.11.2018 23:34  @спокойный тип#13.11.2018 22:30
+
-
edit
 

tarasv

опытный

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

Это хорошо для BI но не решение проблем высоконагруженных систем. Да и паровоз во многом уже ушел. Методы написания приложений поверх БД без поддержки целостности отработаны и возврт назад к использованию только реляционных баз в высоконагруженных приложениях не имеет особого смысла.
 70.0.3538.7770.0.3538.77
RU спокойный тип #14.11.2018 09:41  @tarasv#13.11.2018 23:34
+
-
edit
 

спокойный тип
Спокойный_Тип

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


у высоконагруженных систем "горячих" данных не так много, они на обычные кластеры влазят - на сегодняшний день.
а так да, нужно смотреть на задачу, если не нужны навороты - значит не нужны.
так в РФ достаточно много инсталяций терадаты и количество их увеличивается , рефреши идут, оракл с экзодатой в ту же нишу метит, большой голубой друг тоже старается.
давай посмотрим, я бы не спешил насчёт ушедшего паравоза.
вот санкции от США могут радикально всё обрушить - это да.
эволюционируй или вымри  52.952.9
RU yacc #14.11.2018 23:24  @спокойный тип#13.11.2018 22:30
+
-
edit
 

yacc

старожил
★★☆
с.т.> ну в перспективе OLTP и DWH будут сливаться в active datawarehouse
Что-то как-то хреново я это представляю для транзакций... :)
 64.0.3282.11964.0.3282.119
RU yacc #14.11.2018 23:25  @спокойный тип#14.11.2018 09:41
+
-
edit
 

yacc

старожил
★★☆
с.т.> у высоконагруженных систем "горячих" данных не так много, они на обычные кластеры влазят - на сегодняшний день.
По-моему теме явно не хватает картинки :)
 64.0.3282.11964.0.3282.119
RU спокойный тип #14.11.2018 23:46  @yacc#14.11.2018 23:24
+
-
edit
 

спокойный тип
Спокойный_Тип

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

посмотрим, мир так быстро меняется...там ещё сбоку был машин лернинг который рулил всеми процессами...в общем интересные концепции
эволюционируй или вымри  60.960.9
Последние действия над темой
1 2 3 4

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru