Napisz ciężki, zreplikowany, przechowujący klucz i wartość o większej pamięci niż pamiętaj

Question

Szukam magazynu wartości kluczy, który może być używany z instancji EC2.

• pozycja jest tylko nieuporządkowane ciąg, nie indeksowanie wymagane
• rozmiar elementu nawet do ~ 5MB ale zazwyczaj poniżej 10kB
• wiele zapisów
• odczyt nie musi być szybki, może być memcache umieszczone w przedniej że buforuje często potrzebne czyta
• danych jest zbyt duży, aby zmieścić się w pamięci
• Ewentualne Konsystencja jest w porządku
• demon, który można uzyskać fr om wiele maszyn jest wymagane

Idealnie coś AWS gospodarzem byłby idealny, ale:

• S3 nie pasuje z powodu zbyt wielu zapisów
• SimpleDB/DynamoDb nie pasują ze względu na wielkość przedmiotu limity i indeksowanie nie są wymagane.

Ponieważ na rynku istnieje wiele sklepów z kluczowymi wartościami, trudno jest wybrać najlepszy. Który z nich poleciłbyś?

Answer 1

znalazłem idealne rozwiązanie dla mojego przypadku użycia: memcachedb

Nie robi fantazyjny dokument/indeksowanie, to tylko prosty sklep wartość klucza.

Jednak nie przeprowadziłem jeszcze żadnych testów wydajności.

Edit:

Wpadliśmy memcachedb powodu problemów z replikacją. Zamiast tego uruchamiamy teraz mongodb. Mongodb wymaga znacznie więcej miejsca na dysku i więcej zasobów w ogóle. Zestawy replik działają jednak niezawodnie i są łatwe w konfiguracji.

Answer 2

Może powinieneś spróbować MongoDB:
http://www.mongodb.org/display/DOCS/Amazon+EC2

Szybki start:
http://www.mongodb.org/display/DOCS/Amazon+EC2+Quickstart

Darmowe kursy 10gen i wideo prezentacje:
http://www.10gen.com/presentations/nyc-meetup-group/mongodb-and-ec2-a-love-story

Inne magazynów klucz-wartość:
http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html

Komentarze o Riak i ich przechowywania szczególnie bitcask i innostore:
http://basho.com/blog/technical/2011/07/01/Leveling-the-Field/

RaptorDB: a wyjątkowo małe rozmiary i szybko osadzony, NoSQL, utrzymywały słownika bazy danych za pomocą drzewie B + lub szmer hash indeksowanie. Został zaprojektowany przede wszystkim do przechowywania danych JSON (zobacz moją implementację fastJSON), ale może przechowywać każdy typ danych, które mu dajesz.

HamsterDB: Wspaniały silnik napisany w języku C++, który pod wrażeniem mi wiele dla jego prędkości, kiedy byłem przy użyciu kodu Aarons Watters do indeksowania. (RaptorDB zjada go żywcem teraz ... ahem!) Jest dość duży w 600 KB na wydanie 64-bitowe.

ESENT PersistentDictionary: Projekt na CodePlex, które jest częścią kolejny projekt, który realizuje zarządzanej otoki nad zbudowany w systemie Windows silnika przechowującego dane ESENT.Wydajność słownika obniża się wykładniczo po indeksowaniu 40 000 elementów, a plik indeksu po prostu rośnie na kluczach GUID. Podobno po rozmowach z właścicielami projektu, , jest to obecnie znany problem.

Gabinet Tokyo/Kyoto: C++ wdrożenie klucza sklepu, który jest bardzo szybki. Gabinet Tokyo jest indeksatorem drzewa b + , a szafka Kyoto jest narzędziem indeksującym MurMur2.

4aTech słownik: Jest to kolejny artykuł na CodeProject która robi samo, komercyjna wersja na stronie internetowej jest ogromny (450KB) a nie ponuro Wydajność mądry kluczy GUID po 50,000 pozycji indeksowanych.

BerkeleyDB: Wielki tatuś całej bazy danych, która jest własnością Oracle i jest w 3 smakach, sklep klawisz C++, Java i klucz sklep XML bazy danych.

(źródło Cytat: http://www.codeproject.com/Articles/190504/RaptorDB)

Answer 3

Wydaje się być idealnym przypadkiem użycia dla HBase. Daje dużą przepustowość zapisu, szczególnie jeśli twoje klucze insertowe są nieco losowe. HBase nie jest zazwyczaj reklamowany jako sklep K/V, ale powinien działać dobrze. The AWS documentation przedstawia niektóre przypadki użycia, które warto bliżej przyjrzeć. Wadą jest to, że HBase może zrobić o wiele więcej niż tylko K/V, więc może być bardziej skomplikowany (i skomplikowany) niż to, czego potrzebujesz.

Answer 4

Couchbase Brzmi jak dobry mecz dla Ciebie. To coś w rodzaju memowania z pamięcią dyskową.

Plusy:

• Jest to baza danych klucz/wartość. Możesz przechowywać dowolny blob binarny, który chcesz. Od wersji 2.0 obsługuje on przechowywanie danych jako json i uruchamianie zapytań oraz mapowanie/zmniejszanie. Ale jeśli nie potrzebujesz tego, użycie go jako klucza/wartości działa świetnie.

• Ze wszystkich baz danych NoSQL, które wypróbowałem, jest najszybszy. Może tak być, ponieważ twoje zapisy nie są natychmiastowo zatwierdzane na dysku. Zamiast tego otrzymasz potwierdzenie, gdy zapis zostanie zreplikowany w klastrze. Dane są zapisywane na dysku asynchronicznie. Tak więc jedną potencjalną wadą jest to, że jeśli wszystkie twoje węzły ulegną awarii jednocześnie (np. Twoje centrum danych straci moc), możesz utracić dane. W zależności od aplikacji może to być problem (lub jeśli cały klaster zostanie wyłączony, prawdopodobnie masz większe problemy).

• Z mojego doświadczenia wynika, że ​​jest niezawodny. Jeśli węzeł przestanie działać, klaster będzie działał, a przełączenie awaryjne jest bardzo łatwe. Dodanie nowych węzłów również jest łatwe.

• Dane nie muszą się mieścić w pamięci. Zostanie on zapisany na dysku i odpowiednio wczytany i wysłany.

• Interfejs administracyjny jest bardzo, bardzo miły. Ma ładne wykresy na żywo do monitorowania klastra.

• Jest kompatybilny wstecz z protokołem memcached. Jeśli masz już kod, który używa memcached, byłoby całkiem proste, gdyby używał go zamiast Couchbase.

Wady:

• Produkt jest nadal dość młody, więc dokumentacja i pomoc narzędzia są nieco brakuje. Czasami może to być trochę denerwujące.