Non lasciare che la scala spaziale (oltre 1000 dispositivi) ti inganni per quanto riguarda la scala computazionale e/o di archiviazione. Poche dozzine di inserti da 35 byte al secondo sono un carico di lavoro banale per qualsiasi DBMS mainstream, anche in esecuzione su hardware di fascia bassa. Allo stesso modo, 142 milioni di record al mese sono solo nell'ordine di 1~10 gigabyte di spazio di archiviazione al mese, senza alcuna compressione, inclusi gli indici.
Nel tuo commento alla domanda, hai detto:
"Si tratta di affidabilità, scalabilità e velocità. È molto importante che la soluzione si ridimensioni facilmente (sharding automatico di MongoDB?) semplicemente inserendo più nodi e anche la velocità è molto importante
Affidabilità? Qualsiasi DBMS tradizionale può garantirlo (supponendo che tu intenda che non danneggerà i tuoi dati e non andrà in crash - vedi la mia discussione sul teorema CAP in fondo a questa risposta). Velocità? Anche con una singola macchina, 10~100 volte questo carico di lavoro non dovrebbe essere un problema. Scalabilità? Alla velocità attuale, i dati di un anno intero, non compressi, anche completamente indicizzati, si adatterebbero facilmente a 100 gigabyte di spazio su disco (allo stesso modo, abbiamo già stabilito che la velocità di inserimento non è un problema).
In quanto tale, non vedo alcuna chiara necessità di una soluzione esotica come NoSQL, o anche di un database distribuito:un semplice database relazionale vecchio come MySQL andrebbe bene. Se sei preoccupato per il failover, imposta un server di backup in una configurazione master-slave. Se stiamo parlando di 100 o 1000 volte la scala attuale, partiziona orizzontalmente alcune istanze in base all'ID del dispositivo di raccolta dati (ovvero {indice di partizione} ={id dispositivo} modulo {numero di partizioni}).
Tieni presente che uscire dai confini sicuri e confortevoli del mondo dei database relazionali significa abbandonare entrambi i suoi modello rappresentativo e il suo ricco set di strumenti . Ciò renderà il tuo "complesso datamining" molto più difficile:non devi solo inserire i dati nel database, devi anche estrarli.
Detto questo, MongoDB e CouchDB sono insolitamente semplici da implementare e lavorare. Sono anche molto divertenti e ti renderanno più attraente per qualsiasi numero di persone (non solo programmatori, anche dirigenti!).
La saggezza comune è che, delle tre soluzioni NoSQL che hai suggerito, Cassandra è la migliore per un volume di inserimento elevato (ovviamente, relativamente parlando, non credo che tu abbia volume di inserto elevato:è stato progettato per essere utilizzato da Facebook ); questo è contrastato dall'essere più difficile da lavorare. Quindi, a meno che tu non abbia degli strani requisiti che non hai menzionato, ti consiglierei di non farlo, per il tuo caso d'uso.
Se sei impostato positivamente su una distribuzione NoSQL, potresti prendere in considerazione il teorema CAP. Questo ti aiuterà a decidere tra MongoDB e CouchDB. Ecco un buon link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Tutto si riduce a cosa intendi per "affidabilità":MongoDB scambia disponibilità per coerenza, mentre CouchDB scambia coerenza per disponibilità . (Cassandra ti consente di perfezionare questo compromesso, per query, specificando quanti server devono essere scritti/letti affinché una scrittura/lettura abbia successo; AGGIORNAMENTO:ora, anche CouchDB, con BigCouch! Molto eccitante...)
In bocca al lupo per il tuo progetto.
