Poszukuję bazę danych key-value - Redis ale z zapisem na dysku

Poszukuję bazę danych do zapisu prostych wartości key-value. Danych będzie dużo (kilka GB miesięcznie), będą rzadko odczytywane dlatego Redis odpada. Nie potrzebuję i nie chcę tego trzymać w pamięci RAM. Oprócz prostych Put(key, value), Get(key) oraz Delete(key) potrzebuję jeszcze mieć możliwość usuwania według przedziału wartości klucza, które w moim przypadku będą wartościami liczbowymi (64 bit). Np. chcę usunąć wszystkie klucze, których wartość jest mniejsza niż 5 mln.

Słyszałem wcześniej o RocksDB oraz LevelDB. Zdziwiłem się, gdy chciałem znaleźć obrazy Docker i nic nie znalazłem sensownego. Z tego, co rozumiem to nie są bazy danych standalone jak Redis, tylko biblioteki, takie wbudowane bazy danych.

Pytanie, jeśli nie RocksDB ani LevelDB to co innego? Chcę to użyć w projekcie ASP.NET Core gdzie jest już PostgreSQL oraz Entity Framework. Mogę to zapisywać w Postgresie, ale te dane będą tam niepotrzebne, ponadto zapis tych key-value ma być szybki, nie potrzebuję odpalać transakcji bazodanowej dla każdego zapisu.

Będziesz to eksploatować z jednego komputera, czy rozproszone na wiele?

https://en.wikipedia.org/wiki/Key%E2%80%93value_database

Polecałbym Berkley DB , zwłaszcza, że to chyba Oracle przejęło

A czy nie może być to po prostu redis z entrylogiem, czyli generalnie włączoną opcją backupowania wszystkiego na dysku ustawioną na jakąś wysoką częstotliwość?
Działać on może w różnych trybach -> pierwszy to po prostu zrzut obecnego stanu bazy danych, tego co jest w pamięci, np. co 5 minut albo appendonly, czyli dorzucanie kolejnych eventów któ©e są potrzebne by uzyskać obecny stan, krok po kroku przy czym co jakiś czas jest to optymalizowane. Imo nie uważam, że redis KONIECZNIE odpada, bo można po prostu traktować go jako interfejs do pliku appendonly na przykład.

Natomiast czy jest to rozwiązanie optymalne to śmiem wątpić.

Może jakiś gotowy klocuszek od AWSa czy innego clouda i nie zajmuj sobie tym głowy? Jakie są dokładnie wymagania?

Edit: dorzucam gdzieś tam w temacie fajną prezke by @jarek
Warto obejrzeć

To trzymaj to w Postgresie w tabeli dwukolumnowej z indeksem na kluczu. Kilka giga to nie jest jakoś strasznie dużo. Możesz to wrzucić do osobnej bazy z inna polityką backupów itp. Kolejna metoda przetrzymywania danych skomplikuje ci rozwiązanie (backapy, utrzymanie, serwisowanie, updaty, zapewnienie bezpieczeństwa), a moim zdaniem nie ma to uzasadnienia biznesowego, przynajmniej na tyle, ile opisałeś w tym wątku.
Możesz jeszcze napisać czym ma być klucz (jakim typem danych i jak długi oraz czym mają być dane).

grski napisał(a):

A czy nie może być to po prostu redis z entrylogiem, czyli generalnie włączoną opcją backupowania wszystkiego na dysku ustawioną na jakąś wysoką częstotliwość?

No ale po co to trzymać w ramie jak jest niepotrzebne? Redis ma sens jak potrzebujesz szybkiego dostępu do danych.

Napisałeś, że nie chcesz tego trzymać w RAM, i nie chcesz w postgresql to może najprostszy na świecie SQLite?

@woolfik: Rasowa embedded key-value przez brak interpretera SQL (oraz sieci) bije szybkościowo rozwiązanie SQLowe o rząd wielkości

Z tego, co rozumiem to nie są bazy danych standalone jak Redis, tylko biblioteki, takie wbudowane bazy danych.

