Генерация правдоподобных тестовых данных - ключевой аспект нагрузочного тестирования, результатам которого можно доверять. Стартап https://shadowtraffic.io/ делает это для Kafka, PostgreSQL, и других популярных СУБД. В cassandra-stress, например, вы можете задать тип, размер и распределение тестовых данных, вот так:

columnspec:
  - name: username
    size: uniform(10..30)
  - name: first_name
    size: fixed(16)
  - name: last_name
    size: uniform(1..32)
  - name: password
    size: fixed(80) # sha-512
  - name: email
    size: uniform(16..50)
  - name: startdate
    cluster: uniform(20...40)
  - name: description
    size: gaussian(100...500)

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

        "name": {
            "_gen": "string",
            "expr": "#{Name.full_name}"

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

С недавних пор я присоединился к компании Arenadata в качестве директора по R&D. Одно из направлений, которым я буду заниматься - развитие PostgreSQL. Вот я и пришёл к Aleksander Alekseev, давнему контрибьютору в PostgreSQL, за подробностями о 64-битном счётчике транзакций - почему именно он не оказался (и скорее всего теперь никогда не окажется) в PostgreSQL trunk.

Резидентные вибрации - 501 (!!!) эпизод DevZen в котором простуженный гость рассказывает о всё том же - плагинах, резидентных СУБД, открытом ПО и т.д.. Ребята принципиально не готовят вопросы к подкасту, это всегда живая история - и так уже больше 10 лет.

PS Жалею что под рукой не было хорошего микрофона, качество звука могло бы быть лучше.

На недавней конференции добыл нетленку - статью 1993 года - Relational Database Integration in the IBM AS/400, а вдогонку - ряд документов по микрокоду AS/400. Среди всех Design Patterns №1 - декомпозиция через общие форматы и данные. Это самый естественный, самый простой, и самый эффективный способ. Глобальные переменные. Разделяемая память. Внешние файлы. Централизованная СУБД.

В AS/400 СУБД и таблицы - часть слоя операционной системы. Сама операционная система работает поверх слоя микрокода, выполнение которого задублировано на физических компонентах системы. Адресное пространство и пространство открытых файлов общее для всех процессоров. Это позволяет выполнять параллельные, отказоустойчивые вычисления с общими данными, и даст фору любой современной архитектуре и по эффективности, и, до некоторой степени - по масштабируемости. Мы в Picodata пытаемся сделать что-то похожее: общая разделяемая память, доступ к таблицам - непосредственно в пользовательском коде плагина, резервирование всех компонент кластера.

Но у Picodata есть один фундаментальный недостаток: мы не предоставляем безопасного разделения системного и прикладного слоя, код плагина может повлиять на жизнеспособность распределённого кластера. Справедливости ради, это недостаток всех IMDG систем. И пока мы его не решим, с мейнфреймами нам тягаться не получится.

За те две недели что я прокрастинирую прорекламировать стартап https://nyrkio.com/ у компании появилось два первых клиента - turso и tigerbeetle. Хорошие клиенты, правда?-) Для тех кто не в курсе - это, пожалуй, одни из самых молодых и интересных стартапов в области oltp СУБД. Сама nyrkio основана бывшим коммиттером MySQL и performance engineer'ом MongoDB, Henrik Ingo, и предоставляет continuous performance testing as a service: вы подключаете сервис nyrkio к своему github pipeline, и получаете алерты когда один из ваших коммитов вносит performance regression в код. Звучит просто, правда?

Под капотом миллион деталей: выбор оборудования, создание микробенчмарков, длительное хранение результатов, автоматический поиск аномалий и трендов. Естественно, содержать in-house команду которая бы поддерживала и развивала всю эту инфраструктуру даже для вендоров с бюджетом на разработку в десятки миллионов долларов - накладно. Что уж говорить о маленьких командах в 5-10 человек.

nyrkio часть более глобального тренда в Кремниевой долине - компактные команды. Всё больше стартапов готовы предложить ранней команде зарплаты в сотни тысяч долларов, но при этом привлекают исключительно высокопроизводительных и опытных разработчиков, готовых заниматься всем. Пожалуй основной причиной для этого является созревание AI, но подход стал возможным в том числе и из-за развития SaaS.

В этот четверг в 19-00 по Москве собираемся тесным кругом программного комитета Database Internals чтобы разобрать статью How Good Are Query Optimizers, Really? Я впервые с ней познакомился лет 10 назад по наводке товарища из ныне несуществующей СУБД NuoDB, и всё это время наблюдаю как статья неизменно оказывается одной из самых цитируемых при обсуждении проблем оптимизации запросов. Ссылка на регистрацию

Не могу не написать о 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 сообщества.

Я бы свои деньги в такое инвестировать не стал. Но видимо поэтому я и не инвестор )

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

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

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

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

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

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

Книги прочитанные за отпуск:
- Генрих Альтшуллер "Найти идею". ТРИЗ - известный брэнд, а я как-то с сутью метода знаком не был. По результатам прочтения, кажется что метод мне неподвластен. Похожее чувство возникает у меня при игре в любительской лиге "Что Где Когда". Вроде ход мышления знатоков понятен, но если я не знаком с ответом как с фактом, логически до него домыслить я не могу: слишком много "натяжек" и "допущений" должно быть сделано чтобы прийти от вопроса к ответу. Я таких сильных допущений в своих рассуждениях делать не привык. Похожее же чувство от ТРИЗ.

Константин Харский "Ценностное управление для бизнеса".

Книгу какое-то время назад рекомендовали, после этого попалась на litres и вот. Автор делит всех сотрудников на 4 типа: материалист, эмоционал, виталист, идеолог. Материалист, понятно, в первую очередь движим выгодой, эмоционал - экстраверт получающий удовольствие и энергию от совместной деятельности, виталист заботится о благополучии, балансе, здоровье, идеолог - одержим великой идеей и готов принести в жертву идее всё остальное. Понято, что типы могут комбинироваться в людях, но автор утверждает что в каждом человеке доминируют 1-2 типа. Книга в чём-то похожа на "6 шляп мышления" де Боно, действительно помогает посмотреть на действия разных людей в новом свете. В остальном книга показалась повторяющей уже известные мне (Start with Why, Simon Sinek, например). В целом книгу скорее рекомендую, чем нет.

The Art of Gathering, Priya Parker.

Книга из моего reading list по фасилитации, содержит (пока что, я в середине) базовые правила о том как надо и как не надо проводить встречи. О том что место встречи должно отвечать цели, о том как фасилитировать коммуникации внутри группы, о том как модерировать, работать с хеклерами и т.д. Мне напоминает что-то вроде учебника для колледжа, но помогает структурировать собственные мысли по теме. В целом не питаю иллюзий что стану сильно лучшим фасилитатором ), но очень хотелось бы, конечно.

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

Обновлял 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 я информации об этом не увидел, да и результаты этого не подтверждают.

На земле так много непонятного...

Интересный 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.

Вышел мой подкаст вместе с Кириллом Мокевниным на его площадке "Организованное программирование". Говорим про всё подряд: SQL, NoSQL, будущее СУБД, ИИ.

https://youtu.be/_9JhY63Cvtc?si=FeHn0rEBZXlN3_qe

Ссылки на трансляцию на российских площадках:
- vkvideo - https://vkvideo.ru/video-224967259_456239258
- rutube - https://rutube.ru/video/72d2081f06703cd8bbbefb2bbcfac0be/

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

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

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