Mam doświadczenie z Redis i MongoDB, ale nie poleciłbym ich w twoim przypadku użycia. Redis jest niesamowity pod każdym względem, ale ponieważ jest tylko pamięcią RAM i nie ma funkcji klastrowania (jeszcze są w fazie rozwoju), nie skaluje się zbyt dobrze. MongoDB nigdy więcej nie użyłbym do niczego, co wymaga niczego poza małym zestawem replik.
Zasadniczo MongoDB jest niedojrzały i całkowicie nieodpowiedni dla jakichkolwiek wymagań dotyczących dużej ilości i wysokiej wydajności. Ma globalną blokadę zapisu, która jest utrzymywana podczas opróżniania dysku, co oznacza, że wydajność może się znacznie różnić w zależności od tego, co robisz. W praktyce sprawia to, że aktualizacje, które powiększają dokumenty, są niemożliwe, a przy usuwaniu trzeba być bardzo ostrożnym. Mówiąc o usuwaniu, poważnie fragmentują bazę danych, więc jeśli wykonasz wiele operacji usuwania, ucierpi na tym wydajność.
Sharding w wersjach 1.8.0 do 1.8.1 był katastrofą. Były kompletne błędy, które nigdy nie powinny były trafić do stabilnego wydania. Konfiguracja nie została poprawnie opróżniona i bardzo łatwo było doprowadzić bazę danych do złego stanu, dzięki czemu fragmenty nigdy nie zostały przeniesione z podstawowego fragmentu. 1.8.2 rozwiązuje większość z nich i wydaje się bardziej stabilny, ale ani trochę nie ufam implementacji shardingu. Dodaj do tego, że sharding jest trudny, nawet gdy wszystko działa, nie zawsze jest łatwo wybrać naturalny klucz shard, a jeśli tego nie zrobisz, spowodujesz wiele smutku.
MongoDB jest naprawdę łatwy w obsłudze, a zestaw funkcji jest naprawdę fajny. Dokumentacja, kierowcy i społeczność są świetne. MongoDB działa znakomicie jako zamiennik MySQL, ale nie używaj go do niczego, co wymaga skalowania.
Obecnie planujemy przenieść się do Cassandry. Uważam, że model dynamo (np. brak węzłów głównych, pisanie i odczytywanie w dowolnym miejscu; po prostu dodawanie węzłów, aby rozwijać klaster) jest atrakcyjny, a funkcje są mniej więcej odpowiednie dla nas. Model danych jest schematem mniej podobnym do MongoDB, choć nieco bardziej ograniczonym (w zasadzie można wybierać między jedno- lub dwupoziomowymi skrótami). Jestem pewien, że społeczność jest dobra, kiedy już się do niej dostaniesz, ale jak dotąd trudno mi znaleźć dobre informacje na temat rozwiązywania typowych problemów, a brakuje dokumentacji. Większość informacji, które znajdziesz na blogach, pochodzi sprzed roku i od tego czasu wydarzyło się wiele rzeczy (0,7 i 0,8 wydają się być naprawdę znaczącymi aktualizacjami, ale większość znalezionych informacji ma około 0,6). Kierowcy nie są też zbyt dojrzali ani dobrze udokumentowani, z tego, co widziałem do tej pory, i wydaje się, że wszyscy kłócą się o to, czy należy użyć Thrift, Avro lub CQL (i to zmieniło się z 0,6 na 0,7 na 0,8) .
Riak jest interesujący, z tych samych powodów co Cassandra, ale dla nas czysty klucz-wartość-store to za mało, musimy mieć możliwość aktualizacji bez wcześniejszego czytania. W przypadku Riaka nie jest to możliwe, ponieważ wartości są po prostu plamami. Wygląda na to, że nie stanowiłoby to dla ciebie problemu.
HBase to kolejny pretendent. Wydaje się, że konfiguracja i uruchamianie jest kłopotliwe ze względu na wiele różnych elementów, ZooKeeper, HDFS itp. Ale model danych jest podobny do Cassandry (kolumny, tj. jednopoziomowe skróty), który działa dobrze dla nas, ale może nie być ważne dla ciebie. Wydaje się to wypróbowane i prawdziwe, ale tak jak w przypadku MongoDB, musisz uważać na problemy z shardingiem, musisz przemyśleć swoje klucze, bo inaczej wpadniesz w kłopoty.
Jest też CouchDB, Project Voldemort i niezliczone inne możliwe opcje. Myślę, że jeśli poważnie myślisz o „ekstremalnie dużych ilościach danych”, to między Cassandrą, Riakiem i HBase. Uderz Riaka, jeśli sama pamięć klucz-wartość nie wystarczy. W zależności od tego, co rozumiesz przez „w pełni spójną replikację”, Cassandra i Riak odpadają, ponieważ istnieje możliwość (niekoniecznie duża i możliwa do dostosowania) odczytania przestarzałej wartości.
W końcu oczywiście musisz wypróbować to w swoim konkretnym przypadku użycia, więc jedyne, co naprawdę powinieneś wziąć do domu z tej odpowiedzi, to:nie zawracaj sobie głowy MongoDB.
