Jepsen нашёл 96 проблем в базе данных ParticleDB от Orkes

Jepsen опубликовал анализ базы данных ParticleDB (проверены версии с 1.1.4 по 1.1.18.11.rc-22). Её создала компания Orkes для собственной платформы оркестрации рабочих процессов Conductor. Изначально Conductor хранил данные в Redis и Postgres, но ради скорости Orkes решила написать свою базу. Версия 1.0.0 умела лишь то, что нужно запросам Conductor, и работала на части кластеров компании и у нескольких её клиентов. Затем Orkes сильно переработала систему (свой сетевой протокол, больше типов данных, дополнительные аналитические запросы), «мягко запустила» новые версии на particledb.ai и наняла Jepsen проверить их, начиная с 1.1.4.

ParticleDB пытается объединить в одном движке транзакционный SQL, хранилище «ключ, значение», векторный поиск, аналитику в реальном времени и пользовательские функции (Particles) с упором на ИИ-агентов и приложения. Подключаться можно по протоколам Postgres и Redis, а также через собственные gRPC и HTTP2. Написана с нуля на Rust и, по заявлению разработчиков, на порядки быстрее Postgres при тех же гарантиях безопасности. У базы есть кластерный режим на протоколе консенсуса Raft, но он доступен только в корпоративных облачных развёртываниях. Присланные Orkes сборки репликацию не поддерживали, поэтому отчёт охватывает только работу одного узла.

Уже документация и маркетинг вызвали у Jepsen вопросы. Главная страница заявляла, что ParticleDB «формально доказана» с помощью TLA+, но за время сотрудничества спецификации TLA+ не нашлось, и неясно, какие свойства доказаны и относятся ли они к реальной сборке. Там же стояло «Full ACID. 159K TPS», а прямо под этим, «snapshot isolation» (изоляция снимков), которая не является полной изоляцией. Для журнала предзаписи (WAL) есть три режима синхронизации: sync (fsync на каждый коммит), groupsync (один fsync на пачку транзакций) и nosync (без fsync). Документация движка говорила, что у sync «более сильная долговечность», чем у groupsync, а справка командной строки и внутреннее руководство оператора Orkes утверждали, что groupsync даёт ту же долговечность, что sync. Команды SET TRANSACTION ISOLATION LEVEL база игнорировала или отклоняла, а уровень изоляции задавался флагом --txn-mode при запуске. Описание четырёх режимов (fast, occ, zero-copy-occ, table-2pl) было двусмысленным: непонятно, какие гарантии они дают, а в справочнике occ и table-2pl называли «Jepsen-safe», не объясняя, что это значит. Orkes пояснила, что документация по occ ошибочна: режим на самом деле оптимистичный, а алиас row-2pl сохранён для совместимости со старым механизмом двухфазных блокировок. Источники расходились и насчёт режимов по умолчанию; похоже, это occ-v3 и groupsync.

Тесты Jepsen запускала на отдельных узлах Debian 13 в контейнерах и на виртуальных машинах EC2. Тестовый стенд мог убивать процесс, имитировать потерю не сброшенных на диск записей через LazyFS, обрезать и портить файлы. Прогоняли все режимы транзакций и все три режима WAL. Официальный Java SDK, который по документации должен подтягиваться как Maven-зависимость, на деле был недоступен ни в виде JAR, ни в исходниках, поэтому начали со стандартного JDBC-клиента Postgres версии 42.7.11, а позже добавили поддержку SDK версий 1.0.0-1.0.2. Использовали нагрузки rw и append (проверка чекером Elle на циклы зависимостей и другие аномалии), нагрузку internal (внутренняя согласованность одной транзакции), нагрузку compare (дифференциальное тестирование против PostgreSQL на случайных таблицах и простых SQL-запросах, с автоматическим упрощением найденных расхождений; по словам авторов, она оказалась очень результативной) и гибридную internal-sim.

