Сергей-4030: Все сообщения за 11 Ноября 2018 года

 
ПнВтСрЧтПтСбВс
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Сергей-4030

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

Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.
 70.0.3538.8070.0.3538.80
US NoSQL vs SQL #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

Сергей-4030

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

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

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

Сергей-4030

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

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

Сергей-4030

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

Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
 70.0.3538.8070.0.3538.80

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