NoSQL vs SQL

Теги:SQL, NoSQL
 
1 2 3 4
US Сергей-4030 #11.11.2018 11:38  @Balancer#11.11.2018 10:38
+
-
edit
 

Сергей-4030

исключающий третье
★★

с.т.>> и, я не согласен с тезисом что SQL впринципе плохо масштабируется "СЮРПРИЗ - Sql NOT SCALABLE!", всё зависит от архитектуры.
Balancer> Самое интересное, что и большинство (чисто по определению) NoSQL-решений не масштабируется. Вот, например, упомянутый выше пример самопального файлового key-value :)

Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.
 70.0.3538.8070.0.3538.80
US Сергей-4030 #11.11.2018 11:42  @спокойный тип#11.11.2018 11:37
+
-
edit
 

Сергей-4030

исключающий третье
★★

Balancer>> Самое интересное, что и большинство (чисто по определению) NoSQL-решений не масштабируется. Вот, например, упомянутый выше пример самопального файлового key-value :)
с.т.> ну тут надо с терминами определиться,
с.т.> 1) что именно под no sql понимается
с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.

Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
 70.0.3538.8070.0.3538.80
RU спокойный тип #11.11.2018 11:43  @Сергей-4030#11.11.2018 11:38
+
-
edit
 

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

старожил
★☆
Сергей-4030> Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.

эээ..но есть же решения MPP на SQL?
эволюционируй или вымри  52.952.9
RU Balancer #11.11.2018 11:44  @спокойный тип#11.11.2018 11:37
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> ну тут надо с терминами определиться,
с.т.> 1) что именно под no sql понимается

Всё, что не SQL :)

NoSQL (от англ. not only SQL — не только SQL) — термин, обозначающий ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL.
 


Когда в один ряд NoSQL ставят Redis и MongoDB, там может быть всё что угодно ещё, что позволяет сохранить и получить значение :D

с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.

Это уже не ко мне, я-то как раз практикую масштабирование даже у MySQL ;)
 55
RU Balancer #11.11.2018 11:46  @Сергей-4030#11.11.2018 11:42
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.

А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так? :)
 55
US Сергей-4030 #11.11.2018 11:49  @Balancer#11.11.2018 11:46
+
-
edit
 

Сергей-4030

исключающий третье
★★

Сергей-4030>> SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так? :)

Видимо не делаешь joins по таблицам. То есть то, что ты делаешь реализуется свободно на noSQL а возможностей SQL ты не используешь.

То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.
 70.0.3538.8070.0.3538.80
RU спокойный тип #11.11.2018 11:52  @Сергей-4030#11.11.2018 11:42
+
-
edit
 

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

старожил
★☆
Сергей-4030> Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.

ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь
эволюционируй или вымри  52.952.9
US Сергей-4030 #11.11.2018 11:59  @Balancer#11.11.2018 11:46
+
-
edit
 

Сергей-4030

исключающий третье
★★

Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так? :)

Кстати, я ни за что не агитирую. Если кто считает, что SQL scalable - флаг в руки. Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах. Если ты хочешь думать, что это от глупости - ok, пусть так.
 70.0.3538.8070.0.3538.80
US Сергей-4030 #11.11.2018 12:01  @спокойный тип#11.11.2018 11:52
+
-
edit
 

Сергей-4030

исключающий третье
★★

Сергей-4030>> Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
с.т.> ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь

Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
 70.0.3538.8070.0.3538.80
RU Balancer #11.11.2018 12:15  @Сергей-4030#11.11.2018 11:49
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Видимо не делаешь joins по таблицам.

Делаю :)

Сергей-4030> То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.

Конечно, ничего не меняет. По-прежнему не каждый NoSQL масштабируется, не каждый SQL не масштабируется :)
 55
RU Balancer #11.11.2018 12:16  @Сергей-4030#11.11.2018 11:59
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах. Если ты хочешь думать, что это от глупости - ok, пусть так.

Так я не спорю. И что? :)
 55
RU спокойный тип #11.11.2018 12:17  @Сергей-4030#11.11.2018 12:01
+
+1
-
edit
 

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

старожил
★☆
Сергей-4030> Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.

а как у тебя no sql делает join так эффективно? насколько я видел, хадуп вообще нормально не может джойнить (может , но медленно, то одно то другое хромает, вообще не энтерпрайз платформа, только для "болота данных" подходит), чисто большая флэшка - по ёмкости - да , отлично масштабируется.
или же у тебя какой-то другой no sql?
(возвращаясь к тому что понимается под no sql)
эволюционируй или вымри  52.952.9
RU спокойный тип #11.11.2018 15:29  @Balancer#11.11.2018 11:46
+
-
edit
 

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

старожил
★☆
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так? :)

ну это не масштабирование ))) ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных - когда тебе и ёмкости и скорость обработки нужно поднять что бы время отклика на увеличивающихся объемах было прежним.
вот зелёная слива (greenplum) вроде заявляет что может.
эволюционируй или вымри  52.952.9
RU yacc #11.11.2018 15:53  @спокойный тип#11.11.2018 15:29
+
-
edit
 

yacc

старожил
★★☆
Balancer>> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так? :)
с.т.> ну это не масштабирование )))
Ну почему?
Это называется Horizontal Scaling - горизонтальное масштабирование, в отличии от вертикального - когда увеличиваются ресурсы самого сервера.

с.т.> ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных
Надо чтобы приложение поддерживало шардирование. Тогда можно.
 64.0.3282.11964.0.3282.119
RU yacc #11.11.2018 16:14  @Сергей-4030#11.11.2018 12:01
+
-
edit
 

yacc

