ИИтог

TidesDB стал доступен для MySQL как плагин TideSQL 2.0.0

инфраструктураРедакция ИИтогHacker News🔥38Рейтинг ИИтог38Влияние40Новизна45Релевантность80Неожиданность20Участники10Достоверность75
TidesDB стал доступен для MySQL как плагин TideSQL 2.0.0

5 октября 2026 года проект TidesDB объявил, что его движок хранения теперь доступен для MySQL как внешний плагин TideSQL. Версия TideSQL for MySQL 2.0.0 работает в паре с TidesDB 10.1.1 и протестирована на MySQL 9.7.0 и 26.7.0. Сначала TideSQL был форком MySQL, созданным ради того, чтобы подключить библиотеку TidesDB как плагин, но тогда у сообщества MySQL не было способа сделать это штатно, и курс поменяли. Теперь это именно плагин, а не форк: запускается обычный MySQL, движок загружается в него, и таблица TidesDB может лежать рядом с таблицей InnoDB на одном сервере. Сейчас плагин ставится скриптом install.sh из репозитория плагина (его можно направить на собственную сборку или дать собрать пакет самому). В будущем авторы хотят упростить установку и ведут об этом переговоры с «соответствующими сторонами»; кто это и в какие сроки, не сказано.

TidesDB описывается как библиотека движка хранения, оптимизированная по записи и по занимаемому месту, которая при этом хорошо держит чтение благодаря гибридной LSM-архитектуре. Настройки задаются в ENGINE_ATTRIBUTE (JSON-объект в CREATE TABLE): опечатка в имени опции приводит к ошибке, а не молча игнорируется; у каждой опции есть сессионная переменная tidesdb_default_*. Сжатие включено по умолчанию: NONE, SNAPPY, LZ4, ZSTD и LZ4_FAST, по умолчанию LZ4. Большие значения вынесены из компакции: значение размером от tidesdb_value_separation_threshold (по описанию автора, от 1024 байт) уходит в общий сегментированный журнал значений, а в журнале ключей остаётся указатель; для таблиц, которые сканируются намного чаще, чем сливаются, можно задать keep_values_inline. Форму LSM можно настраивать по таблице (level_size_ratio, min_levels, l1_file_count_trigger, tombstone_density_trigger для таблиц с большим числом удалений), а политику компакции выбирает сам движок среди трёх вариантов: preemptive merge, dividing merge и partitioned merge.

Долговечность задаётся одной настройкой tidesdb_memtable_sync_mode: FULL (по умолчанию) означает, что подтверждённая запись дошла до устройства и переживёт отключение питания; INTERVAL передаёт запись ОС и сбрасывает на устройство в течение интервала; NONE при коммите ничего не делает, и сбой процесса теряет подтверждённый коммит, лежащий в буфере. Конкурентность, оптимистичный MVCC без пессимистических блокировок строк: конфликт записи проявляется при коммите как ER_ERROR_DURING_COMMIT (1180), и приложению с явными транзакциями на уровне REPEATABLE READ и выше стоит повторять транзакцию. Автокоммит работает на READ COMMITTED, где библиотека не проверяет конфликты записи. Также есть срок жизни строк (TTL), шифрование на уровне строк с двухуровневыми ключами, полнотекстовые индексы (BM25), внешние ключи, пространственные индексы, генерируемые столбцы, JSON, мгновенные ADD/DROP COLUMN, онлайн-бэкап и контрольные точки. Векторные столбцы можно хранить и читать, но поиска по сходству нет.

Автор сам прогнал sysbench 1.0.20 на обоих движках на одном сервере (Intel i9-13900, 24 потока, NVMe Micron 7450, Ubuntu 24.04.4): 8 таблиц по 5 млн строк, каждый движок с настройками по умолчанию; изменены только уровень изоляции READ COMMITTED и режим долговечности, одинаковые для обоих. Показаны транзакции в секунду при 24 потоках (там коробка выходила на пик) и объём записанных на устройство байт на операцию (по /proc/diskstats, с периодом успокоения после прогона). Сами цифры в тексте не приведены, они есть только на графиках. Разницу автор объясняет так: набор данных около 8 ГБ при блок-кэше и memtable по 256 МБ у TideSQL и буферном пуле InnoDB 128 МБ, поэтому память данные не вмещает; обновление случайной строки в InnoDB требует найти обычно не загруженную страницу 16 КБ, прочитать её, изменить и записать все 16 КБ обратно через doublewrite buffer плюс redo-журнал, а TidesDB дописывает несколько сотен байт и наводит порядок позже.

