Jepsen нашёл в ParticleDB 96 проблем, включая потерю данных при штатной работе
Jepsen: ParticleDB 1.1.4
Jepsen протестировал ParticleDB версий 1.1.4–1.1.18.11.rc-22 и обнаружил 96 дефектов: падения, дедлоки, потерянные коммиты, невидимые строки, которые нельзя удалить, воскресающие таблицы и превращение строк в числа. Большинство проблем воспроизводились на одном узле без сбоев. К rc-22 почти все исправлены, но база по-прежнему теряла подтверждённые записи в режиме occ и допускала Lost Update в serializable. Заявленный «Full ACID» оказался преждевременным.
К версии 1.1.18.11.rc-22 все, кроме десяти, из этих проблем, по-видимому, были устранены. Однако ParticleDB продолжала терять подтверждённые записи при нормальной работе с режимом транзакций occ по умолчанию и допускала внутренние аномалии и Lost Update при serializable — самой строгой настройке.
- the_duke
Жестко!
> ParticleDB 1.1.4 заявляла о себе как о базе данных, совместимой с Postgres... Вместо этого мы обнаружили библиотеку путаницы
> демонстрировала частые, глубокие транзакционные аномалии практически во всех измеримых нами аспектах. Мы регулярно наблюдали потерю зафиксированных записей, нарушения внутренней согласованности, G1a (Aborted Read), G1b (Intermediate Read) и P4 (Lost Update). В нагрузке на добавление успешно добавленные значения регулярно исчезали из последующих чтений данного ключа. Наш набор тестов выявил все виды циклических аномалий, включая G0, G1c, G-Single и G2-item, но многие из них можно отнести к более базовым проблемам, таким как потеря записей. Эти проблемы возникали с одним сервером и без сбоев, и затрагивали каждый протестированный режим транзакций, интерфейс и режим WAL
- amluto
Я пришёл к пониманию интересной дихотомии в программном обеспечении:
Некоторое ПО корректно по построению, в том смысле, что общий дизайн имеет смысл, а случаи, которые не работают, как правило, являются локальными багами.
Некоторое ПО некорректно по построению, и оно обычно работает благодаря сочетанию удачи и тщательного обхода некорректного дизайна в большинстве или во всех путях кода, которые могли бы выявить эту некорректность. (ИИ может быть весьма эффективен в поиске подходящих мест для вставки обходных путей.)
ParticleDB, похоже, относится ко второй категории. У многих крупных проектов есть части, относящиеся к одной категории, и части, относящиеся к другой.
Кстати, последние день-два я размышляю о том, что обработка закрепления folio в ядре Linux, похоже, относится к категории некорректных по построению. Весёлые времена. Нет, я не нашёл трудноисправимый баг, который я бы достоверно охарактеризовал как проблему безопасности или вероятное случайное повреждение данных [0], но это выглядит в основном как удача.
[0] Похоже, я переоткрыл баг, который также нашёл какой-то огромный дамп от Anthropic пару месяцев назад, и его исправляют. Если ваше приложение использует "fixed" I/O через io_uring или определённые типы iommu-based или, возможно, RDMA на memfd, вы вполне можете столкнуться с ним в редких случаях. Я не стал утруждать себя созданием репродьюсера.
- tensegrist
> Домашняя страница ParticleDB рекламировала, что ParticleDB "формально доказана" с помощью доказательства на TLA+. Однако во время нашего сотрудничества никакой спецификации TLA+ не было доступно. Неясно, какие свойства могли быть доказаны и описывали ли они ParticleDB в том виде, в каком она была построена.
- wofo
> Учитывая серьёзность и масштаб найденных нами ошибок безопасности, а также процесс, который их породил, Jepsen рекомендует пользователям приостановить дальнейшее развёртывание ParticleDB и как можно скорее перейти на другие базы данных. Рассмотрите возможность проверки и/или пересборки состояния базы данных из более надёжных источников, если таковые имеются.
Полагаю, вот что происходит, когда вайбкодишь базу данных...
- edude03
> Мы представляем 96 проблем в ParticleDB, от заурядных (падения, дедлоки, потеря данных и т.д.) до пикантных (частично невидимые строки, которые невозможно удалить, WHERE 4 = 5, удалённые таблицы, вновь появляющиеся в искажённом виде, перепутанные столбцы, строки, превращающиеся в целые числа, и так далее).
Определённо выглядит хуже обычного (оглядываясь назад, у большинства баз данных, кажется, всего <10 проблем, и большинство из них "мягкие") — поскольку это база данных для ИИ, была ли она также, вероятно, вайбкодена или просто новая? С другой стороны, даже если новая, я бы не ожидал столько проблем в стабильном релизе.
- mxey
Это дико, насколько всё плохо. Неудивительно для вайбкоденой базы данных, но почему они наняли Кайла для тестирования, вместо того чтобы сначала провести ЛЮБОЕ тестирование самим?
- eqvinox
> Строки иногда превращались в восьмибитные целые числа (#37)
НАКОНЕЦ-ТО мы знаем, что случилось с ключами eMudhra!
(Извините. Правда не смог удержаться.)
- t3ntxcles
Выпустить такой баг, как "WHERE 4 = 5", возвращающий строки, — это всё мне говорит