Rabid Transit

#видеозаписи #плюсочетверг Разбираемся с проблемой, для которой не существует доказанного оптимального решения — на какие компромиссы идут разработчики движков хранения данных? Узнайте из доклада: Константин Осипов — Стратегии слияния (compaction strategies) в LSM-деревьях 😉 YouTube | 📺 VK Видео

Доступно видео с моего выступления на C++ Russia про стратегию слияний в LSM дереве которую мы используем в Виниле - дисковом движке для Picodata. Винил продолжает развиваться: в готовящемся релизе 26.2 заменен аллокатор и добавлена поддержка transaction isolation level “snapshot”. На очереди новый tuple cache и нативная поддержка ttl.

Томас Кун в "Структуре научных революций" пишет о том, что революции в науке не происходят через переубеждение оппонентов. Революция - это война школ, и побеждает та школа, которая подготовит более востребованных учеников. В 1999-2000 году я работал программистом на Perl, разрабатывал веб-сайты, интернет магазины. Мне очень нравился этот язык за свою гибкость, выразительность, эффективность. В сравнении Perl vs PHP Perl однозначно выигрывал и с точки зрения языка и с точки зрения зрелости экосистемы. В 2005 году я впервые побывал на FOSDEM- крупнейшей европейской конференции посвящённой экосистеме открытого ПО. Я уже давно к этому времени программировал на С++, но меня продолжала интересовать судьба Perl, Perl 6 в частности. Меня поразило тогда, что стенд Perl совершенно седой - я буквально говорю про волосы как у Гэндальфа у ребят, которые там работали. Несколько часов назад вышел официальный документальный фильм про историю C++. Посмотрите.

Японский аналог Российского "PostgreSQL изнутри" Егора Рогова - "The Internals of PostgreSQL" Hironobu SUZUKI. Кажется, ещё больше ориентирована на разработчиков СУБД чем на DBA, и в отличие от русскоязыной книги содержит больше информации по журналированию и репликации. В целом, обязательна к прочтению, если вы как-то связаны с PostgreSQL - будь то использование, развитие, или имитация.

Пообщались с @alexeyrybak на тему сверх-больших инсталляций СУБД: какие ключевые факторы выбора, ограничения и т.д. За 30 минут живого общения наговорили на long read, сейчас доступна первая часть: https://t.me/rybakalexey/469

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

Интересное движение в MariaDB: pluggable data types. Возможность была в PostgreSQL десятки лет, и является основополагающей для архитектуры СУБД. Должен признать, что будучи выходцем на момент основания Tarantool из экосистемы MySQL я не понимал важность именно расширяемой системы типов, в результате в Tarantool/Picodata добавление нового типа данных требует множества касаний в коде. Реализация в MariaDB до сих пор отстаёт по возможностям от реализации в PostgreSQL - нет возможности задавать компараторы, задавать стратегию индексирования отличную от индексирования встроенных типов. Есть риск что шаг сильно запоздалый - на сегодня есть огромное количество альтернатив для желающих сделать кастомное расширение для СУБД, и не факт что MariaDB будет вверху списка.

Опубликовал свою статью о новом планировщике в Vinyl на Хабр. Это результат работы по проекту импортозамещения Cassandra на основе Picodata, которую мы делали в январе-феврале 2026 года, сейчас код уже полностью доступен в релизах Picodata 26.1 и нашем Tarantool 2.11.8. Лайк-шер-алишер.

Вышел мой подкаст вместе с Кириллом Мокевниным на его площадке "Организованное программирование". Говорим про всё подряд: SQL, NoSQL, будущее СУБД, ИИ. https://youtu.be/_9JhY63Cvtc?si=FeHn0rEBZXlN3_qe Ссылки на трансляцию на российских площадках: - vkvideo - https://vkvideo.ru/video-224967259_456239258 - rutube - https://rutube.ru/video/72d2081f06703cd8bbbefb2bbcfac0be/

