Laat u niet misleiden door de ruimtelijke schaal (1000+ apparaten) wat betreft de reken- en/of opslagschaal. Een paar dozijn 35-byte-inserts per seconde is een triviale belasting voor elke reguliere DBMS, zelfs als deze op low-end hardware draait. Evenzo zijn 142 miljoen records per maand slechts in de orde van 1~10 gigabyte opslagruimte per maand, zonder enige compressie, inclusief indexen.
In uw vraagopmerking zei u:
"Het draait allemaal om betrouwbaarheid, schaalbaarheid en snelheid. Het is erg belangrijk dat de oplossing eenvoudig schaalt (MongoDB autosharding?) door gewoon meer knooppunten in te voeren, en de snelheid is ook erg belangrijk
Betrouwbaarheid? Elke reguliere DBMS kan dit garanderen (ervan uitgaande dat u bedoelt dat het uw gegevens niet zal beschadigen en niet zal crashen - zie mijn bespreking van de CAP-stelling onderaan dit antwoord). Snelheid? Zelfs met een enkele machine zou 10 tot 100 keer deze werkbelasting geen probleem moeten zijn. schaalbaarheid? Met het huidige tempo passen de gegevens van een heel jaar, ongecomprimeerd of zelfs volledig geïndexeerd, gemakkelijk in 100 gigabyte schijfruimte (we hebben ook al vastgesteld dat de invoegsnelheid geen probleem is).
Als zodanig zie ik geen duidelijke behoefte aan een exotische oplossing zoals NoSQL, of zelfs een gedistribueerde database - een eenvoudige, oude relationele database zoals MySQL zou prima zijn. Als u zich zorgen maakt over failover, stelt u gewoon een back-upserver in een master-slave-configuratie in. Als we het hebben over 100 of 1000 keer de huidige schaal, verdeel dan gewoon een paar instanties horizontaal op basis van de ID van het apparaat voor het verzamelen van gegevens (d.w.z. {partition index} ={device id} modulo {aantal partities}).
Houd in gedachten dat het verlaten van de veilige en comfortabele grenzen van de relationele databasewereld betekent dat zowel het representatieve model wordt opgegeven. en zijn rijke toolset . Dit maakt uw "complexe datamining" veel moeilijker - u hoeft niet alleen gegevens in de database te plaatsen, u moet ze er ook uit halen.
Dat gezegd hebbende, MongoDB en CouchDB zijn buitengewoon eenvoudig te implementeren en mee te werken. Ze zijn ook erg leuk en zullen je aantrekkelijker maken voor een groot aantal mensen (niet alleen programmeurs, maar ook leidinggevenden!).
De algemene wijsheid is dat van de drie NoSQL-oplossingen die u voorstelde, Cassandra het beste is voor een hoog invoegvolume (natuurlijk, relatief gezien, denk ik niet dat u hebt hoog invoegvolume - dit is ontworpen om te worden gebruikt door Facebook ); dit wordt tegengegaan door moeilijker om mee te werken. Dus tenzij je vreemde vereisten hebt die je niet hebt genoemd, zou ik het afraden, voor jouw gebruik.
Als u positief ingesteld bent op een NoSQL-implementatie, kunt u de CAP-stelling overwegen. Dit zal u helpen kiezen tussen MongoDB en CouchDB. Hier is een goede link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Het komt allemaal neer op wat je bedoelt met "betrouwbaarheid":MongoDB verruilt beschikbaarheid voor consistentie, terwijl CouchDB consistentie verruilt voor beschikbaarheid . (Met Cassandra kun je deze afweging per zoekopdracht verfijnen door te specificeren hoeveel servers moeten worden geschreven/gelezen om een schrijven/lezen te laten slagen; UPDATE:Nu kan CouchDB dat ook, met BigCouch! Erg spannend...)
Veel succes met je project.