Tarantool 2.8

Оно где-то используется за пределами mail.ru?

мои коллеги в финтехе используют

Можно чуть поподробнее про сценарии использования? И почему выбрали именно этот продукт? Какие были альтернативы при выборе?

Мысле о скалярной природе данных и невозможности натянуть ее на ОО модель категорически отказанно в парковке в головах программистов. Отсюда и NoSQL с JSON-нами. Потом, внезапно как всегда, выясняется, что без кластеризации и in-memory вот это вот все объектно-ориентированное наслоение работать не может. И как вишенка: ради того чтобы не использовать SQL + RDBMS переизобретается что? Правильно! Поддержка SQL и всех сущствующих фич RDBMS.

У меня картинка в глазах отпечаталась! Как убрать, теперь обои окно и даже моё пузо с этим логотипом, боюсь в зеркало смотреть!

А так, прикольна, документация очень хорошая (глянул по диагонали). Жаль что сходу докер лезет, лучшеб без него доку, как взять, скомпилять, поставить и дальше уже по доке.

Тарантул интересный. Даже странно что его популярность не очень.

Даже странно что его популярность не очень.

Видать, потому что его возможности на практике «не очень»))

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

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

Так и скажи, что это никому не нужно и без него люди мутят делишки. А когда проект выше всех на голову ему и реклама особо не нужна, расхватают как горячие пирожки.

Щас этих nosql поделий как на собаке блох и каждое из них очередное ненужно. Тренд за newsql, впрочем и там если у тебя не копрорация, то опять же ненужно. О малом и среднем бизнесе копроразрабы не думают и не заморачиваются.

Дело не в самой системе типов сверху хранилища. Систему типов можно сделать динамической и многовариантной. Т.е. создавать те же объектные представления данных «на лету» для того кода, который работает с данными в объектной семантике.

Дело в нижележащем K/V-движке, который заточен под точечные запросы, но не заточен под эффективное сканирование диапазонов. Именно поэтому «нахлобучивание SQL сверху» на K/V дает, в лучшем случае, сомнительный результат. Cassandra, например, тупо отваливается по таймауту, если сканирование по любой причине получается слишком долгим. Полагаться на эту операцию в C* нельзя вообще.

Ты всё верно говоришь. Просто в NoSQL сделать что-то «выше всех на голову» сейчас будет очень сложно. Оно и так уже предельно вылизано. А, как я сказал в посте выше, нахлобучивать сложные системы типов поверх K/V — так себе занятие.

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

Да. Идёшь на сайт, открываешь раздел с кейсами, смотришь.

Немного странно в этой теме то, что оно однопоточное и при этом требует дикое кол-во памяти. Сервера это обычно много ядер с низкой частотой, а тут нужно совсем мало ядер с высокой частотой. Смахивает на десктопное железо, но много памяти это не про десктопы. Да и что это за «сервера» без ECC.

Потому что многопоточность - это синхронизация, а синхронизация - это долго.

Оно не «однопоточное» в узком смысле. Внутренняя архитектура Тарантула очень хорошо шардируется. «Поток на шард» — это нормально для операционных БД, в которых преобладают точечные запросы. Логика простая: если worker thread занят на 100%, то пора делать новый shard. Так удастся лучше утилизировать CPU по сравнению с тем, если бы использовались разделяемые данные и блокировки.

Тут архитекторам системы нужно отдать должное. В рамках выбранной ниши архитектура системы хорошо продумана (акторы, файберы и всё такое). Главное — не ждать от этой архитектуры чудес за пределами её зоны эффективности (линеаризуемые транзакции, single writer, single reader).

Дело не в базе. Они постоянно упоминают сервер приложений. Там типа как в node.js, но lua. Могло бы и взлететь. Но вот почему-то не взлетает до сих пор.

Оно не «однопоточное» в узком смысле. Внутренняя архитектура Тарантула очень хорошо шардируется.

Тут проблема в непропорциональности нужного количества памяти и количества ядер в современных процессорах. Судя из их описания два инстанса на одном сервере выжирают 250ГБ памяти на одном сервере. А типичный современный сервер нынче это порядка 16 ядер и больше. И где столько памяти брать? Ядра это дешевое горизонтальное масштабирование, к которому пришли эволюционным путём. А масштабировать новыми серверами это приблизительно как менять авто когда пепельница заполнилась.

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

Сервер приложений решает проблему доставки вычислений к данным. Обычный же noSQL — это доставка данных к вычислениями. Просто файловая система без лишних сущностей и возможностей.

Я потому и сказал, что оно требует высокой квалификации для работы. По сути, придется писать свой движок БД над такой штукой. Слишком уж она низкоуровневая, несмотря на всю свою систему типов.

