Комментарии 65
После падения одной из год в кассандре, она отключается, и запросы, которые шли на данную году, перераспределяются на оставшиеся ноды. Падает следующая года и так, пока нод не останется. Как карточный домик она у нас складывалась, когда например падал самолёт, и трафик с подключены систем удваивался / утраивался.
Redis+Redis Cluster или Sentinel, работает без даунтайма.Ты про какой тип говорил NOSQL или SQL и про какую конфигурацию серверов сколько мастеров сколько слейвов
Master-Slave,MultyMaster итд.Куча же подходов к реализации отказоустойчивости.
Riak, при установленной политике корзины — например, 3 копии и кворум на чтение и запись.
Другой вопрос, что при раздельных падениях в разное время можно получить ситуацию, что кворума нет, и база отдаст сообщение типа «я нашла 2 разных версии, сами разбирайтесь, какая правильнее».
Я так и думал, что автор наркоман, но после
Times Series Databases как тренд я вообще не затрагиваю. Есть тезис среди times series движения, что это отдельная ниша, аналогично графовым базам, но, если копать глубже, там оказывается под капотом сидит Postgres.
В целом, все стало ясно. Автор слишком сильно не учитывает, что на самом деле есть куча задач где консистетность в полной мере не нужна и там это отлично почему-то работает.
ИМХО — самой популярной вариацией в ближайшие 5 лет будет бессхемная DB с широкой поддержкой SQL, но с урезанной консистентностью транзакций
Я не совсем понимаю, как связаны join и sql? Для операции join строго говоря, нужна только связь по каким-то ключам, sql не нужен.
Ту же аналику, основанную на событиях, которые обычно делают через всякие системы типа elasticsearch и clickhouse использует просто куча народу, но вот join'ов нет ни там, ни там.
То, что прикручивают sql это не очень показатель полезности sql, а скорее всего просто инетрности.
Вообще, если абстрактно, то по моему опыту прикрученный к некой системе SQL, которая не является СУБД, обычно является жалкой пародией на SQL, где любая команда может отсутствовать или работать не так.
Про «прикручивание» SQL к документо-ориентированным СУБД — согласен, получается часто не очень. Те же Postgres и MySQL хранят документы гораздо эффективнее для большинства бизнес задач. Но выхода нет — на волне хайпа в NOSQL инвестированы огромные деньги, созданы хранилища и бизнес требует наконец-то начать извлекать из них какую-то аналитику. Вот тут-то без SQL и наступает облом.
Нет это бред ;) Открывай api.mongodb.com и просветляйся.
en.wikipedia.org/wiki/BSON
Если из фразы выше убрать SQL получится вылитый MongoDB. Что самое смешное, с точки зрения java программиста API Монго просто два шага вперёд по сравнению с архаичным SQL. Даже если не учитывать во что превратили SQL различные вендоры, перетягивая одеяло на себя. В итоге надо знать в 3 раза больше команд, а в каждой РСУБД ещё и своя специфика по оптимизации. Вот уж не надо больше нам такого счастья. Я это всё говорю как человек который знает SQL намного дольше, чем java. Познакомился с Mongo, забыл SQL как страшный сон.
Ну и любимая фишка Mongo — когда после первой же операции запрос теряет связь с коллекциями/индексами и начинает вертеть данные в памяти — тоже изрядно достает когда данных много.
Это еще не говоря об аналитиках — которые так и норовят спросить, почему в 70е уже можно было писать запросы на практически обычном английском, а в 2018 их вдруг надо формулировать с помощью каких-то чудных скобок и корявок.
Как закончивший иняз скажу, что это глупости про «обычный английский». Как только начинаются трехэтажные select-ы into, partition by, rownum() и прочее подобное, читаемость SQL кода падает в НОЛЬ. Причём смешно, ДБА который этот запрос писал уже через несколько дней не может понять что там и зачем. Про удобство отладки молчу. Ещё и нельзя местами переставить например limit и order, что есть показатель нереальной продуманности SQL.
Правильно пишешь, что SQL придумали в лохматые 70е НЕ для программистов, а для околокомпьютерного сброда типа менеджеров. Менеджеры его так и не осилили, а для нормального программиста он убог. Народная мудрость: сделай систему, которой сможет пользоваться идиот и только идиот станет ей пользоваться.
>«в какие еще филиалы обращаются клиенты, посетившие филиал X»
В Монго это элементарно делается, причём несколькими способами. Для современного Монго скорее всего обратных примеров будет больше, когда «сделай это на РСУБД и чтобы отрабатывало за милисекунды» заставит бледнеть SQLных свитерков ;)
По поводу запросов — а давайте вы пример приведете и мы сравним. Монго-база в пару миллионов записей у меня есть, есть и ее копия в MySQL. Заодно засеките, сколько времени у вас заняло написать и отладить запрос на Монго.
Как javaкодер такое сделаю двумя последовательными запросами, сначала выдернуть IDы клиентов, результат скормить второму запросу в $in. Это будет работать быстрее, чем JOIN в РСУБД. Строчек 5 кода. По компактности кода mongo api вообще в десяток раз лаконичнее самописных DAO для РСУБД, вся эта муть с prepared statements, а потом вытаскиванием данных из resultset. Надо иметь очень альтернативное мышление, чтобы это всё было быстрее и дешевле в разработке чем mongo api.
вы индусы все одинаковы.
Успехов в притаскивании «миллиона LONGов» — там таких KPI еще штук 20-25 кроме названного.
Я прогер, а не телепат. Какое «ТЗ», такой ответ. Изначальный ответ был про «несколько способов», чего ты разумеется не заметил. Живи и дальше с верой, что твою задачу на NOSQL ну прямо никак не решить. Не забудь почаще эту мысль до начальства своего доносить, а то вдруг тоже в один прекрасный день на мороз пойдёшь.
Соболезную твоему начальству, вместо идиотов пихающих во все дыры Mongo пришёл идиот, пихающий SQL. Хотя, причина уже и понятна, какая зарплата, такой и архитектор.
Но я вам все равно благодарен. У нас есть неплохая статистика по интервью (большинство «юниоров-джаваистов» отсеиваются еще на телефонном этапе) — теперь мы, наверное, даже и звонить таким перестанем.
Батенька, не переживай, с тобой больше не пересечемся. Я с SQL работать начал 15 лет назад, но года 4 как выбросил все РСУБД из проектов. Удачи тебе в довлении над девочками с экселем и вешании лапши начальству, что лучше тебя только Чак Норрис!
Fully expressive joins, faceted search, graphs queries, powerful aggregations
Multi-node durability with tunable semantics
Analytics and BI-ready
And… multi-document ACID transactions
Не забудь усилить давление на мозги начальства, что Монго это атата. А то глядишь, узнают, что SQL с РСУБД уже не нужны
На слабО и без ТЗ не осилил. Стыд мне и позор.
>вчера вышедшую версию только школота в продакшен ставит
Узнаю Ораклистов :) Наш перед вылетом на мороз любил повторять, что только школота юзает Оракл с веткой ниже Х.2
А еще у нас есть девочка-аналитик. Она пишет свои SQL-запросы без всякого участия программистов, рисует графики в Excel и это отлично работает. Некоторые мы потом оптимизируем и выкладываем на портал для клиентов, некоторые нет — но на Монго, да еще и с участием «javaкодер-ов» это было бы на порядок дольше и дороже.
>Она пишет свои SQL-запросы без всякого участия программистов
Ну я очень точно описал ситуацию ещё несколько дней назад. SQL язык для околокомпьютерного сброда в конторах где на R-программистов денег не хватило :) Так бы и писал сразу, что SQL-обезьянки дешеле, тогда бы и спора не было.
И последнее — работа системного архитектора как раз и заключается в нахождении путей сделать «быстрее и дешевле».
Я нашему бывшему ораклисту (да, его позднее ушли попой в мороз) показывал фокус, когда даже с тормозным Ораклом оказывалось в несколько раз быстрее скачать весь dataset (вообще говоря на линейное чтение плоских данных в РСУБД не хуже NOSQL), обработать на сервере приложений и вернуть результат.
РСУБДшники такие смешные, не знают, что ядро РСУБД на порядок тормознее нормального ЯП.
>апп сервер ничего не умеет, чего бы не умел pl/sql
Спор старый как мир, хранимочки vs аппсервер. Только весь приличный бизнес на java и аппсерверах, а за хранимочки всякие маргиналы и продажные душонки типа Томми Кайта ;)
Только что мне PLSQL впаривал. У тебя какая-то болезнь, пишешь невпопад. ВСЕГДА тянуть данные на аппсервер это тебе тоже не я, а голоса в голове предложили.
Я нашему бывшему ораклисту (да, его позднее ушли попой в мороз) показывал фокус, когда даже с тормозным Ораклом оказывалось в несколько раз быстрее скачать весь dataset
не надо качать весь датасет, люди буду смеяться
вот это, да. займет пару секунд. а вот вычитать в апп сервер по jdbc 100 млн строк что бы вычислить дельту уйдет вечность только на выкачивание. классика индюшатины, не слышавшей о MERGE.
Написал бы «пару милисекунд» чтобы уж точно победить в этом споре. У того ораклиста тоже всегда всё летало… и терабайтные базы и тысячи пользователей. ;)
Расскажите мне, о величайший — куда и что вы будете скачивать, если размеры датасета превышают обьем памяти на вашем сервере? Раз эдак в 5 как минимум? Кстати, в нормальных NOSQL-решениях тоже никто весь датасет никуда не качает.
>если размеры датасета превышают обьем памяти на вашем сервере
Я уже понял, что ты большой фантазёр. Столько «а если» в каждом сообщении.
особенно повеселило восхищение майкрософтом, учитывая, что flashback query в оракле уже лет 8 доступны.
Пользователи, конечно, сначала шалеют от того, что им теперь можно править данные в любом периоде — хочешь задним числом, хочешь передним. У постановщиков задачи со стороны Заказчика, конечно, мозг закипал, когда я им рисовал картинку, в которой время и по иксам, и по игрекам.
А потом приходит GDPR и мы разрабатываем новые СУБД, который с одной стороны все из себя темпоральные и всё хранят вечно, но с другой стороны, если какой-то чиновник хорошо попросит, то тут же удаляют, и тоже навечно. :)
Автору спасибо за краткий обзор всего и за кучу ключевых слов по которым я пошел читать и учить что происходит в мире баз данных сегодня.
Мы видим продукты, которые стали заложниками своей изначальной простоты, и они будут отваливаться, потихонечку уходить в небытие.
Тут меня прям бомбануло, простите. Давайте на примере Тарантул. Я слышал что тарантул раньше использовал sophiadb. Это довольно простой движок по сравнению с текущим как я понимаю. Два года назад на тестовом стенде тарантул за неделю успел как потерять данные при записи (тут в драйвере скорее всего была ошибка, не стал разбираться), показал намного худшую производительность (точных цифр не помню, но прям со свистом, раз в 10 на записи и в пару раз вроде на чтение vs SophiaDb) И наконец развалиться без какой либо возможности восстановления. Плюс отсутствие возможности юзать как апликейшен сервер из-за лимитов луа по памяти, и получился полный проигрыш по всем фронтам. Вроде бы движок мощнее, а смысл? Мы вынуждены были написать свой сервер на sophiadb и за два года, не возникло ни одной проблемы на нем, хотя и нагрузка выше, и падения серверов пережила база. Хотя казалось бы, в нем нет и половины фич тарантула. И вот если с первой частью статьи я почти везде согласен, то чем дальше — тем страшнее. Не превратитесь в Кассандру, Тарантул, в погоне за фичами. ps: выбираем жене машину — хочет — чтобы она была — быстрая, большая, проходимая, и камера и парктроники, и спереди и сзади и чтоб пищала когда сбоку в мертвой зоне и чтоб не хенде всякие и не дороже хенде и не б/у конечно. Так и клиенты — они много чего хотят от субд, пока не поймут, что иногда лучше меньше
Захотелось сказать, что "это слишком сложная штука для понимания широким кругом разработчиков" — можно так же сказать про интернет протоколы, что, впрочем, не мешает широкому кругу разработчиков им пользоватся.
Кто пользуется Riak? — никто=/
NewSQL: SQL никуда не уходит