Итог видимой части: найдено 96 проблем, все, кроме трёх, на здоровых одиночных узлах. Категории результатов: доступность и производительность, неработающие функции, предикаты, ограничения, соединения, «зомби», порча состояния, транзакции и конкурентность, сбои. В доступной части разобраны первые четыре проблемы по доступности и производительности. Режим table-2pl в версиях с 1.1.4 по 1.1.18.4 был почти непригоден: часть транзакций проходила за миллисекунды, но большинство висело 10, 20 и даже 30 секунд и падало с ошибкой «could not serialize access due to concurrent update» или ошибкой ввода-вывода (проблема #62; при десяти клиентах). К версии 1.1.18.6 задержки улучшились, но узлы начали спонтанно завершаться без сообщений об ошибках через несколько сотен или тысяч секунд, причём очевидной причины не было (#81); в 1.1.18.11.rc-18 эти падения уже не воспроизводились. В версии 1.1.18.8 взаимную блокировку вызывали всего две параллельные транзакции на здоровом одиночном узле (#27); с нагрузкой append версия 1.1.18.9 обычно не работала дольше 45 секунд, а 1.1.18.11.rc-1 стабильно держалась две минуты, и проблему сочли решённой. Взаимная блокировка в table-2pl (#71) разбирается в усечённой части отчёта. Остальные разделы, включая итоговое обсуждение, в доступном тексте не видны.

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

Jepsen по заказу Orkes проверила ParticleDB (версии с 1.1.4 по 1.1.18.11.rc-22) и нашла 96 проблем; все, кроме трёх, проявлялись на здоровых одиночных узлах.
Проверялся только один узел: репликация на Raft есть лишь в корпоративных облачных развёртываниях и в присланные сборки не входила.
Заявления на главной странице расходятся с реальностью: «формально доказана» по TLA+, но спецификации не было; «Full ACID» рядом с «snapshot isolation», которая не является полной изоляцией.
Документация путалась в гарантиях: режимы транзакций описаны неясно, а про groupsync одни источники писали «та же долговечность, что у sync», другие, что у sync она сильнее.
Проблемы с доступностью: транзакции в table-2pl висели 10-30 секунд, версия 1.1.18.6 внезапно падала, версия 1.1.18.8 зависала всего на двух параллельных транзакциях; часть исправили в 1.1.18.11.

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

ParticleDB позиционируется как единый движок для SQL, ключей и значений, векторного поиска и аналитики, ориентированный на ИИ-агентов, и заявляет скорость на порядки выше Postgres при тех же гарантиях. Jepsen специализируется на проверке корректности распределённых систем, и её отчёт показывает, что на момент проверки эти заявления подкреплены слабо: 96 проблем, почти все на здоровом одиночном узле, плюс расхождения между рекламой, справкой и документацией. Для читателя это пример того, как проверяют базу данных не по тестам скорости, а по соответствию заявленным гарантиям.

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

Разработчикам, которые выбирают базу данных для приложений и ИИ-агентов и присматриваются к ParticleDB или похожим «всё-в-одном» движкам. Инженерам, отвечающим за надёжность хранилищ, интересна методика: нагрузки rw и append с чекером Elle, дифференциальное тестирование против PostgreSQL, проверки внутренней согласованности. Тем, кто пользуется Conductor от Orkes, важно знать, что исходная версия 1.0.0 с урезанным набором функций работала у компании и части клиентов, а проверялись переработанные версии.

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

В видимой части отчёта нет итогового вердикта о пригодности ParticleDB, поэтому выводы о внедрении делать рано. Практический вывод для выбора любой базы: не полагаться на рекламные лозунги вроде «Full ACID» и «формально доказана», а выяснять, какой уровень изоляции и какой режим синхронизации журнала реально включён, и проверять это на своей нагрузке. Из методики Jepsen можно взять идею сравнивать поведение с PostgreSQL на случайных запросах: даже простой генератор SQL оказался очень результативным.

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

Отчёт написан Jepsen, авторами тестов, и сделан по заказу Orkes, создателя ParticleDB. Утверждения подкреплены конкретными версиями, номерами проблем и описанием тестового стенда. Оговорка: доступный текст усечён, раздел «Обсуждение», остальные категории результатов и приложение не видны, поэтому общий вывод авторов здесь не пересказан. Скорость 159 тыс. TPS в видимой части не проверялась, это цитата с главной страницы ParticleDB.

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

Тестировались только одиночные узлы: поведение кластера с репликацией на Raft не проверялось. Версии менялись быстро, и часть проблем (например, спонтанные падения #81 и взаимная блокировка #27) в более поздних сборках уже не воспроизводилась, поэтому цифры по ранним версиям не переносятся на новые. Режимы транзакций и синхронизации журнала описаны неоднозначно, а источники расходятся насчёт значений по умолчанию, так что можно получить не те гарантии, на которые рассчитываешь. Официальный Java SDK по документации был доступен как Maven-зависимость, но на деле его не оказалось.

«Full ACID. 159K TPS.»

— Главная страница ParticleDB, как её цитирует Jepsen