Mail.Ru Group анонсировала коммерческую поддержку для СУБД Tarantool

По сабжу: от мэилру груп в целом больше пользе чем от яндекса

Хороший наброс, но нет. От меил-ру пользы вообще нет, в отличии от яндекса.

LMDB - key-value? Так навернуть сверху SQL - и что получится в итоге?

SQL составляет 0.5% проблемы. В лучших домах Парижа его так или иначе компилируют в машинных код, и избыточность получается минимальной по сравнению с ручным кодированием. Что до джоинов, то тут совсем другая история, товарищи из лагеря NoSQL запудрили аудитории мозги. Там всё упирается в производительность сети и на 10GbE уже совсем не проблема. Хотя раньше была, да.

Был уверен, что чтение в версионниках - всегда wait-free. И «предыдущая версия данных» будет «жить» до тех пор, пока живо хоть одно «чтение/транзакция», начавшееся до окончания очередных «изменений».

Ну вот сама базовая структура данных, обеспечивающая такое разделение, она же не волшебная. Всё это состояние должно где-то храниться, и к нему должен быть совместный доступ. И если она не wait-free, то в итоге wait-free не будет, а будет просто меньше блокировок. Что тоже хорошо. Плохо же то, что сам такой стек оказывается довольно тяжеловесным и замедляет короткие, самые типичные, транзакции.

В противовес этому в CoW B-Tree именно самая базовая структура wait-free, потому что (1) пути записи и чтения всегда разнесены в пространстве и (2) писатель может быть только один. Можно сделать несколько параллельных писателей, но мы теряем wait-free (на самом деле нет, но реализация становится непрактичной), и мы огребаем еще кучу других проблем.

Если мне не изменяет эрудиция, то Sophia (storage engine от Tarantool), реализована именно по этому принципу (SWMR CoW). Так что заявления команды в целом соответствуют действительности при условии, что БД используется на флеше или в памяти. Да, с помощью Tarantool иногда можно, при наличии прямых рук и светлой головы, сэкономить кучу денег за счет отказа от «традиционных СУБД», которые на современных машинах тупо не эффективны из-за изменившейся модели памяти. Просто если уже делаются такие заявления о превосходстве, то принято приводить результаты тестов.

у гугла, только лучше.

А ты попробуй открыть гуглдиск в огнелисе и перебросить в него каталог.

Увы mail.ru приобрела дурную славу, но техническая команда очень сильная.

Ну, оно вроде как-то работало. Но по ночам админы ооой как часто просыпались из-за засранного тарантула :) Но это было пару лет назад, сейчас, возможно, все в лучшую сторону ушло.

Слишком много MAIL.RU в последнее время.

так они же всех купили.

теперь перед тем как кричать «говно», придется начать разбираться в сортах Мэйлры, потому что Obsidian это скорей хорошо а они их тоже купили

что такое «засиралось» применительно к тарантулу?

А что вы с ним делали?

Скорее, это применимо к программистам компании-производителя :).

Это надо спросить у mail.ru.

мэйлру что-то придумало, «нужное» для мэйлру

так мэйл.ру и виноват в том, что к нему такое отношение. Нефиг агрессивно навязывать всем свои свистоперделки.

SQL составляет 0.5% проблемы.

На одной таблице - да. На трехзвенке - да (наверное). На развесистой базе с отношениями, с целостностью, с триггерами/процедурами/вьюшками и прочим на базе кучи таблиц - совсем не уверен.

Всё это состояние должно где-то храниться, и к нему должен быть совместный доступ.

временные метки, опять-же, wait-free на чтение

Плохо же то, что сам такой стек оказывается довольно тяжеловесным и замедляет короткие, самые типичные, транзакции.

