Комментарии 65
У меня возникает вопрос, что кроме кассандры продолжает работать при падении одной из нод без даун тайма? И почему автор говорит, что ключ-значения вымрет?
Даунтайм из-за выбора новой праймари реплики или вы о чём-то другом?
В кассандре падение любой из нод не вызывает падение и/или временную невозможность работы приложения. К примеру в той же MonogoDB после падения мастер ноды будет даунтайм, а только потом выберется новая нода и приложение продолжит работу.

После падения одной из год в кассандре, она отключается, и запросы, которые шли на данную году, перераспределяются на оставшиеся ноды. Падает следующая года и так, пока нод не останется. Как карточный домик она у нас складывалась, когда например падал самолёт, и трафик с подключены систем удваивался / утраивался.

Во первых даунтайм будет только для пишущих, читающим с nearest ничего не грозит. Во вторых падение primary это мягко говоря авария и если посмотреть тесты у jepsen то актуальные (3.4 и 3.6) монго наоборот одни из лучших в этом.
слишком размазанный вопрос, зависит от архитектуры.
Redis+Redis Cluster или Sentinel, работает без даунтайма.Ты про какой тип говорил NOSQL или SQL и про какую конфигурацию серверов сколько мастеров сколько слейвов
Master-Slave,MultyMaster итд.Куча же подходов к реализации отказоустойчивости.
> У меня возникает вопрос, что кроме кассандры продолжает работать при падении одной из нод без даун тайма?

Riak, при установленной политике корзины — например, 3 копии и кворум на чтение и запись.
Другой вопрос, что при раздельных падениях в разное время можно получить ситуацию, что кворума нет, и база отдаст сообщение типа «я нашла 2 разных версии, сами разбирайтесь, какая правильнее».

Я так и думал, что автор наркоман, но после


Times Series Databases как тренд я вообще не затрагиваю. Есть тезис среди times series движения, что это отдельная ниша, аналогично графовым базам, но, если копать глубже, там оказывается под капотом сидит Postgres.

В целом, все стало ясно. Автор слишком сильно не учитывает, что на самом деле есть куча задач где консистетность в полной мере не нужна и там это отлично почему-то работает.

Да даже уже на «смерти eventual-consistency» можно было заканчивать чтение. Обдолбаются своим тарантулом, и давай всех подряд хоронить.
Статья не совсем бесполезна, я например плотно используя Монго не знал, что они уже транзакции прикрутили. Изредка их не хватает (намного реже, чем утверждают рсубдшники). Возникает вопрос — сколько годков рсубдам осталось? 5-10 и не вспомнит никто, кроме старпёров.
Опять же — что такое «РСУБД» можно спорить, но медицинский факт в том, что любой серьезный анализ данных требует JOINов, а SQL в последнее время прикручивают ко всему — от S3 до Монго с Эластиком и прочих Хадупов. И аналитику заказчики требуют онлайн, а не когда данные в OLAP реплицируются и оно все кубы пересчитает — да и деньги на сам OLAP/DWH из них не вытянешь.
ИМХО — самой популярной вариацией в ближайшие 5 лет будет бессхемная DB с широкой поддержкой SQL, но с урезанной консистентностью транзакций

Я не совсем понимаю, как связаны join и sql? Для операции join строго говоря, нужна только связь по каким-то ключам, sql не нужен.


Ту же аналику, основанную на событиях, которые обычно делают через всякие системы типа elasticsearch и clickhouse использует просто куча народу, но вот join'ов нет ни там, ни там.


То, что прикручивают sql это не очень показатель полезности sql, а скорее всего просто инетрности.

То, что прикручивают SQL — вызвано огромной трудоемкостью написания запросов на JSON и нежеланием людей, занимающихся BI и data science трахаться со скобочками и прочими ассемблеро-подобными «радостями» вместо собственно работы.
«Незнайкам в NOSQL» пора бы уже узнать, что в mongo api вообще нет никаких скобочек и json-а.