Стандартные нагрузки sysbench журнал значений не затрагивают: строка sbtest около 188 байт, а в журнал значение уходит от 1024 байт. Поэтому отдельный тест: 4 таблицы по 200 000 строк с текстовым столбцом 4 КБ, данные сжимаются как лог или JSON. Три конфигурации: InnoDB, TidesDB по умолчанию (с разделением значений) и TidesDB с keep_values_inline в роли контрольной. Вставка у InnoDB и TidesDB с inline одинаковая, а разделение значений даёт втрое больше. Автор делает вывод, что выигрыш на больших записях не от LSM как таковой, а от того, что компакция переписывает ключи и оставляет значения на месте. По задержке чтения inline-вариант имеет лучшую медиану 0,07 мс, но среднее 0,38 мс и худший случай свыше 40 мс (компакция таскает значения под чтениями); конфигурация по умолчанию: среднее 0,09 мс, худший случай 6 мс. Те же 3,05 ГиБ полезных данных занимают 4,24 ГиБ в InnoDB и 1,19 ГиБ в TidesDB (LZ4 по умолчанию на текстоподобных данных). Загрузка занимает 17 секунд у InnoDB и 8 у TidesDB. Исходные данные и скрипты опубликованы архивом data.zip.

Ключевые факты

  • TideSQL for MySQL 2.0.0 (вместе с TidesDB 10.1.1), внешний плагин, а не форк: работает в обычном MySQL 9.7.0 и 26.7.0, таблицы TidesDB и InnoDB могут сосуществовать на одном сервере.
  • Ставится пока через скрипт install.sh из репозитория плагина; упрощение установки авторы только обсуждают с «соответствующими сторонами».
  • Конкурентность, оптимистичный MVCC: конфликты записи видны при коммите (ER_ERROR_DURING_COMMIT, 1180) и требуют повтора; векторные столбцы хранятся, но поиска по сходству нет.
  • Тест с большими значениями (4 таблицы по 200 000 строк, текстовый столбец 4 КБ): вставка втрое быстрее, чем у InnoDB; 3,05 ГиБ данных занимают 1,19 ГиБ против 4,24 ГиБ; загрузка 8 секунд против 17.
  • Все замеры сделаны самим автором на одной машине (i9-13900, NVMe Micron 7450); цифры sysbench по TPS и байтам на операцию в тексте не приведены, только на графиках.

Почему это важно

InnoDB, движок MySQL по умолчанию, и альтернативы, которые можно подключить без форка сервера, встречаются нечасто. Раньше TideSQL был форком MySQL; теперь это плагин, который подключается к стандартному серверу. Для тех, кого интересует запись и экономия места, это способ попробовать LSM-движок рядом с InnoDB в той же базе. Это выпуск небольшого проекта, а не решение Oracle или команды MySQL: о её поддержке или включении плагина в поставку в тексте ничего не сказано.

Кому это важно

Администраторам и разработчикам MySQL с нагрузкой на запись, с большими (килобайты) значениями в строках, например текстами, логами и JSON-документами, и с жёсткими требованиями к занимаемому диску. Тем, кто хочет сравнить движки на своих данных, не меняя сам сервер MySQL. Тем, кого интересует устройство LSM-движков и разделение ключей и значений.

Как это применить

Сейчас плагин ставится скриптом install.sh из репозитория плагина: его можно направить на собственную сборку или дать собрать пакет самому. Опции таблицы задаются в JSON-атрибуте ENGINE_ATTRIBUTE, а общие политики, через переменные tidesdb_default_*. Режим долговечности выбирается в tidesdb_memtable_sync_mode: FULL по умолчанию, INTERVAL и NONE ослабляют гарантии. Для таблиц, которые сканируются намного чаще, чем сливаются, автор предлагает keep_values_inline. Приложениям с явными транзакциями на REPEATABLE READ и выше нужна логика повтора при ошибке 1180. Сведений о цене или лицензии в тексте нет.

Можно ли доверять

Это материал самого проекта, где автор не назван, а замеры сделаны им самим на одной машине; независимого воспроизведения в тексте не упоминается. Методика описана подробно: версия sysbench, конфигурация сервера, одинаковые изменения для обоих движков, измерение записи по /proc/diskstats, контрольная конфигурация с keep_values_inline; опубликованы сырые данные и скрипты (data.zip). Однако ключевые цифры по TPS и байтам на операцию в тексте не приведены и видны только на графиках, а InnoDB тестировался на настройках по умолчанию (буферный пул 128 МБ). Утверждение о том, что TidesDB хорошо держит чтение, в тексте не подкреплено числом, превосходства над InnoDB в чтении автор не заявляет.

Риски и подводные камни

Установка пока не стандартная и требует сборки или скрипта. Оптимистичный MVCC означает, что конфликты записи вскрываются только при коммите, и приложению нужно уметь повторять транзакцию; автокоммит на READ COMMITTED не проверяет конфликты записи. Режим NONE теряет подтверждённый коммит при сбое процесса, INTERVAL при сбое машины теряет запись в пределах интервала. Векторные столбцы не поддерживают поиск по сходству. Для таблиц, которые много сканируются, значения в отдельном журнале дают дополнительное чтение на строку. Выигрыш в тесте с большими значениями получен на данных, сжимающихся как текст, на случайных данных результат может отличаться.