16 октября 2026 года, в 19:31 UTC, Джонатан Миллер опубликовал на mariadb.org разбор, как гонять TidesDB внутри MariaDB через TAF.
Под заголовком сразу график POINT_SELECT. Подпись на нём: Read Benchmark for TidesDB, одна линия 11.4.13-MariaDB. По горизонтали отметки 64, 128 и 256, по вертикали TPS. Чем правее точка, тем выше линия.
Движок входит в сервер 11.4.13 как подключаемый storage engine. В тексте плагин называется TideSQL. На зеркале файл подписан иначе: MariaDB-plugin-tidesdb-11.4.13_5.0.0. Каркас тот же TAF. Про версию 4.0 от 28 сентября есть отдельная заметка. Здесь другой слой: конкретная сборка сервера, плагин и готовые прогоны sysbench.
Сам TidesDB сервером баз не является. Это встраиваемое транзакционное хранилище ключ-значение на C. Демона нет, порта нет, своего разбора SQL нет, своей авторизации нет. SQL появляется, когда плагин работает внутри MariaDB.
Одной строки ENGINE=TIDESDB мало. Миллер пишет это прямо: нужны установленный плагин, его параметры и пути, по которым сервер находит и файл .so, и каталог данных. Заметка собрана как старт для такого прогона. Те же properties, shell-скрипты и обвязка, которые лежат в TAF в коммите e55a32691c1234e6fea20ac86ba6b59575fdd520.
Чем TidesDB отличается от InnoDB
Устройство другое. Если ждать «InnoDB, только быстрее» и подложить плагин под таблицы WordPress, цифра с sysbench сюда не переносится.
Запись устроена как LSM, не как B-дерево. Данные дописываются, уплотнение (compaction) идёт потом, в фоне. Ключи лежат в отсортированной LSM-структуре, значения уходят в отдельный последовательный журнал. Так, по словам фонда, меньше усиление записи (write amplification), и уплотнение под нагрузкой ведёт себя иначе.
Внутри структуры без блокировок (lock-free), расчёт на много ядер и NVMe. MVCC оптимистичный, уровней изоляции несколько. Читатель и писатель друг друга не блокируют, конфликт всплывает на коммите.
Таблицы WordPress при этом остаются на InnoDB, пока их явно не переводят на другой движок. Прогон из заметки поднимает sysbench на отдельной установке MariaDB, которую собирает TAF.
RPM MariaDB 11.4.13 для el9
TidesDB в этой заметке поставляется внутри MariaDB 11.4.13. RPM лежат в каталоге ветки 11.4 для rhel9-amd64, ссылка из поста: mirror.mariadb.org. Без этих шести файлов каркас сборку с плагином не соберёт.
- MariaDB-server-11.4.13-1.el9.x86_64.rpm
- MariaDB-client-11.4.13-1.el9.x86_64.rpm
- MariaDB-common-11.4.13-1.el9.x86_64.rpm
- MariaDB-devel-11.4.13-1.el9.x86_64.rpm
- MariaDB-plugin-tidesdb-11.4.13_5.0.0-1.el9.x86_64.rpm
- MariaDB-shared-11.4.13-1.el9.x86_64.rpm
В имени плагина между версией сервера и версией плагина стоит подчёркивание: 11.4.13_5.0.0. Дефис на этом месте будет уже другим файлом.
Сборки el9. Это RHEL 9 и родственные системы, включая AlmaLinux 9, на которых фонд снимал прогоны. В apt Ubuntu и Debian этих имён нет. Как ставить саму ветку 11.4 на Ubuntu 24.04, когда репозиторий отвечает 404, разобрано отдельно. Плагин из заметки 16 октября в тот рецепт не входит: TAF забирает RPM и раскладывает их в своё дерево, мимо пакета, которым живёт сайт.
Какая база отвечает на VPS сейчас, видно по версии. На Debian и Ubuntu обычно жива одна из двух команд.
mariadb --version mysql --version
Если в выводе не 11.4.13, пакет MariaDB-plugin-tidesdb-11.4.13_5.0.0 к этому серверу не относится. Системный MariaDB ради прогона не затирают. Каркас ставит свою копию.
Куда TAF кладёт установку
Когда каталог TAF уже на месте и шесть RPM скачаны, установку делает сам каркас. Флаги из заметки: verbose, db-software-install, db-software-install-packages. В консоли перед ними два дефиса. На странице фонда типографика местами превратила их в длинное тире, копировать оттуда в терминал не стоит. Список пакетов идёт одним аргументом, через запятую, пути свои.
perl taf.pl --verbose --db-software-install --db-software-install-packages=/<path to>/MariaDB-server-11.4.13-1.el9.x86_64.rpm,/<path to>/MariaDB-client-11.4.13-1.el9.x86_64.rpm,/<path to>/MariaDB-common-11.4.13-1.el9.x86_64.rpm,/<path to>/MariaDB-devel-11.4.13-1.el9.x86_64.rpm,/<path to>/MariaDB-plugin-tidesdb-11.4.13_5.0.0-1.el9.x86_64.rpm,/<path to>/MariaDB-shared-11.4.13-1.el9.x86_64.rpm
Дальше TAF распаковывает слои RPM, сплющивает дерево и кладёт MariaDB вместе с плагином в taf-perl/database_software_installs/. Туда же попадают бинарники и каталог плагинов. Установка помечается как active. В конце каркас печатает строку Install has completed. Happy benchmarking!
Это метка TAF, не systemctl enable для базы сайта. Юнит, который поднимает MariaDB на VPS, команда не включает и не выключает. Каталог, из которого сайт читает таблицы, в список RPM не входит.
Если правите cnf именно стенда, сначала снимите копию файла. Конфиг, которым сайт ходит в базу, этот шаг не трогает. Системные таблицы из-за прогона не мигрируют: mysql_upgrade здесь ни при чём.
Пути к данным и к файлу .so
Чужой пример не заведётся, пока пути не ваши. В properties и в скриптах стоят заглушки. Миллер выписывает их все: ни один не совпадает с каталогом «по умолчанию».
Каталог данных TidesDB лежит в секции [db_config_start] / [db_config_end]. Куда стендовый сервер смотрит за .so, задаётся не штатным каталогом плагинов пакета MariaDB. TAF передаёт свой путь аргументом при старте. В скриптах ещё две переменные: где лежат properties и где лежит установленная сборка.
tidesdb_data_home_dir=/<path to>/taf-perl/data/ taf.db_plugin_dir=/<path to>/taf-perl/database_software_installs/MariaDB-server-11.4.13-1.el9.x86_64/lib64/mysql/plugin/ PROP_DIR="/<path to>/taf-perl/properties/mariadb/tidesdb" INSTALL_DIR="/<path to>/taf-perl/database_software_installs/MariaDB-server-11.4.13-1.el9.x86_64"
Если PROP_DIR или INSTALL_DIR смотрят мимо, TAF не находит ни файлы прогона, ни бинарники. Если taf.db_plugin_dir указывает в каталог плагинов системной MariaDB, а .so лежит в дереве TAF, стендовый сервер плагин не откроет.
Обратная путаница больнее. Вписать этот db_plugin_dir в конфиг MariaDB, которая обслуживает WordPress. Боевой сервер начнёт искать плагины в каталоге стенда. Путь относится к экземпляру, который поднимает TAF, не к тому, что отдаёт сайт.
В tidesdb_data_home_dir каталог данных сайта тоже не ставят. Прогон пишет туда, куда путь задан для стенда.
properties/mariadb/tidesdb и sysbench
На свежей установке sysbench ещё надо собрать. Клиент компилируется против текущего сервера: MariaDB, MySQL или PostgreSQL, против чего собрали, с тем и работает. Берёте properties, с которого начнёте, и добавляете флаг –action=build-client. Пример в посте указывает на домашний каталог Миллера на стенде, /home/jeb. У себя путь другой.
perl ./taf.pl --properties=/home/jeb/taf-perl/properties/mariadb/tidesdb/sysbench_tidesdb_large_host_writes.properties --action=build-client
Заново собирать клиент нужно, если уходите с MariaDB на PostgreSQL. Для следующих прогонов TidesDB на той же сборке он уже есть.
Сценарии лежат в properties/mariadb/tidesdb/. Чтение и запись разведены, и ещё разведены по классу машины. Чтение: POINT_SELECT и OLTP_RO. Запись: OLTP_RW и OLTP_WO_MODIFIABLE.
- sysbench_tidesdb_small_host_reads.properties
- sysbench_tidesdb_small_host_writes.properties
- sysbench_tidesdb_large_host_reads.properties
- sysbench_tidesdb_large_host_writes.properties
В каждом файле заданы тип теста sysbench, размер набора под класс машины, уровни конкуренции, выбор движка TidesDB и его параметры. Туда же входят пути к плагину и к данным. Их как раз и правят перед стартом.
Обёртки короткие: scripts/mariadb/tidesdb/tidesdb_small.sh и tidesdb_large.sh. Сначала скрипт выставляет частоту CPU так, чтобы она не плавала между прогонами. Потом подставляет PROP_DIR и INSTALL_DIR и запускает чтение и запись своего класса. Оба прогона пишут в один лог.
На VPS, где в эту же минуту отвечают nginx и php-fpm, скрипт трогает частоту всей машины. Сайту, который на ней работает, фиксированная частота бенчмарка не нужна. small.sh и large.sh запускают на отдельном стенде, не на коробке, которая отдаёт прод.
Дальше Миллер сам зовёт крутить число нитей, включать threadpool, менять размер набора и брать другие сценарии sysbench. Четыре файла это база, с которой стартуют.
Стенды hz-bench и hz-bench2
Размер набора в properties привязан к двум машинам Hetzner, не к VPS на пару гигабайт. Фонд на них и снимал интеграцию TidesDB с TAF.
Малая, hz-bench. Intel Core i5-13500, 13-е поколение. В посте: 20 CPU, 14 ядер, 1 сокет, 62.33 ГБ памяти. Система AlmaLinux 9.7 (Moss Jungle Cat), ядро 5.14.0-811.35.1.el9_7.x86_64. Под неё файлы small_host: меньший набор, ниже конкуренция, предсказуемая частота.
Большая, hz-bench2. AMD EPYC 9454, 48 ядер. В посте: 96 CPU, 1 сокет, 124.98 ГБ. Система AlmaLinux 9.8 (Olive Jaguar), ядро 5.14.0-427.28.1.el9_8.x86_64. Под неё файлы large_host. На этой машине как раз смотрят, как движок ведёт себя, когда нагрузка реально упирается в LSM, журнал значений и число ядер.
Прогон large_host на машине, которая одновременно отдаёт сайт, мерит не движок. Он мерит всю коробку: nginx, php-fpm и базу вместе. Для сравнения с цифрами фонда нужна машина того же класса, что hz-bench или hz-bench2, и та сборка 11.4.13, которую TAF разложил у себя.
Движок в MariaDB доводил Алекс (Гаэтано) Падула. В заметке плагин TideSQL назван его работой: отдельный storage engine, который можно загрузить в сервер. Пост написан, чтобы по этой сборке можно было начать прогон, а не чтобы завтра переложить wp_posts.
Для сайта развилка короткая. Команда mariadb –version на VPS от этой заметки не меняется. Плагин есть как RPM el9 рядом с MariaDB 11.4.13 и ставится в дерево TAF. Таблицы WordPress остаются на InnoDB. Каталог данных сайта в установщик не передают. Скрипты, которые фиксируют частоту CPU, на боевой машине не запускают.