Интересный pull request в seastar - выносит весь ввод-вывод на decicated cpu cores. Основная фишка seastar - симметричность и локальность исполнения. Все ядра одинаковые и каждое ядро СУБД делает всё - и обработку данных, и сетевой и дисковый ввод-вывод. В Picodata, например, вводом-выводом занимаются обособленные потоки, а tx thread изолирванно занимается только обработкой транзакций. Планировщик Tokio в Rust может продолжить обработку таски на другом треде, что похоже на Go, но плохо подходит для задач типа СУБД, где локальность кэшей CPU крайне важна (*). Это не значит что у seastar до последнего MR была какая-то неправильая архитектура. Напротив, я бы сказал что в плане эффективного использования ядер seastar – best of the best. Неправильая архитектура скорее не у seastar, а у сетевого стэка Linux и NIC firmware. Старые сетевые карточки умели доставлять и забирать пакетики из 1 области DMA и отправлять прерывания об этом на одно ядро. Новые поддерживают так называемые RX/TX queues – очереди прерываний, с каждой из которых связана своя область DMA. В общем, шардируют входящую очередь по ядрам. Проблема в том что нет никакого способа выстроить сетевой стэк так, чтобы в нужный тебе, то есть локальный для твоего ядра, RX/TX queue прилетали нужные тебе пакеты. С одной стороны маппинг на RX/TX очередь делается по src/dst ip address/port, то есть пакеты одного соединения всегда прилетают в одну и ту же очередь, с другой стороны сама хэш функция определяется сетевой картой, и на прикладном уровне не получится “настроить” входящий и исходящий порты конкретного соединения так чтобы добиться локальности прерываний. В общем случае доставка данных из сетевой карточки требует как минимум одного hop’а от ядра-получателя прерывания к ядру-обработчику данных. При этом seastar поставляется с тулзой perftune.py , которая может настроить отображение RX/TX queue и IRQ на ядра по одной из базовых схем: равномерно по всем либо выделенно на несколько (например, по 1 ядру на NUMA ноду). В отсутствие perftune.py который работает через запись в /proc/irq/<N>/smp_affinity, задачу отдаётся на откуп irqbalance, это такой демон в Linux который следит за равномерностью прерываний и перераспледеляет их между ядрами. perftune.py также включает режим Receive Flow Steering. В этом режиме ядро Linux отслеживает, на каком CPU core последним вызывался recvmsg() для данного потока, и перенаправляет будущие пакеты этого потока на то же CPU core. Так вот, в идеальном мире прерывание должно приходить в то ядро, в которое нужно доставить пакет. В реальном мире прерывания могут приводить к load spikes, то есть паузам в исполнении прикладного кода. Вот чтобы максимально отделить прикладной код от сетевого ввода вывода и предлагается сделать assymetric io_uring backend, который будет обрабатывать ввод-вывод на выделенных ядрах. Очень похоже на то что было сделано в Tarantool 15 лет назад и сейчас работает в Picodata. (*) Похоже ближайшим аналогом seastar в Rust является glommio, который написал Glauber Costa – бывший разработчик из московского Parallels, затем разработчик в ScyllaDB а сейчас CTO Turso :) Возможно, Picodata когда-нибудь выкинет свой runtime, и переедет на glommio.

Обновлял zstd в Picodata с версии 1.5.1 до 1.5.7 и получил результаты которые не могу объяснить: ZSTD | level 3 | level 9 | level 18 | ----------------------------------------------------- 1.5.7, API v2 | 240 MB/s | 107 MB/s | 10.4 MB/s | ----------------------------------------------------- 1.5.7, API v1 | 223 MB/s | 125 MB/s | 35 MB/s | ----------------------------------------------------- 1.5.1, API v1 | 169 MB/s | 124 MB/s | 34 MB/s | ----------------------------------------------------- Тут не так важно, что changelog zstd пишет что значительно улучшена скорость работы на высоких уровнях компрессии, и я этого не наблюдаю. Более интересно регрессия в производительности при переходе с API v1 на API v2. ZSTD_compressBegin/ZSTD_compressEnd объявлены unsafe & deprecated, при этом ZSTD_compress2 работает медленнее. При этом память для компрессии представляем мы, то есть внутренних аллокаций нет, и в целом в среднем на 1 фрейм API вызывается 1 раз. Как видно по таблице, чем выше уровень компрессии, тем выше регрессия от использования нового API. Месиво ещё в том, что более новая версия в теории может лучше/хуже сжимать. Но в ChangeLog я информации об этом не увидел, да и результаты этого не подтверждают. На земле так много непонятного...