Вообще, если абстрактно, то по моему опыту прикрученный к некой системе SQL, которая не является СУБД, обычно является жалкой пародией на SQL, где любая команда может отсутствовать или работать не так.
Я не знаю, API для какого языка (Java?) вы имеете в виду — но то что язык запросов Mongo основан на JSON — это «медицинский факт», в какие обьекты бы его не заворачивали.
Про «прикручивание» SQL к документо-ориентированным СУБД — согласен, получается часто не очень. Те же Postgres и MySQL хранят документы гораздо эффективнее для большинства бизнес задач. Но выхода нет — на волне хайпа в NOSQL инвестированы огромные деньги, созданы хранилища и бизнес требует наконец-то начать извлекать из них какую-то аналитику. Вот тут-то без SQL и наступает облом.
>но то что язык запросов Mongo основан на JSON — это «медицинский факт»

Нет это бред ;) Открывай api.mongodb.com и просветляйся.
Вы сами читали сайт на который ссылаетесь? Там же черным по белому написано что все эти функции и методы кодируют/декодируют данные в формате BSON, который и является основным для Монго.
en.wikipedia.org/wiki/BSON
>«но то что язык запросов Mongo основан на JSON»

Не юли, программисты, работая с Монго в запросах JSONа вообще не имеют. Точка.

В результатах есть JSON или нет зависит от желания прогера. Вообще, BSON клёвая штука, местами круче POJO. Но вам, программистам SQL, не понять…
«ИМХО — самой популярной вариацией в ближайшие 5 лет будет бессхемная DB с широкой поддержкой SQL, но с урезанной консистентностью транзакций»

Если из фразы выше убрать SQL получится вылитый MongoDB. Что самое смешное, с точки зрения java программиста API Монго просто два шага вперёд по сравнению с архаичным SQL. Даже если не учитывать во что превратили SQL различные вендоры, перетягивая одеяло на себя. В итоге надо знать в 3 раза больше команд, а в каждой РСУБД ещё и своя специфика по оптимизации. Вот уж не надо больше нам такого счастья. Я это всё говорю как человек который знает SQL намного дольше, чем java. Познакомился с Mongo, забыл SQL как страшный сон.
Это смотря что делать. При первом же запросе вида «в какие еще филиалы обращаются клиенты, посетившие филиал X» адепты NOSQL начинают бледнеть и предлагать замутить «какую-нибудь другую» аналитическую БД и реплицировать туда данные.
Ну и любимая фишка Mongo — когда после первой же операции запрос теряет связь с коллекциями/индексами и начинает вертеть данные в памяти — тоже изрядно достает когда данных много.
Это еще не говоря об аналитиках — которые так и норовят спросить, почему в 70е уже можно было писать запросы на практически обычном английском, а в 2018 их вдруг надо формулировать с помощью каких-то чудных скобок и корявок.
>запросы на практически обычном английском

Как закончивший иняз скажу, что это глупости про «обычный английский». Как только начинаются трехэтажные select-ы into, partition by, rownum() и прочее подобное, читаемость SQL кода падает в НОЛЬ. Причём смешно, ДБА который этот запрос писал уже через несколько дней не может понять что там и зачем. Про удобство отладки молчу. Ещё и нельзя местами переставить например limit и order, что есть показатель нереальной продуманности SQL.

Правильно пишешь, что SQL придумали в лохматые 70е НЕ для программистов, а для околокомпьютерного сброда типа менеджеров. Менеджеры его так и не осилили, а для нормального программиста он убог. Народная мудрость: сделай систему, которой сможет пользоваться идиот и только идиот станет ей пользоваться.

>«в какие еще филиалы обращаются клиенты, посетившие филиал X»

