sql >> Databáze >  >> NoSQL >> Redis

Které NoSQL databáze pro extrémně velké objemy dat

Mám zkušenosti s Redis a MongoDB, ale nedoporučuji ani jedno pro váš případ použití. Redis je úžasný ve všech ohledech, ale protože je pouze RAM a nemá žádné funkce shlukování (zatím jsou ve vývoji), neškáluje se příliš dobře. MongoDB bych už nikdy nepoužil pro nic, co potřebuje něco jiného než malou sadu replik.

MongoDB je v zásadě nevyzrálý a zcela nevhodný pro jakýkoli druh požadavků na vysoký objem a vysoký výkon. Má globální zámek zápisu, který je držen během vyprázdnění disku, což znamená, že výkon se může výrazně lišit v závislosti na tom, co děláte. V praxi to znemožňuje aktualizace, které rozšiřují dokumenty, a také musíte být velmi opatrní při mazání. Když už mluvíme o mazáních, značně fragmentují databázi, takže pokud provedete hodně mazání, váš výkon utrpí.

Sharding v 1.8.0 až 1.8.1 byla katastrofa. Byly tam úplné chyby, které se nikdy neměly dostat do stabilní verze. Konfigurace nebyla správně vyprázdněna a bylo velmi snadné dostat databázi do špatného stavu, aby se bloky nikdy neodsunuly z primárního fragmentu. 1.8.2 většinu z nich řeší a zdá se stabilnější, ale implementaci shardingu nevěřím ani trochu. Přidejte k tomu, že sharování je těžké, i když vše funguje, není vždy snadné vybrat přirozený klíč shardu, a pokud sharování neuděláte, způsobí vám mnoho zármutku.

S MongoDB se opravdu snadno pracuje a sada funkcí je opravdu pěkná. Dokumentace, ovladače a komunita jsou skvělé. MongoDB funguje skvěle jako náhrada za MySQL, ale nepoužívejte jej pro nic, co je třeba škálovat.

Momentálně uvažujeme o přestěhování do Cassandry. Model dynama (např. žádné hlavní uzly; psát a číst kdekoli; jednoduše přidat uzly, aby se cluster rozrostl) považuji za přesvědčivý a funkce jsou pro nás víceméně vhodné. Datový model je méně schématický jako MongoDB, i když trochu omezenější (v zásadě si můžete vybrat mezi jednou nebo dvěma úrovněmi hash). Jsem si jistý, že komunita je dobrá, jakmile se do ní dostanete, ale zatím je pro mě těžké najít dobré informace o tom, jak řešit běžné problémy, a chybí dokumentace. Většina informací, které najdete na blozích, je rok stará a od té doby se událo mnoho věcí (0.7 a 0.8 se zdají být opravdu významné aktualizace, ale většina věcí, které najdete, je asi 0,6). Ovladače také nejsou příliš vyspělé nebo dobře zdokumentované, z toho, co jsem zatím viděl, a zdá se, že se všichni hádají, zda je třeba použít Thrift, Avro nebo CQL (a to se změnilo z 0,6 na 0,7 na 0,8) .

Riak je zajímavý, ze stejných důvodů jako Cassandra, ale pro nás nestačí pouze úložiště klíčů a hodnot, musíme být schopni aktualizovat bez předchozího čtení. S Riakem to není možné, protože hodnoty jsou jen kuličky. Zdá se však, že by to pro vás nebyl problém.

HBase je dalším uchazečem. Zdá se, že je obtížné nastavit a spustit kvůli mnoha různým částem, ZooKeeper, HDFS atd. Ale datový model je podobný Cassandře (sloupcové, tj. jednoúrovňové hashe), což nám funguje dobře, ale nemusí být důležité pro vás. Zdá se to vyzkoušené a pravdivé, ale stejně jako u MongoDB si musíte dávat pozor na problémy se shardováním, musíte trochu přemýšlet o svých klíčích, jinak se dostanete do problémů.

K dispozici je také CouchDB, Project Voldemort a nespočet dalších možných možností. Myslím, že pokud to myslíš s "extrémně vysokými objemy dat" vážně, tak je to mezi Cassandrou, Riakem a HBase. Udeřte na Riaka, pokud čisté úložiště párů klíč-hodnota nestačí. V závislosti na tom, co myslíte "plně konzistentní replikací", pak Cassandra a Riak jsou mimo, protože existuje možnost (ne nutně velká a laditelná) čtení zastaralé hodnoty.

Nakonec to samozřejmě musíte vyzkoušet na svém konkrétním případu použití, takže vše, co byste si z této odpovědi měli vzít domů, je:neobtěžujte se MongoDB.



  1. Snižte dobu provádění úloh sidekiq

  2. PyMongo -- iterace kurzoru

  3. Názvy polí FieldPath nesmí obsahovat '.' ve skupině $

  4. MongoDB získat SubDocument