Крайне любопытный тред в Cassandra mailing list о том, не реализовать ли в Cassandra поддержку диалекта PostgreSQL. Диалект PostgreSQL пожирает мир баз данных с невероятной скоростью: если только вы не делаете что-то совсем своё, как TigerGraph или Memgraph, то вы выбираете диалект PostgreSQL. Для сообщества Cassandra это вдвойне любопытно, т.к. Cassandra, по моему мнению, реализует один из самых чудовищных диалектов SQL, и тема поднимается не первый раз. В предыдущие разы ответ был неизменно - для AP базы данных нужен AP синтаксис. Видимо поддержка транзакций многое в сообществе Cassandra, которое в целом в последние пару лет переживает ренессанс, поменяла.

Книги прочитанные за отпуск: - Генрих Альтшуллер "Найти идею". ТРИЗ - известный брэнд, а я как-то с сутью метода знаком не был. По результатам прочтения, кажется что метод мне неподвластен. Похожее чувство возникает у меня при игре в любительской лиге "Что Где Когда". Вроде ход мышления знатоков понятен, но если я не знаком с ответом как с фактом, логически до него домыслить я не могу: слишком много "натяжек" и "допущений" должно быть сделано чтобы прийти от вопроса к ответу. Я таких сильных допущений в своих рассуждениях делать не привык. Похожее же чувство от ТРИЗ. Константин Харский "Ценностное управление для бизнеса". Книгу какое-то время назад рекомендовали, после этого попалась на litres и вот. Автор делит всех сотрудников на 4 типа: материалист, эмоционал, виталист, идеолог. Материалист, понятно, в первую очередь движим выгодой, эмоционал - экстраверт получающий удовольствие и энергию от совместной деятельности, виталист заботится о благополучии, балансе, здоровье, идеолог - одержим великой идеей и готов принести в жертву идее всё остальное. Понято, что типы могут комбинироваться в людях, но автор утверждает что в каждом человеке доминируют 1-2 типа. Книга в чём-то похожа на "6 шляп мышления" де Боно, действительно помогает посмотреть на действия разных людей в новом свете. В остальном книга показалась повторяющей уже известные мне (Start with Why, Simon Sinek, например). В целом книгу скорее рекомендую, чем нет. The Art of Gathering, Priya Parker. Книга из моего reading list по фасилитации, содержит (пока что, я в середине) базовые правила о том как надо и как не надо проводить встречи. О том что место встречи должно отвечать цели, о том как фасилитировать коммуникации внутри группы, о том как модерировать, работать с хеклерами и т.д. Мне напоминает что-то вроде учебника для колледжа, но помогает структурировать собственные мысли по теме. В целом не питаю иллюзий что стану сильно лучшим фасилитатором ), но очень хотелось бы, конечно.

Амазон выпустила линейку машин i7* (из России ссылку не открыть) в которой (в облаке) доступно до 192 ядер, 1.5ТБ оперативной памяти и 100Gbps сеть. Это уже привело к серии патчей в seastar которая до этого не умела работать с CPU c более чем 256 ядрами. Теперь seastar поддерживает до 2000 ядер. И совсем непонятно как классические СУБД к этому будут адаптироватья.

В сотрудничестве с университетом ИТМО закончили формировать темы для бакалаврских и магистерских работ. Приятно, что многие ВУЗы сегодня ищут активного сотрудничества с индустрией, и вдвойне приятно что у этого сотрудничества нет корпоративных преград, т.к. взаимодействие идёт на базе открытого кода. Мы также стараемся поддерживать корректную разметку задач в нашем гитлаб чтобы любой желающий мог выбрать тикет для себя и прислать нам патч.

Интересный тренд использовать dictionary-based compression в СУБД. Сейчас это обсуждают в Cassandra mailing list, ранее такую возможность добавила ScyllaDB в свою коммерческую версию. Наилучший эффект достигается, конечно же, на LSM дереве, т.к. только там мы имеем дело с достаточно большими объёмами в одном sstable и append-only работой с диском, но в целом ничего, кажется, не мешает применять и в B-деревьях. Основная проблема в реализации это создание и поддержка актуальных словарей - это бэкграунд работа, которая не должна влиять на производительность системы в целом. В shared-memory парадигме обеспечить конкурентный быстрый доступ к релевантному словарю может быть непросто. Если словарь утерян, расшифровать файл невозможно, поэтому необходимо обеспечить надёжное хранение словаря. В ScyllaDB для этого используется group0 - глобальная Рафт группа объединяющая все узлы в кластере. Похожий принцип управления метаданными реализован и в Picodata.

