-
![[image]](https://www.balancer.ru/cache/uploads/images/1247/128x128-crop/1247620-2885312134_1e80bd8362_o.jpg)
NoSQL vs SQL
Теги:
Сергей-4030
с.т.>> и, я не согласен с тезисом что SQL впринципе плохо масштабируется "СЮРПРИЗ - Sql NOT SCALABLE!", всё зависит от архитектуры.
Balancer> Самое интересное, что и большинство (чисто по определению) NoSQL-решений не масштабируется. Вот, например, упомянутый выше пример самопального файлового key-value
Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.
Balancer> Самое интересное, что и большинство (чисто по определению) NoSQL-решений не масштабируется. Вот, например, упомянутый выше пример самопального файлового key-value
Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.
инфо
инструменты
Balancer>> Самое интересное, что и большинство (чисто по определению) NoSQL-решений не масштабируется. Вот, например, упомянутый выше пример самопального файлового key-value
с.т.> ну тут надо с терминами определиться,
с.т.> 1) что именно под no sql понимается
с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.
Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
с.т.> ну тут надо с терминами определиться,
с.т.> 1) что именно под no sql понимается
с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.
Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
спокойный тип
Сергей-4030> Нет сомнения, что все можно сделать плохо. Но SQL не масштабируется в принципе. А noSQL - зависит от рук. Решения вроде DynamoDB, Oracle Kiev масштабируются вполне хорошо.
эээ..но есть же решения MPP на SQL?
эээ..но есть же решения MPP на SQL?
с.т.> ну тут надо с терминами определиться,
с.т.> 1) что именно под no sql понимается
Всё, что не SQL
Когда в один ряд NoSQL ставят Redis и MongoDB, там может быть всё что угодно ещё, что позволяет сохранить и получить значение
с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.
Это уже не ко мне, я-то как раз практикую масштабирование даже у MySQL
с.т.> 1) что именно под no sql понимается
Всё, что не SQL
NoSQL (от англ. not only SQL — не только SQL) — термин, обозначающий ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL.
Когда в один ряд NoSQL ставят Redis и MongoDB, там может быть всё что угодно ещё, что позволяет сохранить и получить значение
с.т.> 2) какое именно масштабирование там такое особенное что SQL не может впринципе? SQL поверх ампов давно существует.
Это уже не ко мне, я-то как раз практикую масштабирование даже у MySQL
Сергей-4030> SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
Сергей-4030>> SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
Видимо не делаешь joins по таблицам. То есть то, что ты делаешь реализуется свободно на noSQL а возможностей SQL ты не используешь.
То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
Видимо не делаешь joins по таблицам. То есть то, что ты делаешь реализуется свободно на noSQL а возможностей SQL ты не используешь.
То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.
Сергей-4030> Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь
ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
Кстати, я ни за что не агитирую. Если кто считает, что SQL scalable - флаг в руки. Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах. Если ты хочешь думать, что это от глупости - ok, пусть так.
Кстати, я ни за что не агитирую. Если кто считает, что SQL scalable - флаг в руки. Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах. Если ты хочешь думать, что это от глупости - ok, пусть так.
Сергей-4030>> Обычное масштабирование. Значит, что масштабируемая система - которая при двукратном увеличении загрузки требует примерно двукратного увеличения ресурсов. SQL решения при двукратном увеличении нагрузки требует примерно четырехкратного увеличения ресурсов.
с.т.> ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь
Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
с.т.> ммм...а мне казалось что если фронтенд тянет то узлы обработчики можно ~линейно наращивать - главное что бы перекоса таблиц между ампами не было...возможно не прав но поясни как именно ты нагрузку считаешь
Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
Сергей-4030> Видимо не делаешь joins по таблицам.
Делаю
Сергей-4030> То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.
Конечно, ничего не меняет. По-прежнему не каждый NoSQL масштабируется, не каждый SQL не масштабируется
Делаю
Сергей-4030> То, что SQL можно использовать для noSQL запросов - бесспорно. Но это ничего не меняет.
Конечно, ничего не меняет. По-прежнему не каждый NoSQL масштабируется, не каждый SQL не масштабируется
Сергей-4030> Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах. Если ты хочешь думать, что это от глупости - ok, пусть так.
Так я не спорю. И что?
Так я не спорю. И что?
Сергей-4030> Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
а как у тебя no sql делает join так эффективно? насколько я видел, хадуп вообще нормально не может джойнить (может , но медленно, то одно то другое хромает, вообще не энтерпрайз платформа, только для "болота данных" подходит), чисто большая флэшка - по ёмкости - да , отлично масштабируется.
или же у тебя какой-то другой no sql?
(возвращаясь к тому что понимается под no sql)
а как у тебя no sql делает join так эффективно? насколько я видел, хадуп вообще нормально не может джойнить (может , но медленно, то одно то другое хромает, вообще не энтерпрайз платформа, только для "болота данных" подходит), чисто большая флэшка - по ёмкости - да , отлично масштабируется.
или же у тебя какой-то другой no sql?
(возвращаясь к тому что понимается под no sql)
Balancer> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
ну это не масштабирование ))) ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных - когда тебе и ёмкости и скорость обработки нужно поднять что бы время отклика на увеличивающихся объемах было прежним.
вот зелёная слива (greenplum) вроде заявляет что может.
ну это не масштабирование ))) ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных - когда тебе и ёмкости и скорость обработки нужно поднять что бы время отклика на увеличивающихся объемах было прежним.
вот зелёная слива (greenplum) вроде заявляет что может.
Balancer>> А почему у меня иначе? Добавил вторую БД — получил удвоение производительности. Что я делаю не так?
с.т.> ну это не масштабирование )))
Ну почему?
Это называется Horizontal Scaling - горизонтальное масштабирование, в отличии от вертикального - когда увеличиваются ресурсы самого сервера.
с.т.> ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных
Надо чтобы приложение поддерживало шардирование. Тогда можно.
с.т.> ну это не масштабирование )))
Ну почему?
Это называется Horizontal Scaling - горизонтальное масштабирование, в отличии от вертикального - когда увеличиваются ресурсы самого сервера.
с.т.> ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных
Надо чтобы приложение поддерживало шардирование. Тогда можно.
Сергей-4030> Скажем есть две таблицы. Если каждая из них увеличилась в два раза, то join этих таблиц станет в среднем сложнее в четыре раза.
Это не так
Скажем сложность мердж джоина при сортированном входе - O(N + M)
Если у нас N и М каждая увеличилась вдвое, то и сложность возросла вдвое
Сортировка тоже неквадратична, а поиск по индексу логарифмичен
Это не так
Скажем сложность мердж джоина при сортированном входе - O(N + M)
Если у нас N и М каждая увеличилась вдвое, то и сложность возросла вдвое
Сортировка тоже неквадратична, а поиск по индексу логарифмичен
с.т.> ну это не масштабирование ))) ты же не можешь прозрачно для приложения без переписывания кода добавлять N+1 БД по мере роста объёма данных
Могу Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.
В принципе, я Авиабазу так и планирую разгружать, когда решу вопросы файлового синка (аттачи и картинки).
Могу
Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.В принципе, я Авиабазу так и планирую разгружать, когда решу вопросы файлового синка (аттачи и картинки).
Balancer> Могу Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.
ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая)
Естественно, если это изначально в коде заложено, типа round-robin по запросам и т.п.ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая)
с.т.> ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая)
А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.
А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.
с.т.>> ХОРОШО, но таки это не масштабирование на уровне СУБД (без разницы SQL или другая)
Balancer> А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.
нет могу , если у меня СУБД MPP архитектуры, тогда у неё есть фронтенд , та самая "сущность, распределяющая нагрузку по узлам системы" и набор узлов. приложение работает с фронтендом, а что там дальше ему не известно. вот тебе хоть клоудера хоть зелёная-слива ну и другие вещи есть. собственно любая СУБД может масштабироваться если постороена по MPP архитектуре.
Balancer> А ты в любом случае не можешь масштабировать ТОЛЬКО на уровне СУБД. Если приложение работает только с одним узлом БД, то про наличие её реплик оно никак не узнает и эти реплики работу никак не ускорят. Чтобы приложение могло пользоваться масштабированной БД, оно должно уметь работать с разных узлов системы. И должна быть сущность, распределяющая нагрузку по узлам системы.
нет могу
, если у меня СУБД MPP архитектуры, тогда у неё есть фронтенд , та самая "сущность, распределяющая нагрузку по узлам системы" и набор узлов. приложение работает с фронтендом, а что там дальше ему не известно. вот тебе хоть клоудера хоть зелёная-слива ну и другие вещи есть. собственно любая СУБД может масштабироваться если постороена по MPP архитектуре.
с.т.> если у меня СУБД MPP архитектуры, тогда у неё есть фронтенд , та самая "сущность, распределяющая нагрузку по узлам системы" и набор узлов. приложение работает с фронтендом
Ну так и у меня то же самое получается Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД
Ну так и у меня то же самое получается
Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД
Balancer> Ну так и у меня то же самое получается Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД
вот именно, ты не можешь автоматически размазать таблицы по узлам а потом параллельно распараллелить отрабоку запросов, что бы каждый узел условно свой кусок джойна собрал. твоя СУБД не даёт такого функционала.
Только дёргать удалённую географически БД — это убить всякую производительность. Поэтому или нужно иметь «масштабирование» в рамках одного датацентра, что слишком сужает возможности (в моём случае), или иметь распределённое приложение, которое будет работать со своей репликой БД вот именно, ты не можешь автоматически размазать таблицы по узлам а потом параллельно распараллелить отрабоку запросов, что бы каждый узел условно свой кусок джойна собрал. твоя СУБД не даёт такого функционала.
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 для решения их задач.
Больших по какому критерию? Объем функционала в high load держится чуть выше минимально приемлемого уровня. Большая там не бизнес логика, а инфраструктура которая требуется для их функционирования. Корпоративный "кровавый энтерпрайз" тоже большой, но в основном живет на реляционных базах. Там есть потребность в транзакционности и целостности данных и нет причин пытаться съесть кактус который получается из NoSQL для таких применений.
Сергей-4030> Вот там его и использует и Google и Amazon. Т.е. в случае Google и Amazon - во всех до единого проектах. В Амазоне число команд, использующих SQL базу данных стремится к нулю. Да, у них есть SQL база в AWS. И, конечно, сторонние клиенты ее используют широко - для своих маленьких проектов. Сам Амазон в своих проектах SQL базу не использует практически никогда. Потому что - СЮРПРИЗ - Sql NOT SCALABLE!
Размер кактуса который для этого нужно съесть c классическими реляционными базами очень велик. Иногда даже слишком. Но так-как бизнес без транзакций жить не может то есть и масштабируемое и с транзакциями. F1/Spanner например очень даже scalable.
Сергей-4030> Вы можете мне загружать насчет что там Гугль пользует (кстати, интересно, надо поговорить с гугловцами), но когда вы мне начинаете втирать насчет Амазона - не смешно, чесное слово.
Если внимательно прочитать что я написал то то там нет ничего про то что внутри у себя используют Google или Amazon. Там про то какие инструменты они рекомендуют пользователям cloud для решения их задач.
Сергей-4030>Если кто считает, что SQL scalable - флаг в руки. Но внутри как минимум Amazon и Oracle SQL решения discouraged от применения в high availability системах.
Хм. Может всетаки в high load? С девятками после запятой availability у классических реляционок все нормально.
Хм. Может всетаки в high load? С девятками после запятой availability у классических реляционок все нормально.
tarasv> Если внимательно прочитать что я написал то то там нет ничего про то что внутри у себя используют Google или Amazon. Там про то какие инструменты они рекомендуют пользователям cloud для решения их задач.
Ну а почему, вы думаете, пользователям они рекомендуют SQL а своим внутренним командам - нет?
Ну а почему, вы думаете, пользователям они рекомендуют SQL а своим внутренним командам - нет?
yacc> Надо чтобы приложение поддерживало шардирование. Тогда можно.
Ну да. Или уж имплентировать на своем сервисе full fledged базу данных. Тогда тоже можно.
Ну да. Или уж имплентировать на своем сервисе full fledged базу данных. Тогда тоже можно.
Copyright © Balancer 1997..2019
Создано 10.11.2018
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 10.11.2018
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
