Nenechte se zmást prostorovým měřítkem (1000+ zařízení), pokud jde o výpočetní a/nebo úložné měřítko. Několik desítek 35bajtových insertů za sekundu je triviální zátěž pro jakýkoli mainstreamový DBMS, dokonce i běžící na low-end hardwaru. Podobně 142 milionů záznamů za měsíc je pouze řádově 1~10 gigabajtů úložiště za měsíc, bez jakékoli komprese, včetně indexů.
V komentáři k otázce jste uvedli:
"Všechno je to o spolehlivosti, škálovatelnosti a rychlosti. Je velmi důležité, aby se řešení snadno škálovalo (MongoDB autosharding?), stačí přidat více uzlů, a rychlost je také velmi důležitá
Spolehlivost? Jakýkoli mainstreamový DBMS to může zaručit (za předpokladu, že máte na mysli, že to nepoškodí vaše data a že to nespadne – viz moje diskuse o teorému CAP v dolní části této odpovědi). Rychlost? I u jednoho stroje by 10~100násobek této zátěže neměl být problém. Škálovatelnost? Při současném tempu by se data za celý rok, nekomprimovaná, dokonce i plně indexovaná, snadno vešla do 100 gigabajtů místa na disku (podobně jsme již stanovili, že rychlost vkládání není problém).
Jako takový nevidím žádnou jasnou potřebu exotického řešení, jako je NoSQL, nebo dokonce distribuovaná databáze - obyčejná stará relační databáze, jako je MySQL, by byla v pořádku. Pokud se obáváte převzetí služeb při selhání, stačí nastavit záložní server v konfiguraci master-slave. Pokud mluvíme o 100 nebo 1000 násobku aktuálního měřítka, stačí horizontálně rozdělit několik instancí na základě ID zařízení pro sběr dat (tj. {index oddílu} ={ID zařízení} modulo {počet oddílů}).
Mějte na paměti, že opustit bezpečné a pohodlné hranice světa relačních databází znamená opustit oba jeho reprezentační model a jeho bohatou sadu nástrojů . Díky tomu bude vaše „komplexní dolování dat“ mnohem obtížnější – data do databáze nemusíte jen vkládat, musíte je také dostat ven.
Jak již bylo řečeno, MongoDB a CouchDB jsou neobvykle jednoduché na nasazení a práci s nimi. Jsou také velmi zábavné a udělají vás atraktivnější pro libovolný počet lidí (nejen pro programátory – i pro manažery!).
Všeobecně platí, že ze tří řešení NoSQL, které jste navrhli, je Cassandra nejlepší pro velký objem vložení (samozřejmě, relativně vzato, nemyslím si, že máte velký objem vložek – toto bylo navrženo pro použití na Facebooku ); tomu se brání tím, že se s tím obtížněji pracuje. Takže pokud nemáte nějaké zvláštní požadavky, které jste nezmínili, nedoporučoval bych to pro váš případ použití.
Pokud jste pozitivně nastaveni na nasazení NoSQL, možná budete chtít zvážit teorém CAP. To vám pomůže rozhodnout se mezi MongoDB a CouchDB. Zde je dobrý odkaz:http://blog.nahurst.com/visual-guide-to-nosql-systems. Vše záleží na tom, co myslíte „spolehlivostí“:MongoDB vyměňuje dostupnost za konzistenci, zatímco CouchDB vyměňuje konzistenci za dostupnost . (Cassandra vám umožňuje upřesnit tento kompromis na dotaz tím, že určí, kolik serverů musí být zapsáno/přečteno, aby zápis/čtení bylo úspěšné; AKTUALIZACE:Nyní může i CouchDB s BigCouch! Velmi vzrušující...)
Hodně štěstí ve vašem projektu.