Никогда не понимал почему индустрия так высоко ставит тест Тьюринга. Умение не отвечать невпопад, безусловно, крайне ценный социальный навык, но вот я, например, никогда им не обладал. На мой взгляд действительный критерий создания Artificial General Intelligence был бы примерно такой: вгрузить в нейросеть всё что было известно Евклиду, и попросить ответить на вопросы, на которые ответил Евклид. Ну или вгрузить всё что было известно про гипотезу Пуанкаре до работы Перельмана, и попросить доказать. Уверен, что это не мне первому в голову пришло. Может у такого критерия уже есть имя?

Я уже писал, что мы в команде Arenadata R&D помогаем проекту OrioleDB - новому транзакционному движку для PostgreSQL. Помогаем в первую очередь, как мне кажется более системным подходом к тестированию: тестируем на больших машинах, в длительных нагрузочных тестах, при обнаружении крэшей расследуем их и присылаем патчи а не начинаем скулить что код сырой и ожидали большего. Недавно Саша Коротков, основной автор OrioleDB, выпустил очередную оптимизацию - ordered insertion optimization. C одной стороны, это лишь один граничный случай, в котором OrioleDB догнала PostgreSQL :). Ещё есть, например, относительно недавние тесты Марка Кэллэхэна, которые показывают что OrioleDB всё ещё медленнее чем PostgreSQL на ряде сценариев. Их тоже предстоить исправить. С другой стороны, тот факт что раздача пошла по краевым случаям мне лично говорит что свет в конце тоннеля уже довольно близко. И вот я подумал, я написал "новый движок" - а сколько времени должно пройти чтобы движок стал не новым? Вот вы как думаете? И как определяете что технология готова к промышленному использованию?

Трансляция началась, зайти можно по ссылкам: YouTube: https://youtube.com/live/syp22LEUHVQ?feature=share VK Video: https://vkvideo.ru/playlist/-226977842_-3/video-226977842_456239027?linked=1

Не могу не написать о surrealdb.com - абсолютно новой СУБД, которая действительно находится на шаг впереди всего, что я видел раньше :) Не слышали? Странно. А ведь у репозитория 30 000 звёзд на гитхабе (это больше чем у MongoDB), 7 тысяч подписчиков на youtube, и довольно именитые клиенты и размашистые конференции. В surrealdb отсутствует свой собственный слой хранения. Она работает поверх tikv. Онбординг для кластерной версии сразу ведёт в облако. Если раньше продукты стартовали взяв rocksdb за основу, но это всё равно требовало создания минимум нескольких дополнительных крупных модулей, кроме, непосредственно, движка запросов - управления топологией, схемой данных, репликацией, детектором отказов, то теперь новый продукт можно сделать и раскрутить просто взяв слой хранения "у соседа". По сравнению со скучным SQL в tidb, surrealdb даёт свой собственный, не совместимый ни с чем синтаксис (RethinkDB не напоминает? а CrateDB? а TigerGraph? ). Есть поддержка векторного поиска и графов. Что же в surrealdb действительно инновационного, как мне кажется? - ещё более агрессивная раскрутка. Мерч, видео, крутые конференции - всё что мы сейчас видим в экосистеме Clickhouse, но только там это действительно по делу, под капотом стоящая технология. Продажа инвестору звёзд на github, вмёсто понятной долгосрочной стратегии, которая невозможна без собственного движка хранения - это пустышка, что очевидно по судьбе CrateDB. Вот например на db-engines.com эта СУБД на 173 месте, может быть пока? - ставка на пузырь AI как на основную кормовую базу. В целом мы это тоже уже видели, но эффект ещё более "дутый" чем у предыдущей волны облачного хайпа - быстрый старт за счёт использования tikv и rust + javascript непосредственно для query layer. Это же даёт и популярность среди github сообщества. Я бы свои деньги в такое инвестировать не стал. Но видимо поэтому я и не инвестор )