Кому короткие - самые типичные, а кому одно изменение - транзакция с логом в базе, с изменением в связанных таблицах, с отработкой процедур/триггеров, с коррекцией индексов, с подтверждением о завершении транзакции, и главное - с обеспечением целостности. Т.е. на одну «типичную» транзакцию необходим не один десяток «элементарных» ins/add/del в куче таблиц. Вот чем мне здесь поможет CoW - в упор не вижу. Над одним писателем всё равно придётся городить огород разбора множественных одновременных запросов на запись: очереди, блокировки и хз еще что. Иначе половина работы нормальной RDBMS перекладывается на чьи-то плечи, или опять-же сужается область использования БД.

Да, с помощью Tarantool иногда можно, при наличии прямых рук и светлой головы, сэкономить кучу денег за счет отказа от «традиционных СУБД», которые на современных машинах тупо не эффективны из-за изменившейся модели памяти. Просто если уже делаются такие заявления о превосходстве, то принято приводить результаты тестов.

Понятно, любой фейл будет автоматом говорить об отсутствии прямых рук или светлой головы.

Вот когда 1С-ка заработает на Тарантуле в 10 раз быстрее - поверю :)

Кому короткие - самые типичные, а кому одно изменение - транзакция с логом в базе, с изменением в связанных таблицах, с отработкой процедур/триггеров, с коррекцией индексов, с подтверждением о завершении транзакции, и главное - с обеспечением целостности. Т.е. на одну «типичную» транзакцию необходим не один десяток «элементарных» ins/add/del в куче таблиц. Вот чем мне здесь поможет CoW - в упор не вижу.

Давай вспомним, что мы сравниваем «классическую СУБД» с in-memory. Разница между ними в базовых структурах данных. Первые всегда упирались в медленный диск и для них блокировочная модель оказывалась наиболее производительной, что определило все дальнейшие параметры архитектур баз данных на 3 десятка лет вперед. MVCC здесь лишь оптимизация, позволяющая сделать блокировки короче и во многих случаях разнести их в пространстве, но больше ничего не меняется. Т.е. сам стек хранилища, который медленный в современных реалиях, как черепаха, остается: Data path в десятки тысяч инструкций процессора и кучу переключений контекста по пути. Тем не менее, современные РСУБД неплохо так затюнили, что они смотрятся молодцом на многоядерных машинах.

В противовес этому, базовые структуры данных, основанные на CoW-схеме, очень быстры. Data path там может быть буквально несколько инструкций процессора. В результате одна структура в однопоточном режиме может обслуживать больше обновлений в единицу времени, чем высокооптимизированная, но, в остальном, «классическая» РСУБД — в многопоточном. Потому что нет лишних в данном случае сущностей. Не нужно линеаризировать операции доступа к данным, так как нет вращающегося диска. И нет простоев на блокировках в очереди к нему.

В итоге, CoW закончит работу быстрее, хотя латентность индивидуальных транзакций может быть значительно выше. Это справедливо как для коротких транзакций, так и для длинных (трансформаций). Длинные транзакции будут увеличивать среднюю латентность коротких, только и всего.

Над одним писателем всё равно придётся городить огород разбора множественных одновременных запросов на запись: очереди, блокировки и хз еще что.

Совершенно верно. Но это совсем другой уровень разграничения доступа. Проще планировать одну очередь, чем 100000 очередей на индивидуальных блокировках.

Поэтому сейчас все ведущие поставщики СУБД имеют in-memory опцию для тех, кому это очень надо и он готов платить и радоваться.

//Психиатр

Понятно, любой фейл будет автоматом говорить об отсутствии прямых рук или светлой головы. Вот когда 1С-ка заработает на Тарантуле в 10 раз быстрее - поверю :)

Не любой, разумеется. Но, в целом, — да. NoSQL — это инструменты экспертного уровня. Чтобы их правильно применять, нужно уметь пользоваться (а не просто знать) разнообразным матаном и владеть историей вопроса, чтобы не повторять чужих ошибок. РСУБД сильно разбаловали народ, скрыв от разработчика всю магию за относительно простыми интерфейсами. В результате кто-то даже уверен, что там «wait-free на временных метках» ;) NoSQL позволяют добиться более высокой производительности за счет управляемого расслабления консистентности, специфичного для приложений (ака «не везде нужны транзакции»). Но предполагается, что программист умеет это делать. Как в итоге оказалось, уверенные архитекторы РСУБД этим навыком не владеют.

