Исходное сообщение
"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...." Отправлено erthink, 09-Фев-21 02:15
>[оверквотинг удален] > быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим > пользовательским параметрам 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...

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>[оверквотинг удален] >> быстрее на узкоспецифичных кейсах!" не тянет на конкурентное преимущество. По многим >> пользовательским параметрам 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-databases
	Введите код, изображенный на картинке: