Não deixe que a escala espacial (mais de 1.000 dispositivos) o engane quanto à escala computacional e/ou de armazenamento. Algumas dezenas de inserções de 35 bytes por segundo são uma carga de trabalho trivial para qualquer DBMS convencional, mesmo executando em hardware de baixo custo. Da mesma forma, 142 milhões de registros por mês são apenas da ordem de 1 a 10 gigabytes de armazenamento por mês, sem nenhuma compactação, incluindo índices.
No comentário da sua pergunta, você disse:
"É tudo uma questão de confiabilidade, escalabilidade e velocidade. É muito importante que a solução escale facilmente (autosharding MongoDB?) apenas colocando mais nós, e a velocidade também é muito importante
Confiabilidade? Qualquer DBMS convencional pode garantir isso (supondo que você queira dizer que não vai corromper seus dados e não vai travar - veja minha discussão sobre o teorema CAP na parte inferior desta resposta). Velocidade? Mesmo com uma única máquina, 10 a 100 vezes essa carga de trabalho não deve ser um problema. Escalabilidade? Na taxa atual, os dados de um ano inteiro, descompactados, mesmo totalmente indexados, caberiam facilmente em 100 gigabytes de espaço em disco (da mesma forma, já estabelecemos que a taxa de inserção não é um problema).
Como tal, não vejo nenhuma necessidade clara de uma solução exótica como NoSQL, ou mesmo um banco de dados distribuído - um banco de dados relacional simples e antigo, como o MySQL, seria ótimo. Se você está preocupado com o failover, basta configurar um servidor de backup em uma configuração mestre-escravo. Se estamos falando de 100 ou 1000 vezes a escala atual, apenas particione horizontalmente algumas instâncias com base no ID do dispositivo de coleta de dados (ou seja, {índice de partição} ={id do dispositivo} módulo {número de partições}).
Tenha em mente que deixar os limites seguros e confortáveis do mundo do banco de dados relacional significa abandonar tanto seu modelo de representação e seu conjunto de ferramentas avançado . Isso tornará sua "mineração de dados complexa" muito mais difícil - você não precisa apenas colocar dados no banco de dados, você também precisa retirá-los.
Dito tudo isso, MongoDB e CouchDB são extraordinariamente simples de implantar e trabalhar. Eles também são muito divertidos e o tornarão mais atraente para qualquer número de pessoas (não apenas programadores - executivos também!).
O senso comum é que, das três soluções NoSQL que você sugeriu, Cassandra é a melhor para alto volume de inserção (claro, relativamente falando, eu não acho que você tem alto volume de inserção - foi projetado para ser usado pelo Facebook ); isso é combatido por ser mais difícil de trabalhar. Portanto, a menos que você tenha alguns requisitos estranhos que não mencionou, eu recomendaria contra isso, para o seu caso de uso.
Se você estiver positivamente definido em uma implantação NoSQL, convém considerar o teorema CAP. Isso ajudará você a decidir entre MongoDB e CouchDB. Aqui está um bom link:http://blog.nahurst.com/visual-guide-to-nosql-systems. Tudo se resume ao que você quer dizer com "confiabilidade":MongoDB troca disponibilidade por consistência, enquanto CouchDB troca consistência por disponibilidade . (Cassandra permite que você aprimore essa compensação, por consulta, especificando quantos servidores devem ser escritos/lidos para que uma gravação/leitura seja bem-sucedida; ATUALIZAÇÃO:Agora, o CouchDB também pode, com o BigCouch! Muito empolgante...)
Boa sorte em seu projeto.