Но самая большая проблема кроется в другом. Видимая простота NoSQL жестоко обманчива. Из коробки они годятся для практических задач не больше, чем ассемблер — для прикладного программирования.

Простого K/V на практике недостаточно. Денормализация имеет свои пределы разумности. Рано или поздно (а на самом деле — очень быстро) становятся нужны более сложные структуры данных, чем K/V: линейно сканируемые многоатрибутные таблицы, битмаповские и пространственные индексы, многомерные массивы, и много чего еще. Нужны распределенные запросы с сортировкой и джоинами. Энтузиастам NoSQL либо придется всю эту черную магию делать ручками, либо возвращаться на устаревший PgSQL, либо пробовать что-то а-ля VoltDB. Либо устраивать зоопарк из хранилищ где «каждый инструмент под ствою задачу». И получить проблемы уже с этим зоопарком на уровне притирки компонентов.

Практика показала, что никто толком продвинутые структуры данных над NoSQL делать не умеет. Дальше json-объектов в качестве значений дело не пошло. Таблицы Cassandra/HBase сильно избыточны для неразреженного случая. Зато зоопаркостроение пошло и, в общем, делает что-то боле-менее юзабельное.

Возвращаясь к Tarantool и 1C. Если бы мне сейчас поручили что-нибудь такое импортзаместить, я бы попробовал объединиль Tarantool с Presto. Последний — это довольно шустрый и хорошо сделанный федератор SQL-запросов, что дает нам SQL-уровень над не-SQL хранилищами (Tarantool или просто сразу Sophia). Для расределенной консистентности можно прикрутить Raft так же, как его прикрутили к SQLite в ActorDB.

На выходе у нас масштабируемая аналитика, которой не мешает операционная база и более-менее приличный OLTP, которому не мешает аналитика. На отсутствии ETL сразу получается неплохая экономия. Дешево и сердито. Суди сам, какая для такого решения необходима кривизна извилин и прямизна рук.

//Психиатр

Вдогонку начсет сложности разработки высокоуровневых структур данных над K/V.

CoW B-Tree — это K/V и вышеозначенная прблема относится к нему в полной мере. Может показаться, что запилить табличку над K/V проще-простого, но это не так. Нужно запилить не одну табличку а несколько десятков разных. Да разные индексы. Да всё это должно комбинироваться в различных вариантах и при этом оставаться очень легковесным, ибо зачем оно нужно в противном случае? Много мороки.

В HyperDB поступили иначе. Они клонируют адресное пространство процесса со всеми его табличками, индексами и прочим ценным имуществом. Дешево, аппаратно и сердито. Но ограничено RAM.

//Психиатр

lua-nginx-module хорош ровно до того момента пока не начинаешь делать на нем что-то серьезное и не лезешь в его код. А там остается только страх и отчаянье.

Я пользуюсь Яндексом как:

1. собственно поиском --- как основным, потому-что Яндекс сотрудничает со спецслужбами.

2. переводчиком и словарями, но она слабее чем например, Translate.ru

3. у них есть почта, пользуется тёща, у меня тоже есть ящик, и к этой почте имеют прямой доступ компетентные органы.

4. расписанием телепередач и расписанием электричек. На других ресурсах такого нет.

Давайте пользу от Мэйла.СРУ в студию. А заодно можете мне рассказать, что всё это не нужно.

PS Народ использует ещё и бесплатный Яндекс-диск. Кстати, там есть мои фотки над которым ржут админы Яндекса.

--------
Пацаны, исправил таки!

устаревший PgSQL

Хэх, тут некоторые личности орут, что sql сложен и нафиг не нужен, можно ORM-ом обойтись, а тут оказывается надо половину функций RDBMS «взять на себя», и если всё довести до ума «прямыми руками и светлой головой» - вот тогда и придёт счастье...