старожил
★★☆
Сергей-4030> Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
Это не так
Скажем сложность мердж джоина при сортированном входе - O(N + M)
Если у нас N и М каждая увеличилась вдвое, то и сложность возросла вдвое
Сортировка тоже неквадратична, а поиск по индексу логарифмичен
 64.0.3282.11964.0.3282.119
RU Balancer #11.11.2018 19:44  @спокойный тип#11.11.2018 15:29
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> ну это не масштабирование ))) ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных

Могу :) Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.

В принципе, я Авиабазу так и планирую разгружать, когда решу вопросы файлового синка (аттачи и картинки).
 55
RU спокойный тип #11.11.2018 19:50  @Balancer#11.11.2018 19:44
+
-
edit
 

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

старожил
★☆
Balancer> Могу :) Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.

ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая) :D
эволюционируй или вымри  52.952.9
RU Balancer #11.11.2018 20:21  @спокойный тип#11.11.2018 19:50
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая) :D

А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.
 55
RU спокойный тип #11.11.2018 20:28  @Balancer#11.11.2018 20:21
+
-
edit
 

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

старожил
★☆
с.т.>> ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая) :D
Balancer> А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.

нет могу :D , если у меня СУБД MPP архитектуры, тогда у неё есть фронтенд , та самая "сущность, распределяющая нагрузку по узлам системы" и набор узлов. приложение работает с фронтендом, а что там дальше ему не известно. вот тебе хоть клоудера хоть зелёная-слива ну и другие вещи есть. собственно любая СУБД может масштабироваться если постороена по MPP архитектуре.
эволюционируй или вымри  52.952.9
RU Balancer #11.11.2018 21:47  @спокойный тип#11.11.2018 20:28
+
-
edit
 

Balancer

администратор
★★★★★
с.т.> если у меня СУБД MPP архитектуры, тогда у неё есть фронтенд , та самая "сущность, распределяющая нагрузку по узлам системы" и набор узлов. приложение работает с фронтендом

Ну так и у меня то же самое получается :) Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД :)
 55
RU спокойный тип #11.11.2018 23:30  @Balancer#11.11.2018 21:47
+
-
edit
 

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

старожил
★☆
Balancer> Ну так и у меня то же самое получается :) Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД :)

вот именно, ты не можешь автоматически размазать таблицы по узлам а потом параллельно распараллелить отрабоку запросов, что бы каждый узел условно свой кусок джойна собрал. твоя СУБД не даёт такого функционала.
эволюционируй или вымри  52.952.9
CA tarasv #11.11.2018 23:50  @Сергей-4030#10.11.2018 19:05
+
-
edit
 

tarasv

опытный

Сергей-4030> Конечно. Исключительно в областях, для которых предназначен. Для больших проектов, предполагающих очень высокую нагрузку.

Больших по какому критерию? Объем функционала в high load держится чуть выше минимально приемлемого уровня. Большая там не бизнес логика, а инфраструктура которая требуется для их функционирования. Корпоративный "кровавый энтерпрайз" тоже большой, но в основном живет на реляционных базах. Там есть потребность в транзакционности и целостности данных и нет причин пытаться съесть кактус который получается из NoSQL для таких применений.

Сергей-4030> Вот там его и использует и Google и Amazon. Т.е. в случае Google и Amazon - во всех до единого проектах. В Амазоне число команд, использующих SQL базу данных стремится к нулю. Да, у них есть SQL база в AWS. И, конечно, сторонние клиенты ее используют широко - для своих маленьких проектов. Сам Амазон в своих проектах SQL базу не использует практически никогда. Потому что - СЮРПРИЗ - Sql NOT SCALABLE!

Размер кактуса который для этого нужно съесть c классическими реляционными базами очень велик. Иногда даже слишком. Но так-как бизнес без транзакций жить не может то есть и масштабируемое и с транзакциями. F1/Spanner например очень даже scalable.

Сергей-4030> Вы можете мне загружать насчет что там Гугль пользует (кстати, интересно, надо поговорить с гугловцами), но когда вы мне начинаете втирать насчет Амазона - не смешно, чесное слово.

Если внимательно прочитать что я написал то то там нет ничего про то что внутри у себя используют Google или Amazon. Там про то какие инструменты они рекомендуют пользователям cloud для решения их задач.
 70.0.3538.7770.0.3538.77
CA tarasv #11.11.2018 23:53  @Сергей-4030#11.11.2018 11:59
+
-
edit
 

tarasv

опытный

Сергей-4030>Если кто считает, что SQL scalable - флаг в руки. Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах.

Хм. Может всетаки в high load? С девятками после запятой availability у классических реляционок все нормально.
 70.0.3538.7770.0.3538.77
US Сергей-4030 #12.11.2018 00:09  @tarasv#11.11.2018 23:50
+
-
edit
 

Сергей-4030

исключающий третье
★★

tarasv> Если внимательно прочитать что я написал то то там нет ничего про то что внутри у себя используют Google или Amazon. Там про то какие инструменты они рекомендуют пользователям cloud для решения их задач.

Ну а почему, вы думаете, пользователям они рекомендуют SQL а своим внутренним командам - нет?
 70.0.3538.7770.0.3538.77
US Сергей-4030 #12.11.2018 00:11  @yacc#11.11.2018 15:53
+
-
edit
 

Сергей-4030

исключающий третье
★★

yacc> Надо чтобы приложение поддерживало шардирование. Тогда можно.

Ну да. Или уж имплентировать на своем сервисе full fledged базу данных. Тогда тоже можно.
 70.0.3538.7770.0.3538.77
1 2 3 4

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