R>>>NoSQL разве сдулся? S>>О нем уже не говорят. Ну да, свою нишу заняло, но воплей уже нет. C>Ну так он победил РСУБД и стал обычным инструментом.
ага, инструментом, который без очередей, реактивных потоков и какого-нибудь брокера ничего полезного сделать не в состоянии, т.е. кроме 2-3 компаний в мире , в принципе, никому не нужен
Здравствуйте, WolfHound, Вы писали:
WH>>>А что за запросы то? И сколько машин их обрабатывали? WH>Так сколько и каких машин?
Много. Очень много.
C>>Транзакционные счётчики, WH>Не понял, что именно и как считают.
Количество оставшихся товаров на складе, количество свободных роботов и т.п.
При том, что счётчики и транзакции, которые к ним привязаны, могут быть в разных БД (шардах). Например, каждый покупатель привязан к своему шарду, который хранит историю покупок. Текущая корзина — в другой системе, которая тоже разбита по shard'ам. При окончании покупки нужно изменить число товара, перевести заказ из корзины в список заказов, запустить нужные workflow по доставке товара и т.п.
Никаких распределённых транзакций, естественно, нет. Они просто нереальны при таких нагрузках.
C>>выборки по каким-то критериям из sharded-данных и т.д. WH>Каким? И что мешает нормальные БД шардить?
В теории — ничего. На практике то, что они на это не рассчитаны и не оптимизированы. Реализации SQL всё ещё считают, что можно (хотя бы теоретически) join-ить любые таблицы с любыми, а производители РСУБД всё ещё соревнуются кто ловчее оптимизирует join'ы из 30 таблиц.
C>>На РСУБД оно не работает. Амазон пробовал все существующие, включая самый дорогой в мире кластер на Oracle RAC. Этот кластер отвалился в день Чёрной Пятницы. WH>Они без шардинга работали?
С шардингом, репликацией, танцами с бубном, облаком супер-пупер-DBA и инженеров из Oracle. Смогли победить, лишь разрешив запись с небольшого числа узлов и переведя все остальные в read-only.
ВНЕЗАПНО оказалось, что overhead от синхронизационного трафика, нужного для обеспечения ACID, растёт почти экспоненциально с числом пишущих узлов.
Здравствуйте, takTak, Вы писали:
S>>>О нем уже не говорят. Ну да, свою нишу заняло, но воплей уже нет. C>>Ну так он победил РСУБД и стал обычным инструментом. T>ага, инструментом, который без очередей, реактивных потоков и какого-нибудь брокера ничего полезного сделать не в состоянии, т.е. кроме 2-3 компаний в мире , в принципе, никому не нужен
Какие-то выдумки бредовые. Зачем потоки? Зачем очереди?
S>>>>О нем уже не говорят. Ну да, свою нишу заняло, но воплей уже нет. C>>>Ну так он победил РСУБД и стал обычным инструментом. T>>ага, инструментом, который без очередей, реактивных потоков и какого-нибудь брокера ничего полезного сделать не в состоянии, т.е. кроме 2-3 компаний в мире , в принципе, никому не нужен C>Какие-то выдумки бредовые. Зачем потоки? Зачем очереди?
чтобы с помощью 5 кривых костылей смоделировать в конечном итоге то, что обеспечивает любая реляционная база данных одна сама по себе
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, WolfHound, Вы писали:
C>На РСУБД оно не работает. Амазон пробовал все существующие, включая самый дорогой в мире кластер на Oracle RAC. Этот кластер отвалился в день Чёрной Пятницы.
У Амазона все время что-то отваливается / валится (ага прошлая неделя)
Здравствуйте, gandjustas, Вы писали:
G>Как в анекдоте "... и не выйграл, а проиграл". G>РСУБД научились делать все полезное, что умеет nosql.
и правда, как в том анекдоте, ведь научились, но не тому
РСУБД по прежнему не могут в шардинг в автоматическом режиме, не могут в автоскейлинг. В high-load сеттинге, РСУБД используют обычно так(большая денормализованная таблица, join-ы силами приложения), что нет особой разницы, РСУБД это или какая-нибудь NoSQL база данных.
Но зато в некоторых РСУБД появились некоторые фишки NoSQL, например поддержка JSON в посгресе. Кто бы мог подумать, что не всем подходит чистая реляционная модель? :D
Здравствуйте, nekocoder, Вы писали:
C>>Можно сказать по-другому: РСУБД остались там, где производительность не важна или нет больших объёмов данных. N>Фейсбук работает на MySQL. Распределенном и вероятно модифицированном, но все же.
По историческим причинам. MySQL там исспользуется как key-value коллекция, т.е. вот реально вся база: одна таблица с двумя колонками, т.е. такая себе noSQL.
По крайней мере фейсбуковцы говорили лет 5-7 назад.
Но FB — это же классический пример "потерялось пара лайков и ничё" и "сложные выборки по произвольным критериям не нужен".
Under our workload, we would get consistent throughput exceptions against DynamoDB and we were set up to retry these off of queues. With Bigtable, not only were these throughputs exceptions gone but the metrics showed we were barely touching the minimum capacity Bigtable provides. To be fair that minimum is fairly high but it was still cheaper than the over stretched throughput we had provisioned for Dynamo.
Я с DynamoDB работаю наверное полгода, и до сих пор плююсь от того, что вместо краткого и ясного языка вроде SQL, для DynamoDB (по слухам, физически работающей поверх уймы обычных СУБД) нужно писать преразвесистые реквесты со словарями, которые вдобавок не проверяются в compile-time.
Здравствуйте, Cyberax, Вы писали:
C>ВНЕЗАПНО оказалось, что overhead от синхронизационного трафика, нужного для обеспечения ACID, растёт почти экспоненциально с числом пишущих узлов.
Есть хорошее выражение "вы не Гугл". Кстати, а на IBM'овских мейнфреймах амазон пытался работать? Вряд ли, но интересно же.
C>Ну так он победил РСУБД и стал обычным инструментом.
Как известно, когда в руках молоток, то все вокруг кажетя гвоздями )) Но нет, не то что не победил, а занял свою, довольно узкую нишу и подсдулся.
Тут совсем недавно как раз пробегал график частоты использования различных баз в проектах и там хорошо видно, что самая популярная Монга, даже не приблизилась к MSSQL, не говоря уже о мускуле и оракле. Более того, реляционки типа постгри — активно растут, а NoSQL в лучшем случае вышли на плато. И это при том, что та же монга с редисом как правило используются тупо в качестве распределенного кеша поверх реляционки.
Так что "победил" — это даже не желаемое за действительное, а очень возбужденные фантазии =)
И вообще, как уже неоднократно говорилось, с тех пор как к NoSQL-ю прилепили SQL в качестве языка запросов, а реляционки поддержали JSON, разница между ними только в том, что у NoSQL подсистема хранения написана через жопу. )
Здравствуйте, IB, Вы писали:
C>>Ну так он победил РСУБД и стал обычным инструментом. IB>Как известно, когда в руках молоток, то все вокруг кажетя гвоздями )) Но нет, не то что не победил, а занял свою, довольно узкую нишу и подсдулся.
Угу, узкую нишу большого объема данных и высокой производительности.
IB>Тут совсем недавно как раз пробегал график частоты использования различных баз в проектах
А если взять срез из статистики по объему оперируемых базой данных?
IB>и там хорошо видно, что самая популярная Монга, даже не приблизилась к MSSQL, не говоря уже о мускуле и оракле.
Наверно на большинстве детсадовских сценариев подобные инструменты банально не нужны?
В этой песочнице неплохо справляются и традиционные РСУБД, верно?
IB>Более того, реляционки типа постгри — активно растут, а NoSQL в лучшем случае вышли на плато. И это при том, что та же монга с редисом как правило используются тупо в качестве распределенного кеша поверх реляционки.
Т.е. в качестве костылей к реляционкам?
Неужели ты произнёс эту крамолу вслух? ))
IB>Так что "победил" — это даже не желаемое за действительное, а очень возбужденные фантазии =)
Это де-факто, когда речь о ниже высоких нагрузок.
IB>И вообще, как уже неоднократно говорилось, с тех пор как к NoSQL-ю прилепили SQL в качестве языка запросов, а реляционки поддержали JSON, разница между ними только в том, что у NoSQL подсистема хранения написана через жопу. )
Ну, значит кто-то через ж-пу умеет писать примерно на порядок более эффективный код, чем другие некоторые через руки.
Потому что эти руки растут из ж-пы.
Здравствуйте, vdimas, Вы писали:
V>Угу, узкую нишу большого объема данных и высокой производительности.
Нишу, где целостность данных не очень критична. )
V>А если взять срез из статистики по объему оперируемых базой данных?
Пытаешься хоть какую-нибудь метрику придумать, где циферки красивые? ) Но нет, думаю что и в таком странном разрезе циферки тоже не в пользу NoSQL. =)
V>Наверно на большинстве детсадовских сценариев подобные инструменты банально не нужны?
Совершенно верно, поскольку у NoSQL порог входа сильно ниже, чем во взрослую БД (в РСУБД все-таки нужна хоть какая-то квалификация), то большинство NoSQL как раз для "на коленных" проектов, и взрослые базы там действительно не очень нужны =)
IB>> И это при том, что та же монга с редисом как правило используются тупо в качестве распределенного кеша поверх реляционки. V>Т.е. в качестве костылей к реляционкам? V>Неужели ты произнёс эту крамолу вслух? ))
Забавно, что ты считаешь это крамолой ) Так увлекся в попытке уязвить, что не заметил куда занесло? )
V>Ну, значит кто-то через ж-пу умеет писать примерно на порядок более эффективный код, чем другие некоторые через руки. V>Потому что эти руки растут из ж-пы.
Твоя прикладная анатомия забавна, но мне мало интересно где у тебя руки. )
Здравствуйте, IB, Вы писали:
V>>Угу, узкую нишу большого объема данных и высокой производительности. IB>Нишу, где целостность данных не очень критична. )
Но где она вполне достижима при наличии квалификации.
V>>А если взять срез из статистики по объему оперируемых базой данных? IB>Пытаешься хоть какую-нибудь метрику придумать, где циферки красивые?
Пытаешься съехать?
IB>Но нет, думаю что и в таком странном разрезе циферки тоже не в пользу NoSQL. =)
Ошибаешься. По этому срезу РСУБД не видно и под микроскопом на фоне NoSQL.
V>>Наверно на большинстве детсадовских сценариев подобные инструменты банально не нужны? IB>Совершенно верно, поскольку у NoSQL порог входа сильно ниже, чем во взрослую БД (в РСУБД все-таки нужна хоть какая-то квалификация)
Судя по твоим рассуждениям всё ровно наоборот — РСУБД нужна для людей без квалификации.
Таким людям дают совершенно безопасный и настолько же тормознутый инструмент.
Квалификация нужна для разработки подобных вещей, но ты тут целевая аудитория таких тулзов, а не разработчик.
IB>то большинство NoSQL как раз для "на коленных" проектов, и взрослые базы там действительно не очень нужны =)
Боюсь, в нашей реальности ровно наоборот — для наколенных проектов берут проверенные простенькие решения, навроде MS SQL.
IB>>> И это при том, что та же монга с редисом как правило используются тупо в качестве распределенного кеша поверх реляционки. V>>Т.е. в качестве костылей к реляционкам? V>>Неужели ты произнёс эту крамолу вслух? )) IB>Забавно, что ты считаешь это крамолой ) Так увлекся в попытке уязвить, что не заметил куда занесло? )
Меня заносит куда и всегда — в называние вещей своими именами.
Если РСУБД сама не умеет нормально кешировать данные, то ей нужны подпорки.
V>>Ну, значит кто-то через ж-пу умеет писать примерно на порядок более эффективный код, чем другие некоторые через руки. V>>Потому что эти руки растут из ж-пы. IB>Твоя прикладная анатомия забавна, но мне мало интересно где у тебя руки. )
IB>>Но нет, думаю что и в таком странном разрезе циферки тоже не в пользу NoSQL. =) V>Ошибаешься. По этому срезу РСУБД не видно и под микроскопом на фоне NoSQL.
что за микроскоп такой? может, всё-таки бинокль?
имхо, noSql может иметь смысл для приложний с числом одновременных пользователей от десятков тысяч (пара сотен фирм на всём земном шарике) либо с числом одновременных пользователей меньше 2 (молодёжный и крутой никому не нужный стартап)
для всего остального подойдёт любая коммерческая реляционная база данных, обеспечение блокировок\локов и беспроблеменого допуска на достаточно высоком уровне — из коробки, а теперь просто подумаем, когда и для каких фирм танцы с бубном вокруг noSql могут вообще иметь смысл и окупиться?
CK>РСУБД по прежнему не могут в шардинг в автоматическом режиме, не могут в автоскейлинг.
Что значит "шардинг в автоматическом режиме" ?
Выбрать инстанс на который писать данные в зависимости от параметров — это вообще не задача СУБД, это задача клиентской библиотеки и подобный решений вагон и маленькая тележка.
Автоматически перераспределить данные при появлении нового шарда — это какая из NoSQL баз умеет?
Что значит "автоскейлинг" ?
Автоматически поднимать новые ноды когда что-то на существующих кончается? Этим точно должен движок СУБД заниматься? И откуда свободное железо будет браться?
Ты вместо маркетиногового булшита приводи реальные сценарии использования. Окажется что единственный реальный сценарий для NoSQL это "положить данные и взять по ключу без гарантий записи на диск". То есть кэш.
CK> В high-load сеттинге, РСУБД используют обычно так(большая денормализованная таблица, join-ы силами приложения), что нет особой разницы, РСУБД это или какая-нибудь NoSQL база данных.
Сорри, но я таких хайлоадов не видел.
Я видел TPC-C, видел банковский процессинг, видел интернет-магазин с большой нагрузкой — везде нормализованные таблицы. Даже в stackoverflow нормализованные. Мамкин хайлоад с базой на 30 гб, где большая денормализованная таблица и джоины силами приложения, там и рядом не валялся.
CK>Но зато в некоторых РСУБД появились некоторые фишки NoSQL, например поддержка JSON в посгресе. Кто бы мог подумать, что не всем подходит чистая реляционная модель? :D
С каких пор тип данных в столбцах не соответствует реляционной модели?
Здравствуйте, gandjustas, Вы писали:
CK>>Но зато в некоторых РСУБД появились некоторые фишки NoSQL, например поддержка JSON в посгресе. Кто бы мог подумать, что не всем подходит чистая реляционная модель? :D G>С каких пор тип данных в столбцах не соответствует реляционной модели?
В реляционной модели речь идет о примитивных типах, если не ошибаюсь.
Мы уже победили, просто это еще не так заметно...
может, всё-таки бинокль?
