Ne laissez pas l'échelle spatiale (plus de 1000 appareils) vous induire en erreur quant à l'échelle de calcul et/ou de stockage. Quelques dizaines d'insertions de 35 octets par seconde représentent une charge de travail triviale pour tout SGBD grand public, même s'exécutant sur du matériel bas de gamme. De même, 142 millions d'enregistrements par mois ne représentent que de l'ordre de 1 à 10 Go de stockage par mois, sans aucune compression, y compris les index.
Dans le commentaire de votre question, vous avez dit :
"Tout est une question de fiabilité, d'évolutivité et de vitesse. Il est très important que la solution évolue facilement (partage automatique MongoDB ?) En ajoutant simplement plus de nœuds, et la vitesse est également très importante
Fiabilité? Tout SGBD grand public peut le garantir (en supposant que vous vouliez dire qu'il ne va pas corrompre vos données et qu'il ne va pas planter - voir ma discussion sur le théorème CAP au bas de cette réponse). La vitesse? Même avec une seule machine, 10 à 100 fois cette charge de travail ne devrait pas être un problème. Évolutivité ? Au rythme actuel, les données d'une année complète, non compressées, voire entièrement indexées, tiendraient facilement dans 100 Go d'espace disque (de même, nous avons déjà établi que le taux d'insertion n'est pas un problème).
En tant que tel, je ne vois aucun besoin évident d'une solution exotique comme NoSQL, ou même d'une base de données distribuée - une base de données relationnelle simple et ancienne telle que MySQL conviendrait parfaitement. Si vous vous inquiétez du basculement, configurez simplement un serveur de sauvegarde dans une configuration maître-esclave. Si nous parlons de centaines ou de milliers de fois l'échelle actuelle, partitionnez simplement horizontalement quelques instances en fonction de l'ID de l'appareil de collecte de données (c'est-à-dire {partition index} ={device id} modulo {number of partitions}).
Gardez à l'esprit que quitter les limites sûres et confortables du monde des bases de données relationnelles signifie abandonner à la fois son modèle de représentation et son ensemble d'outils riche . Cela rendra votre "exploration de données complexe" beaucoup plus difficile - vous n'avez pas seulement besoin de mettre des données dans la base de données, vous devez également les sortir.
Cela dit, MongoDB et CouchDB sont exceptionnellement simples à déployer et à utiliser. Ils sont également très amusants et vous rendront plus attrayant pour un certain nombre de personnes (pas seulement les programmeurs, mais aussi les cadres !).
La sagesse commune est que, des trois solutions NoSQL que vous avez suggérées, Cassandra est la meilleure pour un volume d'insertion élevé (bien sûr, relativement parlant, je ne pense pas que vous ayez volume d'insertion élevé - ceci a été conçu pour être utilisé par Facebook ); ceci est contré en étant plus difficile à travailler. Donc, à moins que vous n'ayez des exigences étranges que vous n'avez pas mentionnées, je vous le déconseille, pour votre cas d'utilisation.
Si vous êtes positivement fixé sur un déploiement NoSQL, vous voudrez peut-être considérer le théorème CAP. Cela vous aidera à choisir entre MongoDB et CouchDB. Voici un bon lien :http://blog.nahurst.com/visual-guide-to-nosql-systems. Tout se résume à ce que vous entendez par "fiabilité" :MongoDB échange la disponibilité contre la cohérence, tandis que CouchDB échange la cohérence contre la disponibilité . (Cassandra vous permet de peaufiner ce compromis, par requête, en spécifiant combien de serveurs doivent être écrits/lus pour qu'une écriture/lecture réussisse ; MISE À JOUR :CouchDB aussi, avec BigCouch ! Très excitant...)
Bonne chance dans votre projet.