@cabron4p: co masz kontra bibliotece (embedded database), chcesz to cluodować?

Pytanie, jeśli nie RocksDB ani LevelDB to co innego?

Kwerenda zwraca sporo wyników, stoją za tym zarówno firmy, jak i single (nie mam własnej opinii)
https://www.google.com/search?q=c%23+key+value+database

Nie sądziłem że to kiedykolwiek powiem, ale może Mongo?
Wiem że mongo to baza dokumentowa, ale przecież baza dokumentowa jest tylko rozbudowaną wersją bazy klucz wartość.
Z drugiej strony jeśli obawiasz się że transakcje na Postgresie będą spowalniać (bo rozumiem że na razie żadnych testów nie robiłeś i wróżymy z fusów) to można obniżyć poziom transakcji do Read uncommitted

AnyKtokolwiek napisał(a):

@woolfik: Rasowa embedded key-value przez brak interpretera SQL (oraz sieci) bije szybkościowo rozwiązanie SQLowe o rząd wielkości

A nie przez brak sieci? Wolałbym porównanie embedded key-value vs SQLite lub noembedded key-value vs PostgreSQL. Wtedy byłaby to równa walka :)

KamilAdam napisał(a):

AnyKtokolwiek napisał(a):

@woolfik: Rasowa embedded key-value przez brak interpretera SQL (oraz sieci) bije szybkościowo rozwiązanie SQLowe o rząd wielkości

A nie przez brak sieci? Wolałbym porównanie embedded key-value vs SQLite lub noembedded key-value vs PostgreSQL. Wtedy byłaby to równa walka :)

Tyle że w 2021 non-embedded to cloudowe serwery, z wielkim narzutem

Uważam że "interpreter" jest wiodący (w praktyce więcej modułów, ja dostrzegam przynajmniej: parsowanie, OGARNIANIE RELACJI, OPTYMALIZACJA, WYKONANIE, operacje z indeksami, operacje ze zbiorem głownym i pewnie się przypomną inne klocki)
Każda baza SQL ma to samo, co embeded key-value (gospodarka indeksowa) PLUS wielki, wielki narzut, bardzo dużo RAM i CPU

Sieć jest dodatkowym argumentem, ale transmisja kwerendy i wyników SQL, kosztuje znacznie mniej (dane są przetworzone) niż transmisja plików w dawnych bazach plikowych

Lat temu sporo testowałem na Javie Kyoto Cabinet i spełnił obietnice (przebitkę *N w stosunku do SQL)

Riak pozwala używać LevelDB na backendzie. Jest i Docker. Ale nie używałem tego, więc nie wiem na ile jest sensowny.

Dziękuję wszystkim za odpowiedzi. Po ich przeanalizowaniu uznałem, że szukanie bazy na "zapas" pochłonie mi za dużo czasu i eksperymentowania, dlatego tak jak sugeruje KamilAdam skorzystam z Postgresa z poziomem transakcji Read uncommitted. Jak to będzie za wolne to wtedy powrócę do martwienia się.

Znalazłem jeszcze InfluxDB, który mógłby być ok.

Jeżeli bezpieczeństwo recovery nie jest dla Ciebie ważne, to wyłącz fsync w PostgreSQL-u - wtedy prędkość zapisu znacznie się zwiększy

@cabron4p: a co Ty dokładnie chcesz składować? Bo InfluxDB jest do bardzo specyficznych zastosowań.

Dodatkowo czy już sprawdziłeś, że Postgres nie wyrabia, czy tylko sobie gdybasz?

Uzyj jsonb w Postgre , to zdziwisz sie jeszcze bardziej - a ta baza to IMHO najlepszy Open Sourcowy i Darmowy RDBMS, którego można używać jako NOSQL.

Po kiego grzyba mu JSONB do par key-value, to chyba najgorsze co można wymyślić w tym przypadku. JSONB jest dobry do przechowywania dokumentów/danych o nieokreślonej strukturze.