В Монго это элементарно делается, причём несколькими способами. Для современного Монго скорее всего обратных примеров будет больше, когда «сделай это на РСУБД и чтобы отрабатывало за милисекунды» заставит бледнеть SQLных свитерков ;)
По поводу SQL — мне абсолютно все равно для чего его придумали. Сегодня деньги платят за быстрое внедрение новых возможностей и поддержку работы аналитиков. Пока на Монго и то и другое банально дороже раза в два.
По поводу запросов — а давайте вы пример приведете и мы сравним. Монго-база в пару миллионов записей у меня есть, есть и ее копия в MySQL. Заодно засеките, сколько времени у вас заняло написать и отладить запрос на Монго.
Вы определитесь уже, вы «незнайка в Mongo», бледнеющий с задачи «в какие еще филиалы обращаются клиенты, посетившие филиал X» или крутой архитектор с широким кругозором и в SQL и NOSQL. А то как то не вяжутся рассуждения про стоимость разработки с такими вопросами.

Как javaкодер такое сделаю двумя последовательными запросами, сначала выдернуть IDы клиентов, результат скормить второму запросу в $in. Это будет работать быстрее, чем JOIN в РСУБД. Строчек 5 кода. По компактности кода mongo api вообще в десяток раз лаконичнее самописных DAO для РСУБД, вся эта муть с prepared statements, а потом вытаскиванием данных из resultset. Надо иметь очень альтернативное мышление, чтобы это всё было быстрее и дешевле в разработке чем mongo api.
индюшачья классика. в проде этот кодер получает Error running child: java.lang.OutOfMemoryError: Java heap space и идет читать что такое субд и знакомиться с азами.
Девочка с экселем? Технические специалисты вроде должны знать, что вытащить 1млн LONGов даже из РСУБД это вопрос 2 сек. Другой вопрос, откуда уже миллионы взялись? Столько клиентов в филиале? :))))))) Для справки — у самого крупного в РФ холдинга-околонефтегазика с порядка 50 филиалов список контрагентов меньше 40k. Вижу, что с 1 июня по 1 сентября не включительно тут одни воротилы сидят, никакие нефтегазики рядом не лежали :)))
нет, мальчик с хадупом и вот таких вот индюшат поучатель. сначала он был лист лонгов, потом понадобилось имя, потом баланс, потом юзеров таких параллельно тысяча.
вы индусы все одинаковы.
>сначала он был лист лонгов, потом понадобилось имя, потом баланс, потом юзеров таких параллельно тысяча

Эк фантазия разыгралась. Потом все жители планеты ломанулись, а ты один весь в белой шляпе на Хадупе.
Имеется в виду клуб покупателей сети супермаркетов. За полтора миллиона клиентов, несколько сот филиалов, миллионы посещений в неделю. Аналитический портал имеет 40-50 параллельных сессий.
Успехов в притаскивании «миллиона LONGов» — там таких KPI еще штук 20-25 кроме названного.
>Имеется в виду клуб покупателей сети супермаркетов

Я прогер, а не телепат. Какое «ТЗ», такой ответ. Изначальный ответ был про «несколько способов», чего ты разумеется не заметил. Живи и дальше с верой, что твою задачу на NOSQL ну прямо никак не решить. Не забудь почаще эту мысль до начальства своего доносить, а то вдруг тоже в один прекрасный день на мороз пойдёшь.
Ты так ничего и не понял. Мою задачу можно решить хоть с текстовыми файлами — просто будет медленно и дорого. А начальство мое занято совсем другими проблемами, гораздо более важными для бизнеса. Меня с коллегами и наняли вместо тех идиотов, кто пихал Монго во все дыры — потому что у них транзакция занимала до 6 секунд, а у нас редко превышает 40 мс.
>Меня с коллегами и наняли вместо тех идиотов, кто пихал Монго во все дыры

