Låt inte den rumsliga skalan (1000+ enheter) vilseleda dig när det gäller beräknings- och/eller lagringsskalan. Några dussin 35-byte-inlägg per sekund är en trivial arbetsbelastning för alla vanliga DBMS, även körs på low-end hårdvara. Likaså är 142 miljoner poster per månad bara i storleksordningen 1~10 gigabyte lagring per månad, utan någon komprimering, inklusive index.
I din frågekommentar sa du:
"Allt handlar om tillförlitlighet, skalbarhet och hastighet. Det är mycket viktigt att lösningen skalas lätt (MongoDB autosharding?) bara genom att slänga in fler noder, och hastigheten är också mycket viktig
Pålitlighet? Alla vanliga DBMS kan garantera detta (förutsatt att du menar att det inte kommer att korrumpera dina data, och det kommer inte att krascha - se min diskussion om CAP-teoremet längst ner i det här svaret). Hastighet? Även med en enda maskin bör 10~100 gånger denna arbetsbelastning inte vara ett problem. Skalbarhet? Med nuvarande hastighet skulle ett helt års data, okomprimerad, till och med helt indexerad, lätt rymmas inom 100 gigabyte diskutrymme (likaså har vi redan fastställt att insättningshastigheten inte är ett problem).
Som sådan ser jag inget tydligt behov av en exotisk lösning som NoSQL, eller ens en distribuerad databas - en vanlig, gammal relationsdatabas som MySQL skulle vara bra. Om du är orolig för failover, ställ bara in en backupserver i en master-slave-konfiguration. Om vi pratar 100- eller 1000-tals gånger den nuvarande skalan, partitionera bara några få instanser horisontellt baserat på ID för datainsamlingsenheten (dvs. {partitionsindex} ={enhets-id} modulo {antal partitioner}).
Tänk på att att lämna relationsdatabasvärldens trygga och bekväma gränser innebär att man överger både dess representationsmodell och dess rika verktygsuppsättning . Detta kommer att göra din "komplexa dataminering" mycket svårare - du behöver inte bara lägga in data i databasen, du måste också få ut den.
Med detta sagt är MongoDB och CouchDB ovanligt enkla att distribuera och arbeta med. De är också väldigt roliga och kommer att göra dig mer attraktiv för hur många som helst (inte bara programmerare – även chefer!).
Den gemensamma visdomen är att av de tre NoSQL-lösningar du föreslog, är Cassandra den bästa för hög insatsvolym (naturligtvis, relativt sett, tror jag inte att du har hög insatsvolym - detta designades för att användas av Facebook ); detta motverkas av att det är svårare att arbeta med. Så om du inte har några konstiga krav som du inte nämnde, skulle jag avråda från det, för ditt bruk.
Om du är positivt inställd på en NoSQL-distribution, kanske du vill överväga CAP-teoremet. Detta hjälper dig att välja mellan MongoDB och CouchDB. Här är en bra länk:http://blog.nahurst.com/visual-guide-to-nosql-systems. Allt beror på vad du menar med "tillförlitlighet":MongoDB byter tillgänglighet mot konsistens, medan CouchDB byter konsistens mot tillgänglighet . (Cassandra låter dig finjustera denna kompromiss, per fråga, genom att ange hur många servrar som måste skrivas/läsas för att en skriv/läsning ska lyckas; UPPDATERING:Nu kan CouchDB också göra det, med BigCouch! Mycket spännande...)
Lycka till i ditt projekt.