>[оверквотинг удален]
> быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим
> пользовательским параметрам rocks и lmdb проигрывают leveldb, во всяком случае так
> было неделю назад, когда я крайний раз выбирал key-value хранилище для
> проекта. Может быть, с тех пор что-нибудь и поменялось.
> Нет. Я считаю, что это всё совершенно не интересно пользователям, имеют значение
> только осязаемые параметры. И вот скажем это "ура, мы на 5%
> быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим
> пользовательским параметрам rocks и lmdb проигрывают leveldb, во всяком случае так
> было неделю назад, когда я крайний раз выбирал key-value хранилище для
> проекта. Может быть, с тех пор что-нибудь и поменялось.

1) Позвольте пожелать удачи вашему (похоже воображаемому) "проекту".

2) Не 5%, а до 30%. Не в "узкоспециализированных кейсах", а в CRUD-сценариях с псевдо-случайным порядком записей.
По ссылкам, кроме _ВСЕХ_ исходных текстов, легко найти примечание: 2 inserts, 1 read, 1 update, 1 delete.

3) Ничего не поменялось примерно с самого начала.
Что-чему проиграет/выиграет принципиально зависит от требований, например:
- сколько процессов работают с БД;
- нужны ли транзакции и с какой изоляцией;
- отношение read/write в нагрузке;
- ограничения на выброс latency;
- нужны ли выборки диапазонов;
- как долго живут версии данных;
- отношение объема данных и ОЗУ;
- какие диски;
- и т.д.

Короче, просится RTFM:
https://github.com/erthink/libmdbx#performance-comparison
https://github.com/erthink/libmdbx#comparison-with-other-dat...