Соболезную твоему начальству, вместо идиотов пихающих во все дыры Mongo пришёл идиот, пихающий SQL. Хотя, причина уже и понятна, какая зарплата, такой и архитектор.
Слив засчитан — нормальный пример реализации вы так и не привели, а переход на личности пускай останется на вашей совести. Добавите к своим 3-м годам опыта еще 3-4, если повезет — изучите принципы работы СУБД, тогда поговорим.
Но я вам все равно благодарен. У нас есть неплохая статистика по интервью (большинство «юниоров-джаваистов» отсеиваются еще на телефонном этапе) — теперь мы, наверное, даже и звонить таким перестанем.
>изучите принципы работы СУБД, тогда поговорим.

Батенька, не переживай, с тобой больше не пересечемся. Я с SQL работать начал 15 лет назад, но года 4 как выбросил все РСУБД из проектов. Удачи тебе в довлении над девочками с экселем и вешании лапши начальству, что лучше тебя только Чак Норрис!
Превед! MongoDB 4.0
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
На месте вашего бывшего ораклиста, я бы радовался каждому дню проведенному вне этой помойки — так как уровень технических решений вы нам очень хорошо продемонстрировали.
Коллега Yo1 уже все сказал. Вместо искомых пары десятков записей про филиалы вам придется таскать по сети и хранить в памяти миллион ID клиентов — от СУБД к серверу и обратно для второго запроса.
А еще у нас есть девочка-аналитик. Она пишет свои SQL-запросы без всякого участия программистов, рисует графики в Excel и это отлично работает. Некоторые мы потом оптимизируем и выкладываем на портал для клиентов, некоторые нет — но на Монго, да еще и с участием «javaкодер-ов» это было бы на порядок дольше и дороже.
>А еще у нас есть девочка-аналитик.
>Она пишет свои SQL-запросы без всякого участия программистов

Ну я очень точно описал ситуацию ещё несколько дней назад. SQL язык для околокомпьютерного сброда в конторах где на R-программистов денег не хватило :) Так бы и писал сразу, что SQL-обезьянки дешеле, тогда бы и спора не было.
Причем тут R? Вам уже третий раз обьясняют — данных много, таскать всю базу по сети и обрабатывать на сервере приложений никто не станет. А запросы (т.е. когда фильтры и преобразования выполняются сервером БД) в R выглядят точно так же как и в других языках.
И последнее — работа системного архитектора как раз и заключается в нахождении путей сделать «быстрее и дешевле».
«таскать всю базу по сети и обрабатывать на сервере приложений никто не станет»

Я нашему бывшему ораклисту (да, его позднее ушли попой в мороз) показывал фокус, когда даже с тормозным Ораклом оказывалось в несколько раз быстрее скачать весь dataset (вообще говоря на линейное чтение плоских данных в РСУБД не хуже NOSQL), обработать на сервере приложений и вернуть результат.

РСУБДшники такие смешные, не знают, что ядро РСУБД на порядок тормознее нормального ЯП.
человек с индуской внешностью лжет. ядро субд абсолютно всегда быстрее. скорость в nosql обеспечивается заметно более медленной обработкой, но в параллель. всякие хадупы много медленее ядра оракла, но из-за того что легко поднимают сотни и тысячи параллельных процессов на гораздо больше кол-ве узлов обгоняют. но в одном потоке, тащить данные по нетворку на апп сервер, это всегда медленее. апп сервер ничего не умеет, чего бы не умел pl/sql
>ядро субд абсолютно всегда быстрее
>апп сервер ничего не умеет, чего бы не умел pl/sql

Спор старый как мир, хранимочки vs аппсервер. Только весь приличный бизнес на java и аппсерверах, а за хранимочки всякие маргиналы и продажные душонки типа Томми Кайта ;)
весь приличный бизнес идет в бигдата, где за попытку вытянуть данные на апп сервер убивают на месте. все бигдаты обрабатывают данные там же, где данные хранятся.
>все бигдаты обрабатывают данные там же, где данные хранятся