Обычно остальные ядра обрабатывают данные, которые из базы получены.

Хотя я наверное больше про бд типа level db/dbm/lmdb думаю - то есть те, которые как либа подключаются и по сути представляют гигантский хэш (или ordered map). Поэтому немного удивляет, зачем нужны хранимые процедуры.

Это уже другой вопрос. У нас обычно или аналитика (много ядер молотят большие разделяемые статичные данные), либо OLTP (мало ядер насилуют небольшой объем разделяемых динамических данных). Либо какой-то гибрид, но тут все сильно сложнее. Так как базовых структур данных, которые были бы хороши и для аналитики, и для OLTP — нет. Есть персистентные структуры данных, как в LMDB, дающие single writer/multiple reader с взаимно неблокирующими писателями и читателем, но там будет оверхед CoW-деревьев. Зато полный параллелизм на чтение.

Т.е. вот в Тарантуле выбрали модель шардированных хэшмапов в RAM + WAL + акторная модель сериализации транзакций. Это хорошо для точечных транзакций. Но не хорошо для аналитики, которая хочет читать много статичных данных. Для второго случая нужен LMDB. Он тоже быстр на запись, но транзакции на запись должны быть короткими: «update table set F1 = X where F2 = Y» уже не прокатит. Т.е. прокатит, но все остальные писатели будут ждать. Серебряной пули нет.

Единственное, чего я в Тарантуле не понимаю, так это зачем там файберы для in-memory сценария. Файберы нужны, чтобы амортизировать задержки дисковой и/или сетевой подсистемы (выполняется тот файбер, для которого уже пришли данные).

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

Докерфайл по сути это и есть та самая дока, как взять и поставить.

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

Поэтому немного удивляет, зачем нужны хранимые процедуры.

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

Именно. Те бд я, которые я привел и есть «на стороне бд». Только там не что-то вставляется в бд, а бд сама вставляется в приложение и даёт интерфейс (api) обычной хэш мапы (почти) - хочешь, получай по ключу, хочешь - итерируйся.

Вот когда надо по сети ходить, тогда да. Хотя в простейшем случае можно сделать ключи упорядоченные и получать по диапазону, как, например, в etcd сделано.

Уровень экспертизы мне почему-то напоминает плоскую землю и чипирование прививками :)

нужны большие рекламные бюджеты. Вот когда Tarantool будет мне мелькать в рекламе так же, как мелькает Neo4J, вот тогда её популярность начнет резко расти.

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

Идея о том, что «нормальный продукт люди сами найдут» предполагает два условия:

1. Есть всё же некий дефицит на рынке, который бы заставлял людей искать.

2. Ищущий способен сам сделать рациональный выбор, не оглядываясь на толпу и авторитеты.

По обоим условиям в области БД полный жесткач. Без агрессивной рекламы ты просто не существуешь. Область консервативная, и чтобы реально попробовать что-то новое, нужно именно убеждать людей. Причем массы людей, которые рациональные аргументы вряд ли поймут правильно.

make sense

p.s.

другое дело, что выступления на конференциях - это способ лучше, чем просто реклама. никто ведь не страдает от того, что продукт mail.ru не стал популярен. кому надо, услышали на конфах. кому не надо, не услышали. я за ограничение информирования в специальных, тематических рубриках.

Да, я тоже согласен. Я к тому, что mindshare тоже необходим, и одними только конференциями его не создать. Нужно «А, так вот тут рассказывают про тот самый Тарантул. Пойду послушаю.» Эффект «знакомого слова». Так наше потребительской общество работает, и программисты — такие же потребители, как и все остальные.

На меня постоянно выходят всякие «продавцы технологий», чтобы рассказать про свои продукты. Причем я — совсем не ЛПР у нас. И несмотря на это, они готовы тратить свое время на презентации конкретно мне. Потому что это mindshare. И если мне продукт понравится, то я буду его предлагать использовать внутри компании. Этакое «жжж снизу».

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

А что поделать?)

С волками жить — по волчьи выть.

Чела того, кстати, можно было изящно ткнуть носом в тот факт, что для RH CentOS был именно способом завоевания mindshare и рекламным проектом. В конце-концов проект решили свернуть, но сделали это как-то совсем некрасиво. Фу быть такими.

А, вы тоже центось в продакшене на дофига машинах крутили? 🤭

CentOS был именно способом завоевания mindshare

я это и имел ввиду, вроде бы это самоочевидная вещь, а вот слово это у меня не в ходу.

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

Сподобился не вляпаться в это дело. Облака подоспели и спасли меня от этого. Но таки CentOS я крутил в виртуалках еще до того, как это стало нормой.

