Jepsen нашёл, что WHERE 4 = 5 возвращает строку в ParticleDB, базе, которая продавалась как «Full ACID»

159 тысяч транзакций в секунду и сноска про snapshot isolation

Разбор Jepsen касается многомодельной базы для AI-нагрузок, которая сочетает SQL, ключ-значение, векторный поиск и аналитику. На главной было написано «Full ACID. 159K TPS», но текст под заголовком описывал snapshot isolation. Доказательство на TLA+ тоже рекламировали, однако спецификация тестировщикам не была доступна. В документации расходилось, какой из режимов, sync или groupsync, даёт более сильную долговечность write-ahead-лога.

Jepsen тестировал версии от 1.1.4 до 1.1.18.11.rc-22 на одиночных узлах и насчитал 96 проблем. Несколько примеров из отчёта:

• WHERE 4 = 5 возвращал строку с первичным ключом 5, а SELECT 5 WHERE FALSE вернул строку.
• Ограничения NOT NULL и UNIQUE сначала игнорировались, а первичные ключи можно было установить в NULL.
• Удалённые строки оставались в базе, удалённые таблицы возвращались с изменёнными значениями, а строки иногда превращались в целые числа.
• Прерванные транзакции могли закоммититься, а битовые ошибки в write-ahead-логе приводили к частичной потере данных.

Orkes, которая финансировала работу, исправила большинство пунктов в последующих релизах. К последней протестированной сборке Jepsen насчитал около десяти нерешённых, включая режим occ по умолчанию, который всё ещё терял подтверждённые записи. Jepsen рекомендовал пользователям остановить развёртывание и мигрировать.

Ответ ParticleDB

Участник команды ParticleDB написал, что компания теперь ежедневно гоняет длительные нагрузки Jepsen и «сузила список поддерживаемых режимов транзакций». По его словам, последние прогоны не нашли аномалий в поддерживаемых режимах, которые дают гарантии изоляции.

Как тред прочитал этот ответ

«То, что они сказали, будто проблемы исправлены, хотя на деле нет, — это самый большой красный флаг из возможных. Я бы никогда не позволил никакому клиенту использовать этот софт ни при каких условиях» — комментатор, у которого однажды базу проверял Jepsen

Он сказал, что его собственный опыт работы с автором Jepsen был противоположным: несколько реальных багов, которые срочно исправили, и много внутреннего тестирования ещё до начала проекта.

Некорректна по построению

Один комментатор предложил рамку, в которой 96 не связанных между собой багов могут иметь одну причину. Некоторое ПО корректно по построению, и тогда сбои — локальные ошибки. Другое ПО некорректно по построению и держится на везении и обходных решениях вокруг порочного дизайна. ParticleDB, по его мнению, относится ко второму типу.

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