Niezawodna i wydajna baza danych wartości klucza dla systemu Linux?

Question

Potrzebuję szybkiej, niezawodnej i wydajnej pamięci bazy danych kluczy dla systemu Linux. Moje klucze mają około 128 bajtów, a maksymalny rozmiar może wynosić 128K lub 256K. Podsystem bazy danych nie powinien wykorzystywać więcej niż 1 MB pamięci RAM. Całkowita wielkość bazy danych to 20G (!), Ale tylko niewielka część danych jest dostępna jednocześnie. Jeśli to konieczne, mogę przenieść niektóre dane bloki z bazy danych (do zwykłych plików), więc rozmiar spada do maksymalnie 2 GB. Baza danych musi przetrwać awarię systemu bez utraty ostatnio niezmodyfikowanych danych. Będę miał około 100 razy więcej odczytów niż pisze. To jest plus, jeśli może używać urządzenia blokowego (bez systemu plików) jako pamięci masowej. Nie potrzebuję funkcji klient-serwer, tylko biblioteki. Potrzebuję powiązań Python (ale mogę je zaimplementować, jeśli nie są dostępne).

Jakie rozwiązania należy wziąć pod uwagę i które polecasz?

Kandydaci znam, które mogłyby działać:

• (Wiązania Pythona są pytc patrz również pytc example code wspiera mieszań i B + drzew, pliki dziennika transakcji i więcej, wielkość tablicy wiadro jest stała w czasie tworzenia bazy danych, autor musi zamknąć plik, aby dać innym szansę, wiele małych zapisów z ponownym otwarciem pliku dla każdego z nich jest bardzo powolna, serwer Tyrana może pomóc z wieloma małymi zapisami: speed comparison between Tokyo Cabinet, Tokyo Tyrant and Berkeley DB)
• VSDB (bezpieczny nawet na NFS, bez blokowania, a co z barierami?; aktualizacje są bardzo powolne, ale nie tak wolne, jak w cdb; Ostatnia wersja z 2003 roku)
• BerkeleyDB (zapewnia odtwarzanie po awarii; zapewnia transakcji; moduł bsddb Python zapewnia powiązania)
• Samba's TDB (z transakcji i powiązań Python, niektórych użytkowników experienced corruption, czasami mmap() s całego pliku, operacja repack czasami podwaja rozmiar pliku, powoduje tajemnicze niepowodzenia, jeśli baza danych jest większa niż 2G (nawet w systemach 64-bitowych), dostępna jest także implementacja klastra (CTDB), plik jest zbyt duży po wielu modyfikacjach, plik staje się zbyt wolny po wielu hashach , brak wbudowanego sposobu na odbudowanie pliku, bardzo szybkie aktualizacje równoległe przez blokowanie poszczególnych haków mieszających)
• aodbm (append-only tak przetrwa zawieszenie się systemu, z powiązaniami Pythona)
• hamsterdb (z powiązaniami Pythona)
• C-tree (dojrzałego, wszechstronnego rozwiązania komercyjnego z wysoką wydajnością, ma darmową wersję o ograniczonej funkcjonalności)
• stary TDB (od 2001)
• bitcask (log-zorganizowany, napisany w Erlang)
• różne inne implementacje DBM (takich jak gdbm, NDBM, QDBM ,, SDBM Perl czy Ruby; Prawdopodobnie nie mają właściwego odzysku awarii)

nie będę z nich korzystać:

• MemcacheDB (klient-serwer, wykorzystuje BereleleyDB jako backend)
• cdb (potrzebuje do regeneracji cała baza danych przy każdym zapisie)
• http://www.wildsparx.com/apbcdb/ (jw)
• Redis (utrzymuje całą bazę danych w pamięci)
• SQLite (staje się bardzo wolny bez okresowego odkurzania, zobacz autouzupełnianie w pasku adresu w Firefoksie 3.0, mimo że wersje 3.1 i późniejsze sqlite zezwalają na auto_vacuum; uwaga: małe transakcje pisania mogą być bardzo powolne; uwaga: jeśli zajęty procesem robi wiele transakcji, inne procesy głodu, a oni nigdy nie można uzyskać blokady)
• MongoDB (zbyt dużej gramaturze, traktuje wartości jako obiektów o strukturze wewnętrznej)
• Firebird (RDBMS SQL oparte zbyt duża waga)