А можно в двух словах студенту второкуру пояснить, в чем отличие в областях применения sql и nosql? Где он будет лучше и выгоднее чем традиционный sql? Ну на примере хотя бы вот этого тарантула?

что, прости?? звездочки справа, 5 штук. вопрос по аватаре, что на ней, или у тебя что-то с версткой?:)

Да, я про именно твою аватарку. Мне показалось, что там звездочка октябренка.

Чувак, ты неправильно ставишь вопрос. Тебе нужно понимать, как эти вещи работают «под капотом», и тогда вопрос отпадет сам собой. Не просто отпадет, а ты будешь знать, какая БД для каких нагрузок подходит лучше.

Вот, например, тот Tarantool в варианте дискового хранилища использует модный LSM-tree, у которого есть некоторые важные свойства, определяющие зону применимости этой структуры данных и БД, над ней построенных. LSM могут очень быстро принимать данные (на запись), но ограниченное время. Они хороши для всякого рода веб-магазинов, для которых есть проблема внезапного 100х-наплыва пользователей. Нахватал за час заявок — и потом неделю обрабатываешь.

По той же причине LSM-tree себя очень хорошо показывают в микробенчмарках, где время записи ограничено. Но из-за деградации структуры дерева и необходимости фоновой сборки мусора LSM-tree не могут держать высокую интенсивность записи долго. А еще для них надо резервировать как минимум 2х место на диске, для слияния сегментов. Но там, где нужно держать очень высокую пиковую нагрузку на запись — они незаменимы.

И вот если ты будешь понимать, как различные БД внутри хранят и обрабатывают данные, а это не rocket science, то ты поймешь, где, что и как использовать. Причем экспертом (в узком смысле) по БД для этого становиться не обязательно.

это alter ego. изображение с надгробья (crypt). на нем скорее всего херувим в рафаэльской традиции. в других традициях есть изображения ангелов с шестью крыльями, отсюда твоя ассоциация со звездой. советская символика не оригинальна, она заимствовала то, что уже было. однако, тему ты поднял не в токсах. поэтому, если ты захочешь еще что-то спросить, либо переносить ее туда, либо в личную почту.

на нем скорее всего херувим в рафаэльской традиции

А, точно! И про не-оригинальность согласен. Ладно, закроем. Я любопытство удовлетворил, спасибо!)

не вопрос) я на своем почтовике генерю временные емейлы. мне несложно.

А не могли бы вы порекомендовать литературу, желательно более-менее качественную, чтобы понимать как под капотом работает хотя бы sql, хотелось бы на русском (да, я знаю что без английского никуда, я именно на него сейчас и трачу больше всего времени, три часа в день, у меня была хорошая физ-мат школа с просто отвратительным преподаванием английского - провинция), но если нет на русском - можно и на английском. У нас препод сишник хороший, сам работал и работает, а вот sql объясняют женщины которые при превосходном знании математики, в реальном программировании - ни в зуб ногой…

Книги, тем более «на русском», тебе не сильно-то помогут и на твоем месте я бы не тратил на них драгоценное время. Что я могу рекомендовать — это поковыряться в трех движках — LMDB (Copy-on-write B-tree), SQLite (B-tree + WAL) и RocksDB (LSM-tree). На мой взгляд, наиболее вкусная и перспективная из них — LMDB, но у неё код отвратительный. Можно брать BoltDB на Go — там получше.

Вот эти три движка тебе дадут в сумме 90% необходимых представлений о том, как работают дисковые БД. Хакай на здоровье, присоединяйся к проектам, присылай патчи, и всё такое)

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

А документация у кого лучше? И еще, хоть где нибудь математический аппарат описан? С матаном (в самом общем смысле) проблем нет - разберусь во всем, просто не пойму куда смотреть?

Начинать лучше всего с LMDB. Несмотря на, как я сказал, отвратительный код, идея (и её реализация) у этой БД самые простые. Ищи любую инфу по Copy-on-Write BTree. Для начала пойдет даже статья про персистентные структуры данных на Вики. А дальше попробуй такую структуру данных поднять просто в памяти, на любом удобном языке. Фишка CoW b-tree в том, что там данные никогда не перезаписываются поверх старых, поэтому она может надежно работать в транзакционном режиме над mmap.

CoW b-tree умеют атомарно сбрасывать состояние из RAM на диск, не требуя для этого WAL. Автоматом получишь актуальные представления о том, на каком принципе работают ZFS и BTRFS.

Спасибо. Идею понял.

Тарантул интересный. Даже странно что его популярность не очень.

Как высказался мой батя о ГКЧП: «Идея неплохая, но исполнители…».
Видимо подспудно ожидается, что вместе с тарантулом в систему проползет Amigo.