Только что мне PLSQL впаривал. У тебя какая-то болезнь, пишешь невпопад. ВСЕГДА тянуть данные на аппсервер это тебе тоже не я, а голоса в голове предложили.
боюсь болезнь именно у тебя. кстати, тот эпизод, когда весь отдел ухахатывался на твой тупизной, а ты не мог понять чего смеются. они смеялись вот по этому
Я нашему бывшему ораклисту (да, его позднее ушли попой в мороз) показывал фокус, когда даже с тормозным Ораклом оказывалось в несколько раз быстрее скачать весь dataset

не надо качать весь датасет, люди буду смеяться
Смех без причины, признак ораклиста? Хочешь блеснуть на деле, а не во влажных мечтах? Ты обещал на PLSQL это сделать быстрее, чем я на чём-либо другом. Итого есть такой список недействительных паспортов РФ (на тот момент 110млн), его обновляют не дельтами, а выкладывают каждый день новый полный срез. Описания нет, так что не будем проектировать обработчик с ожиданием, что новые данные пишутся в конец. Задача — иметь в базе полный список каждый день. Удачи тебе со 100млн INSERT-ами в день. Или на «могучем» PLSQL делать HASHSET. На java это всё обрабатывается за десятки секунд, даже если вытаскивать из Оракла предыдущие 100млн. Если хранить предыдущий файл, то надо несколько секунд и гига 4 ОЗУ.
Типичный признак Java-иста — написание страниц кода там где все остальные использовали бы оракловский SQL*Loader
я же говорил что индюшатину за весту чую. pl/sql в такой задаче не нужен. у меня подобные задачи решаются созданием external table, когда приходит новый файл, делается create or replace directory, которая указывает на новый файл. дальше обычный MERGE между extranal table и основной. т.е. команда MERGE into main_table… WHEN NOT MATCHED THEN INSERT…
вот это, да. займет пару секунд. а вот вычитать в апп сервер по jdbc 100 млн строк что бы вычислить дельту уйдет вечность только на выкачивание. классика индюшатины, не слышавшей о MERGE.
>займет пару секунд

Написал бы «пару милисекунд» чтобы уж точно победить в этом споре. У того ораклиста тоже всегда всё летало… и терабайтные базы и тысячи пользователей. ;)
в отличие от индюшатины у меня образование и серьезный опыт. в том числе и жава и хадупах и многом другом. потому я прекрасно понимаю сколько написать. MERGE на таблички по 100 млн запустит хеш-джоин между основной таблицей и external, их фулсканы займут несколько секунд. а вот тащить 100 млн по jdbc в одном потоке точно дело не пары секунд и на несколько порядков более затратое дело, чем MERGE.
>у меня образование и серьезный опыт

Ага, «воинствующий ораклойд» в белой шляпе )
«А мужики-то и не знают»(с). Такую чушь я даже не знаю как комментировать — разве что датасет у вас был записей эдак 10-15.
Расскажите мне, о величайший — куда и что вы будете скачивать, если размеры датасета превышают обьем памяти на вашем сервере? Раз эдак в 5 как минимум? Кстати, в нормальных NOSQL-решениях тоже никто весь датасет никуда не качает.
Датасет был 100млн Long-ов. ;)

>если размеры датасета превышают обьем памяти на вашем сервере

Я уже понял, что ты большой фантазёр. Столько «а если» в каждом сообщении.
Это не я большой фантазер — это у тебя с памятью плохо. Обьяснял же — полтора миллиона записей о клиентах плюс несколько миллионов транзакций в неделю.
странный поток сознания. какую строчку ни возьми, если не полная чушь, то во многом. то что к nosql дают возможность 2pc транзакцию на несколько «документов» не значит, что это вытеснит более примитивные режимы. если взять происходящее во всяких багдата/хадупах, то хорошо видно что консистентность из базы не столь уж кого-то заботит и т.д. и т.п.
особенно повеселило восхищение майкрософтом, учитывая, что flashback query в оракле уже лет 8 доступны.
Темпоральные базы данных — да, это зачётная тема. В своё время довелось с помощью идеи двумерного времени вытащить пару больших и дорогих проектов из идейного тупика. Притом, что забавно, SQL использовался самый обычный, безо всяких специальных наворотов.

Пользователи, конечно, сначала шалеют от того, что им теперь можно править данные в любом периоде — хочешь задним числом, хочешь передним. У постановщиков задачи со стороны Заказчика, конечно, мозг закипал, когда я им рисовал картинку, в которой время и по иксам, и по игрекам.

А потом приходит GDPR и мы разрабатываем новые СУБД, который с одной стороны все из себя темпоральные и всё хранят вечно, но с другой стороны, если какой-то чиновник хорошо попросит, то тут же удаляют, и тоже навечно. :)

Тут штука в том, то «право на забвение» и «удаление данных» весьма разные вещи. Единственное, что их объединяет — это то что в конце-концов некие данные исчезнут. Но на этом всё.
Время, за которое данные должны исчезнуть, требования к консистентности и к транзакционности в процессе исчезновения данных и др. — всё это отличается. Одно дело — данные должны исчезнуть, и на исполнение этого решения нужно некоторое время, и совсем другое, когда данные должны исчезнуть немедленно, в рамках вот этой вот конкретной транзакции. Удаление данных непосредственно связано с аналитикой, право на забвение — не связано.
Поэтому GDPR никак не помешает консистентности темпоральных БД.
Где я был последние 5 лет?!
Автору спасибо за краткий обзор всего и за кучу ключевых слов по которым я пошел читать и учить что происходит в мире баз данных сегодня.
Спасибо за статью, прочел огромным с удовольствием, хоть и не совсем согласен. Ряд категоричных утверждений например про: times series… под капотом сидит Postgres. Ну фиг с ним. Или вот, например, про Redis:
Мы видим продукты, которые стали заложниками своей изначальной простоты, и они будут отваливаться, потихонечку уходить в небытие.

Тут меня прям бомбануло, простите. Давайте на примере Тарантул. Я слышал что тарантул раньше использовал sophiadb. Это довольно простой движок по сравнению с текущим как я понимаю. Два года назад на тестовом стенде тарантул за неделю успел как потерять данные при записи (тут в драйвере скорее всего была ошибка, не стал разбираться), показал намного худшую производительность (точных цифр не помню, но прям со свистом, раз в 10 на записи и в пару раз вроде на чтение vs SophiaDb) И наконец развалиться без какой либо возможности восстановления. Плюс отсутствие возможности юзать как апликейшен сервер из-за лимитов луа по памяти, и получился полный проигрыш по всем фронтам. Вроде бы движок мощнее, а смысл? Мы вынуждены были написать свой сервер на sophiadb и за два года, не возникло ни одной проблемы на нем, хотя и нагрузка выше, и падения серверов пережила база. Хотя казалось бы, в нем нет и половины фич тарантула. И вот если с первой частью статьи я почти везде согласен, то чем дальше — тем страшнее. Не превратитесь в Кассандру, Тарантул, в погоне за фичами. ps: выбираем жене машину — хочет — чтобы она была — быстрая, большая, проходимая, и камера и парктроники, и спереди и сзади и чтоб пищала когда сбоку в мертвой зоне и чтоб не хенде всякие и не дороже хенде и не б/у конечно. Так и клиенты — они много чего хотят от субд, пока не поймут, что иногда лучше меньше

Плюсую, Redis вообще ругать трудно за что-то, ибо продукт идеально делает то, что заявлено. Взять тот же StackOverflow — они серьезно там его используют и крайне рады.

Захотелось сказать, что "это слишком сложная штука для понимания широким кругом разработчиков" — можно так же сказать про интернет протоколы, что, впрочем, не мешает широкому кругу разработчиков им пользоватся.

Спасибо за большое количество информации по NewSQL (который есть в заголовке). Возможно это я такой заторможенный, но из всего этого семейства в сколько упоминался только таракан.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.