Lad ikke den rumlige skala (1000+ enheder) vildlede dig med hensyn til beregnings- og/eller lagerskalaen. Et par dusin 35-byte inserts i sekundet er en triviel arbejdsbyrde for enhver almindelig DBMS, selv kører på low-end hardware. Ligeledes er 142 millioner poster pr. måned kun i størrelsesordenen 1~10 gigabyte lagerplads pr. måned, uden nogen komprimering, inklusive indekser.
I din spørgsmålskommentar sagde du:
"Det handler om pålidelighed, skalerbarhed og hastighed. Det er meget vigtigt, at løsningen let skaleres (MongoDB autosharding?) bare ved at smide flere noder ind, og hastigheden er også meget vigtig
Pålidelighed? Enhver almindelig DBMS kan garantere dette (forudsat at du mener, at det ikke vil ødelægge dine data, og det ikke vil gå ned - se min diskussion af CAP-sætningen nederst i dette svar). Fart? Selv med en enkelt maskine burde 10~100 gange denne arbejdsbyrde ikke være et problem. Skalerbarhed? Med den nuværende hastighed ville et helt års data, ukomprimeret, endda fuldt indekseret, nemt passe inden for 100 gigabyte diskplads (på samme måde har vi allerede fastslået, at indsættelseshastigheden ikke er et problem).
Som sådan ser jeg ikke noget klart behov for en eksotisk løsning som NoSQL eller endda en distribueret database - en almindelig, gammel relationsdatabase som MySQL ville være helt fint. Hvis du er bekymret for failover, skal du bare opsætte en backup-server i en master-slave-konfiguration. Hvis vi taler 100- eller 1000-vis af gange den nuværende skala, skal du bare opdele nogle få tilfælde vandret baseret på id'et for dataindsamlingsenheden (dvs. {partitionsindeks} ={enheds-id} modulo {antal partitioner}).
Husk på, at det at forlade de trygge og behagelige rammer i relationsdatabaseverdenen betyder at opgive både dens repræsentationsmodel og dets rige værktøjssæt . Dette vil gøre din "komplekse dataaminering" meget vanskeligere - du behøver ikke kun at lægge data ind i databasen, du skal også få dem ud.
Når alt dette er sagt, er MongoDB og CouchDB ualmindeligt enkle at implementere og arbejde med. De er også meget sjove og vil gøre dig mere attraktiv for et vilkårligt antal mennesker (ikke kun programmører – også ledere!).
Den almindelige visdom er, at af de tre NoSQL-løsninger, du foreslog, er Cassandra den bedste til høj indsatsvolumen (naturligvis, relativt set, tror jeg ikke, du har høj indsatsvolumen - dette er designet til at blive brugt af Facebook ); dette imødegås ved at være sværere at arbejde med. Så medmindre du har nogle mærkelige krav, du ikke nævnte, vil jeg fraråde det, til din brug.
Hvis du er positivt indstillet på en NoSQL-implementering, kan du overveje CAP-sætningen. Dette vil hjælpe dig med at vælge mellem MongoDB og CouchDB. Her er et godt link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Det hele kommer ned til, hvad du mener med "pålidelighed":MongoDB bytter tilgængelighed for konsistens, hvorimod CouchDB bytter sammenhæng med tilgængelighed . (Cassandra giver dig mulighed for at finessere denne afvejning, pr. forespørgsel, ved at specificere, hvor mange servere der skal skrives/læses for at skrive/læse en succes; OPDATERING:Nu, det kan CouchDB også, med BigCouch! Meget spændende...)
Held og lykke med dit projekt.