FYI, recent article about key--value databases w magazynie Linux.

FYI, older software list

FYI, a speed comparison of MemcacheDB, Redis and Tokyo Cabinet Tyrant

Podobne pytania na StackOverflow:

• Key Value Database For Windows?
• Is there a business proven cloud store/Key=>Value Database? (Open Source)

Answer 1

Miałem szczęście z rozwiązaniem Tokyo Cabinet/pytc. Jest bardzo szybki (nieco szybszy niż użycie modułu półki przy użyciu anydbm w mojej implementacji), zarówno do czytania, jak i pisania (choć ja też dużo więcej czytam). Problemem dla mnie była spartańska dokumentacja na temat powiązań Pythona, ale jest wystarczająco dużo przykładów kodu, aby dowiedzieć się, jak zrobić to, co trzeba zrobić. Dodatkowo, szafka tokyo jest dość łatwa do zainstalowania (podobnie jak połączenia Pythona), nie wymaga serwera (jak wspominasz) i wydaje się być aktywnie wspieranym (stabilny, ale nie jest już pod aktywnym rozwojem). Można otwierać pliki w trybie tylko do odczytu, umożliwiając równoczesny dostęp lub tryb odczytu/zapisu, uniemożliwiając innym procesom dostęp do bazy danych.

W lecie szukałem różnych opcji, a moja rada była następująca: wypróbuj różne opcje i zobacz, co najlepiej dla ciebie działa. Byłoby miło, gdyby była po prostu "najlepsza" opcja, ale wszyscy szukają nieco innych funkcji i są skłonni do różnych kompromisów. Ty wiesz najlepiej.

(Powiedział, że to będzie przydatne dla innych, jeśli wspólne, co skończyło się pracy dla Ciebie najlepszy i dlaczego wybrał takie rozwiązanie nad innymi!)

Answer 2

jak o SQLite?

Answer 3

Użyłem bsddb.hashlib() z Pythonem, działało całkiem nieźle.

Answer 4

Być może spodoba Ci się djbcdb, który ma właściwości, o których wspomniałeś.

Answer 5

Co powiecie na dbm.ndbm w Pythonie 3.0?

Answer 6

Kolejna propozycja jest TDB (część Projekt Samba). Używałem go przez moduł tdb, jednak nie mogę powiedzieć, że testowałem jego niezawodność podczas awarii; projekty, z których korzystałem, nie miały takich wymagań i nie mogę znaleźć odpowiedniej dokumentacji.

Answer 7

W my query for a cross-platform ISAM-style database (podobne), również otrzymałem sugestie dotyczące wbudowanej wersji Firebird i GLib.

Answer 8

cdb może obsłużyć dowolną bazę danych do 4 GB, co czyni ją zbyt małą dla 20 GB dostępnej pod ręką.

Answer 9

Riak działa na Linuksie i pozwala dynamicznie dodawać węzły

Answer 10

LMDB jest najbardziej efektywny w bazie pamięci wokół http://symas.com/mdb/inmem/

i również okazały się być najbardziej niezawodne - całkowicie odporny na zderzenia. http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf

z tych Wspominałeś, Tokyo Cabinet udokumentował kwestii korupcji https://www.google.com/search?q=cfengine+tokyo+cabinet+corruption

BerkeleyDB wydaje również została dobrze udokumentowana korupcja, podobnie jak Bitcask. (I bitcask jest tak czy inaczej DB tylko w pamięci, więc bezużyteczny dla twojego 1MB pamięci RAM).

LMDB jest również dobrze obsługiwany w Pythonie, z kilkoma różnymi powiązaniami dostępnymi. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

Zastrzeżone - Jestem autorem LMDB. Ale są to udokumentowane fakty: LMDB to najmniejszy, najbardziej wydajny i najbardziej niezawodny sklep z kluczem/wartością na świecie i nic innego nie jest blisko.