Какая key-value БД самая быстрая?

Тут топили за какую-то новую базу данных, созданную майкрософтом.

Это я видел, но там бенчмарки от майкрософта, что доверия не внушает.

Проверь сам.

Неужели на ЛОРе я первый регистрант, выбирающий key-value БД?

Ну тут всё просто. Обычно по классике берут редиску и не жужжат, но ты прав, мне вот редиска и key-value БД пока ни разу не понабились, как и куче тех с кем я учился/работал. А вот sql БД тут да, я могу разгуляться, т.к. делал проекты под MS SQL, Postgree, MySQL, SQLite (вот прям сейчас им занимаюсь и думаю нужно ли мне делать так чтоб Postgree было легко прикрутить если SQLite захлебнётся). Только oracle мимо меня как-то прошел на удивление.

MDBX. /thread

Наш чувак. Вроде он собирался пилить вторую версию, сильно отрефакторенную, но я не следил.

UPD. Хотя я среагировал чисто на заголовок. Снапшоты, работа по сети – ваще хз. Я её только как embedded юзал на плюсах. Да и какой, простите, смысл искать самую быструю key-value, если ты с ней собрался работать из другого процесса: межпроцессное взаимодействие сожрёт 90% времени. Про сеть вообще молчу.

UPD2. Обсуждение, где мне её посоветовали.

Надёжность не критична

Может в /dev/null сразу писать, чтобы такты сэкономить?

По сути своей нужно что-то вроде Redis, но редиска тормозная.

Вы просто не умеете ее готовить, она также как и Memcached может обеспечивать субмиллисекундный доступ к данным. Корнем проблем с производительностью редиски является ее single-threaded архитектура, вернее полное игнорирование этого факта при проектировании системы.

Вообще, вы не указали самого главного - какого типа данные, сколько и как часто будут в нее заливать и потом выбирать?.

Например, если это геоданные (широта, долгота) и вам нужно выбирать места которые рядом географически, то geospatial фичи редиски вполне могут «затмить» все остальные самые быстрые, но куцые по функционалу варианты. Или другой пример, различные отношения сущностей можно хранить в виде bitmaps и вытаскивать данные за константное и линейное время используя битовые операции которые в редиске достаточно хороши.

Там автор наглухо головой убитый. См. его подпись на гитхабе, которая запрещает мне (и ему самому, лол) пользоваться результатами его труда. Ну ок, не хочет - не буду.

Вы просто не умеете ее готовить

честно? вообще не умею - я из NoSql раньше с монгой работал, кое-что ещё, редис в глаза не видел

сейчас я просто на тесты смотрю - но насколько они реалистичны - не знаю

какого типа данные, сколько и как часто будут в нее заливать и потом выбирать?

любые, совершенно произвольного формата, который 3rd-party софт будет слать и который по загружаемому юзером скрипту будет отсортировываться

А что скажете про тесты Garnet от майкрософт

https://microsoft.github.io/garnet/docs/benchmarking/results-resp-bench

, где оно обгоняет редис многократно (обратите внимание, шкала на графиках логарифмическая)

по личному опыту,самая шустрая LMDB https://www.symas.com/lmdb (git https://github.com/LMDB/lmdb/tree/mdb.master/libraries/liblmdb )

но это строго key-value и никак не близко к redis

строго key-value

мне ровно оно и надо

но «самая шустрая» - по сравнению с кем?

MDBX выше рекомендованный, по сути, рефакторинг LMDB. Пояснения (плюсы/минусы/подводные камни) из первых рук (от автора): тыц, тыц

но «самая шустрая» - по сравнению с кем?

с другими key-value :-) ndbm,gdbm и подобными *dbm. У них api схожие. Когда надо было выбирать такой бэкенд - выбирал/тестировал и lmdb от simas рвал всех как тузик грелку

но сразу - это не сетевые базы. Строго локальные. А у вас " интересует как скорость по сети". Значит не оно

ну а почему не взять какой-нибудь шустрый веб-фреймворк и тупенько хеш-табличку в памяти в качестве хранилища?

но редиска тормозная.

Согласно тестам, его кто только не обгоняет

Обгоняет в чем? И локальная скорость для разных паттернов данных абсолютно разные

что-то вроде Redis, но редиска тормозная. Согласно тестам, его кто только не обгоняет

кстати потому и обгоняют, что Redis де-факто стандарт и везде есть. Всё просто - пишутся синтетические тесты, где специально настроенный «super-puper-db» обгонит лидера рынка. Большинство-же не будут вычитывать тесты и проверять условия тестирования. Тесты надо делать самим.

и добрый совет: если база сетевая и общая (не только исключительно вашей софтиной используется и вообще для взаимодействий) берите уж Redis.

Избежите головной боли про «разрабы бросили проект и теперь он на нас», «странные глюки и просад скорости», «как развернуть на 10-100 хостов», «научить админов» и так далее..

Скомпилировать у себя https://github.com/pmwkaa/ioarena и посмотреть.

А что скажете про тесты Garnet от майкрософт

Ничего не скажу кроме того что это синтетика воняющая маркетингом, все сильно зависит от конкретной задачи, типа данных в ней и выбранной структуры хранения. Одни базы хорошо справляются с одними типами, другие с другими, одним задачам нужна транзакционность/атомарность, другим нет, и т.д. Другими словами, одни движки хороши в одном, другие - в другом.

Поэтому, если у вас данные:

любые, совершенно произвольного формата

то и БД вам нужна любая.

кажется, постгрес кто-то пытался использовать под kv, и экспозиция в рест там должна быть и поддержка джейсона для колонок наверняка для такого

Ок. Спасибо. Гляну LMDB всё равно.