Не, подожду пока этот «рокет сайенс» спустится к простым смертным. Ладно, пусть не до уровня «ормоклепания», хоть до нынешнего уровня «устаревшего PgSQL» :) Стар я уже «серфить на острие прогресса» ;)

P.S. Спасибо за увлекательный рассказ про БД-шные новинки!

Почему?

CoW сделали на уровне OS — с помощью fork() и клонирования адресного пространства процесса. Дешево и сердито
fork
дешево

Шел бы ты обратно галоперидол по дурке разносить, «психиатр»

Когда мылору название сменит? Несерьезно же, пытается в разные продукты а называется почтой, которой давно никто не пользуется.

которой давно никто не пользуется.

Кроме нескольких миллионов хомячков. И ещё про my.com не забывай

Не, подожду пока этот «рокет сайенс» спустится к простым смертным.

Нормальная стратегия, на самом деле. Исходя из того, что я знаю по этой теме, в ближайшие годы будут появляться очень интересные инструменты, но довольно сложные. Сложнее старых добрых теплых ламповых RDBMS. Так что магия будет в цене.

P.S. Спасибо за увлекательный рассказ про БД-шные новинки!

Всегда рад поговорить с умными людьми!

//Психиатр

fork
дешево

Таки довольно дешево на любых физически доступных размерах памяти, если учесть, что есть huge pages. В HyperDB данные делят на две части — «холодные» и «горячие». Первые лежат в больших страницах, последние — в маленьких. Когда горячих данных немного, а это как раз типичный для OLTP сценарий, форк будет относительно быстрым. Такая вот идея.

//Психиатр

если учесть, что есть huge pages

Ну да, сначала «учитывают», а потом хватаются за голову: чего это у нас процесс в полке по CPU и вся машина тормозит? А это же page split-ы пошли!

А а еще стоит учесть, что создание нового процесса — это тяжелая операция.

Такая вот идея.

Идея, достойная веб-прогромиздов, но не разработчиков серьезных систем.

Идея, достойная веб-прогромиздов, но не разработчиков серьезных систем.

Ну я не знаю, бенчмарки у них в статьях есть. HyperDB продался Tableau и появится в составе её продуктов. Значит, верификация результатов была. Если это не серьезно, то что тогда серьезно?

//Психиатр

lua-nginx-module хорош ровно до того момента пока не начинаешь делать на нем что-то серьезное и не лезешь в его код. А там остается только страх и отчаянье.

Лазил в его код - не очень понравилось, но и не то чтобы отчаянье. Понравилась сама идея связки.

В любом случае, JS и тут собирается вытеснить lua.

А, так это изза вот этой штуки у майла почта тормозить стала.

%program_name% позволяет компаниям оптимизировать работу и сократить расходы на ИТ-инфраструктуру

Куда ж без этого...

Прочитал тред, мои ожидания оправдались. Одна из крупнейших в России ит-компаний разработала и открыла под свободной лицензией (причём именно нормальной лицензией, а не копирастической gpl) свой продукт. Тарантул успешно используется под высокой нагрузкой.
Но нет, десятки кукаретиков набежали сходу визжать. Бирочка им не та, лол. Ещё один такой же упоротый в линукс-хардвейр выбирает клаву БЕЗ надписи «Microsoft». И ни один из этих опсихевших красноглазиков даже не попытался попробовать тарантул.
Кто там сегодня говорил что лор - технический ресурс? Тейлганнер? Лолнет, лор, кроме лолксов и клуба - сборище упоротых фанатиков, которые из треда в тред каргокультируют свои стереотипы.

Да ладно тебе! Ты просто не видишь, или не хочешь видеть, то что «авторитет» мэйл.ру ниже плинтуса! А почему? Я думаю Вы знаете почему. Люди не любят когда им «внаглую» навязывают «услуги». Первые годы терпят, а потом начинается всеобщее и глухое негодование!

Пусть мэйл.ру собирает менеджеров, и думает как же вернуть уважение сообщества. Возьмите что-ли девиз, типа: «мэйл.друг»!