No deje que la escala espacial (más de 1000 dispositivos) lo engañe en cuanto a la escala computacional y/o de almacenamiento. Unas pocas docenas de inserciones de 35 bytes por segundo es una carga de trabajo trivial para cualquier DBMS convencional, incluso si se ejecuta en hardware de gama baja. Del mismo modo, 142 millones de registros por mes son solo del orden de 1 a 10 gigabytes de almacenamiento por mes, sin ninguna compresión, incluidos los índices.
En tu comentario de pregunta, dijiste:
"Todo se trata de confiabilidad, escalabilidad y velocidad. Es muy importante que la solución se escale fácilmente (¿fragmentación automática de MongoDB?) simplemente agregando más nodos, y la velocidad también es muy importante
¿Fiabilidad? Cualquier DBMS convencional puede garantizar esto (suponiendo que quiere decir que no va a corromper sus datos y que no va a fallar; vea mi discusión sobre el teorema CAP al final de esta respuesta). ¿Velocidad? Incluso con una sola máquina, 10~100 veces esta carga de trabajo no debería ser un problema. ¿Escalabilidad? Al ritmo actual, los datos de un año completo, sin comprimir, incluso completamente indexados, cabrían fácilmente en 100 gigabytes de espacio en disco (del mismo modo, ya hemos establecido que la tasa de inserción no es un problema).
Como tal, no veo ninguna necesidad clara de una solución exótica como NoSQL, o incluso una base de datos distribuida:una base de datos relacional simple y antigua como MySQL estaría bien. Si le preocupa la conmutación por error, simplemente configure un servidor de respaldo en una configuración maestro-esclavo. Si estamos hablando de 100 o 1000 veces la escala actual, simplemente particione horizontalmente algunas instancias en función de la ID del dispositivo de recopilación de datos (es decir, {índice de partición} ={id. de dispositivo} módulo {número de particiones}).
Tenga en cuenta que dejar los confines seguros y cómodos del mundo de las bases de datos relacionales significa abandonar tanto su modelo representacional y su conjunto de herramientas enriquecido . Esto hará que su "exploración de datos compleja" sea mucho más difícil:no solo necesita poner datos en la base de datos, también necesita sacarlos.
Habiendo dicho todo eso, MongoDB y CouchDB son extraordinariamente simples de implementar y trabajar con ellos. También son muy divertidos y lo harán más atractivo para cualquier cantidad de personas (no solo para programadores, ¡también para ejecutivos!).
La sabiduría común es que, de las tres soluciones NoSQL que sugirió, Cassandra es la mejor para un alto volumen de inserción (por supuesto, en términos relativos, no creo que tenga alto volumen de inserción:esto fue diseñado para ser utilizado por Facebook ); esto se contrarresta al ser más difícil trabajar con ellos. Entonces, a menos que tenga algunos requisitos extraños que no mencionó, recomendaría no hacerlo para su caso de uso.
Si está configurado positivamente en una implementación NoSQL, es posible que desee considerar el teorema CAP. Esto lo ayudará a decidir entre MongoDB y CouchDB. Aquí hay un buen enlace:http://blog.nahurst.com/visual-guide-to-nosql-systems. Todo se reduce a lo que quiere decir con "confiabilidad":MongoDB intercambia disponibilidad por consistencia, mientras que CouchDB intercambia consistencia por disponibilidad . (Cassandra le permite afinar esta compensación, por consulta, especificando cuántos servidores deben escribirse/leerse para que una escritura/lectura tenga éxito; ACTUALIZACIÓN:¡Ahora también CouchDB, con BigCouch! Muy interesante...)
Mucha suerte en tu proyecto.
