Que dois-je choisir: MongoDB / Cassandra / Redis / CouchDB?

Question

Nous développons un très gros projet et je me demandais si quelqu'un pouvait me donner des conseils sur le backend DB à choisir.

Notre système est composé de 1100 appareils électroniques qui envoient un signal à un serveur central, puis le serveur stocke les informations de signal (le signal fait environ 35 octets). Cependant, ces appareils enverront environ 3 signaux par minute chacun, donc si nous faisons des chiffres, ce sera 4,752,000 nouveaux enregistrements/jour sur la base de données, et un total de 142,560,000 nouveaux enregistrements/mois.

Nous avons besoin d'un backend DB qui soit rapide et fiable. Bien sûr, nous devons effectuer une exploration de données complexe sur cette base de données. Nous faisons des recherches sur MongoDB/Cassandra/Redis/CouchDB, mais les sites Web de documentation n'en sont encore qu'à leurs débuts.

De l'aide? Des idées?

Merci beaucoup!

user359996 · Answer

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 sont une charge de travail triviale pour tout SGBD traditionnel, même fonctionnant sur du matériel bas de gamme. De même, 142 millions d'enregistrements par mois ne sont que de l'ordre de 1 à 10 gigaoctets de stockage par mois, sans aucune compression, y compris les index.

Dans votre commentaire, vous avez dit:

"Il s'agit de fiabilité, d'évolutivité et de vitesse. Il est très important que la solution évolue facilement (auto-partage MongoDB?) En ajoutant simplement plus de nœuds, et la vitesse est également très importante

Fiabilité? N'importe quel SGBD traditionnel peut garantir cela (en supposant que vous voulez dire que cela ne corrompra pas vos données et qu'il ne se bloquera pas - 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 poser de problème. Évolutivité? Au rythme actuel, les données d'une année entière, non compressées, voire entièrement indexées, pourraient facilement tenir dans les 100 gigaoctets 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 clair d'une solution exotique comme NoSQL, ou même d'une base de données distribuée - une base de données relationnelle ancienne et simple telle que MySQL serait très bien. Si vous êtes préoccupé par le basculement, installez simplement un serveur de sauvegarde dans une configuration maître-esclave. Si nous parlons de 100 ou 1 000 fois l'échelle actuelle, partitionnez simplement horizontalement quelques instances en fonction de l'ID du périphérique de collecte de données ( ie {index de la partition} = {id du périphérique} modulo {nombre de partitions}).

Gardez à l'esprit que quitter les confins sûrs et confortables du monde des bases de données relationnelles signifie abandonner à la fois son modèle représentationnel et son ensemble d'outils riche. Cela rendra votre "datamining 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 extraire.

Tout cela étant dit, MongoDB et CouchDB sont exceptionnellement simples à déployer et à travailler. Ils sont également très amusants et vous rendront plus attrayant pour n'importe quel nombre de personnes (pas seulement les programmeurs - les cadres aussi!).

La sagesse courante est que, parmi les 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é - il a été conçu pour être utilisé par Facebook); cela est contrecarré en étant plus difficile à travailler. Donc, sauf si vous avez des exigences étranges que vous n'avez pas mentionnées, je vous le déconseille, pour votre cas d'utilisation.

Si vous êtes défini positivement 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é pour la cohérence, tandis que CouchDB échange la cohérence pour la disponibilité . (Cassandra vous permet d'affiner ce compromis, par requête, en spécifiant combien de serveurs doivent être écrits/lus pour qu'une écriture/lecture réussisse; MISE À JOUR: Maintenant, CouchDB aussi, avec BigCouch ! Très excitant ...)

Bonne chance dans votre projet.

Theo · Answer

Une grande partie de la réponse dépend de ce que vous voulez en faire après sa collecte. Stocker beaucoup de données est facile: il suffit de les vider dans des fichiers journaux, pas besoin de base de données. D'un autre côté, si vous souhaitez effectuer une analyse et une exploration de données complexes, une base de données est utile.

La question suivante est de savoir quel type d'analyse vous allez faire. Sera-t-elle effectuée sur un sous-ensemble de données ayant une propriété particulière, la dernière heure/jour/semaine/mois uniquement, les données peuvent-elles être agrégées ou en quelque sorte précalculées? En d'autres termes: avez-vous besoin d'accéder à l'ensemble de données sous la forme qu'il est collecté? Pouvez-vous archiver des données lorsqu'elles sont trop anciennes pour être intéressantes? Pouvez-vous agréger les données et effectuer l'analyse sur l'agrégation?

D'après mon expérience de travail avec l'analyse publicitaire (collecte de milliards de points de données sur les expositions publicitaires), l'agrégation est la clé. Vous collectez des données brutes, les désinfectez puis les placez dans une base de données comme MongoDB, Cassandra ou même MySQL qui vous permet de faire des mises à jour et des requêtes. Ensuite, vous agrégez régulièrement les données et les supprimez de la base de données (mais archivez les données brutes, vous en aurez peut-être besoin plus tard).

L'agrégation pose essentiellement toutes les questions que vous souhaitez poser sur les données et les enregistre sous une forme qui facilite la récupération de la réponse à une question particulière. Disons que vous voulez savoir quel jour de la semaine a le plus de X. L'implémentation naïve de cela serait de garder tous les signaux enregistrés dans une grande table et de faire une requête qui additionne toutes les lignes qui ont X. Comme le nombre de collectées les signaux augmentent cette requête prendra de plus en plus de temps. Aucune quantité d'indexation, de partitionnement ou d'optimisation n'y contribuera. Au lieu de cela, chaque jour/heure/minute (en fonction du cas d'utilisation exact et de la mise à jour de vos rapports), vous regardez les nouveaux signaux que vous avez enregistrés et pour chaque X, vous augmentez le compteur qui garde la trace du nombre X il y en avait le lundi, si c'est un lundi, le mardi si c'est un mardi et ainsi de suite. De cette façon, vous pouvez récupérer le décompte pour chaque jour de la semaine et les comparer. Vous faites cela pour toutes les questions auxquelles vous voulez pouvoir répondre, puis vous supprimez les signaux de la base de données (mais encore une fois, conservez les données brutes).

Le type de base de données dans lequel vous enregistrez les agrégats peut être le même que celui dans lequel vous stockez les signaux entrants, mais il n'a pas besoin d'être très sophistiqué. Il stockera des clés qui représentent une réponse particulière et des valeurs qui ne sont généralement que des nombres.

Dans le stockage de données à l'ancienne, la base de données dans laquelle vous stockez les signaux entrants s'appelle OLTP (pour le traitement transactionnel en ligne) et la base de données dans laquelle vous stockez les agrégats s'appelle OLAP (pour le traitement analytique en ligne). OLTP est optimisé pour l'insertion et OLAP est optimisé pour l'interrogation. Les termes sont anciens et quand les gens les entendent, ils ont tendance à penser immédiatement au SQL, aux étoiles et à tout ça. Peut-être que je ne devrais pas les utiliser, mais ce sont des termes pratiques.

Quoi qu'il en soit, pour OLTP vous voulez quelque chose qui est rapide pour insérer des données, mais aussi quelque chose qui prend en charge l'indexation des données et la recherche de choses. L'agrégation est grandement facilitée par une base de données qui fait la moitié du travail de additionner et trouver des maximums et des minimums. J'aime vraiment MongoDB parce qu'il est si facile à configurer et à travailler. Les données avec lesquelles je travaille ont tendance à être compliquées et tous les éléments n'ont pas le même ensemble de propriétés, donc la tolérance indulgente de Mongo est un En revanche, vos données semblent beaucoup plus uniformes, donc Mongo ne vous offrirait peut-être pas autant d'avantages. Ne négligez pas encore les bonnes vieilles bases de données relationnelles. Si vous allez faire beaucoup de résumés et ainsi de suite, SQL est génial, c'est pour cela qu'il est conçu.

Pour OLAP quelque chose de beaucoup plus simple, un magasin de valeurs-clés est tout ce dont vous avez besoin. J'utilise Redis car il est également très facile à utiliser et à configurer. Il vous permet également de stocker plus de valeurs scalaires, ce qui est pratique. Parfois, votre valeur est en fait une liste, ou un hachage, dans la plupart des magasins de valeurs-clés, vous devez coder ces valeurs, mais Redis le gère de manière native. L'inconvénient de Redis est que vous ne pouvez pas faire de requêtes ("comme dans me donner toutes les lignes qui ont cette valeur pour Y"), vous devez conserver vous-même les index de vos données. En revanche, vous n'aurez pas besoin de beaucoup d'index car les réponses à toutes vos questions ont été précalculées, tout ce que vous avez à faire est de rechercher la réponse par une clé définie par la question. Pour la question ci-dessus, quel jour de la semaine a le plus X, vous recherchez le nombre de X travail lundi, mardi, etc. les ai stockés sous X: lundi, X: mardi, etc.

En conclusion: MongoDB et Redis fonctionnent très bien pour moi. Je ne pense pas que MongoDB soit très bon pour votre cas d'utilisation, mais je pense que vous pourriez en fait bénéficier davantage d'une base de données SQL traditionnelle (mais cela dépend, si vos données sont vraiment simples, vous pouvez peut-être utiliser Redis à fond). La chose la plus importante est de ne pas commettre l'erreur de penser que vous devez avoir les données dans une seule base de données et les conserver pour toujours. L'agrégation et l'élimination des anciennes données sont essentielles.

Ben Damman · Answer

CouchDB est très fiable, offre une excellente durabilité et vous subirez une charge CPU très faible. Il est également excellent pour la réplication entre plusieurs nœuds, à la demande ou en continu.

Grâce à ses capacités de réplication et à l'API RESTful (il utilise HTTP pour son API), vous pouvez évoluer horizontalement assez facilement à l'aide d'outils matures. (Nginx ou Apache pour le proxy inverse, les équilibreurs de charge HTTP, etc.)

Vous écrivez des fonctions de mappage/réduction en JavaScript pour précalculer les requêtes. Les résultats sont construits de manière incrémentielle sur le disque, ce qui signifie qu'ils ne doivent être calculés qu'une seule fois par signal. En d'autres termes, les requêtes peuvent être très rapides car elles n'ont qu'à effectuer des calculs sur les données de signal enregistrées depuis la dernière exécution de la requête.

CouchDB échange l'espace disque pour les performances, vous pouvez donc vous attendre à utiliser beaucoup d'espace disque. Vos requêtes peuvent être rapides comme l'éclair et économiser de l'espace disque si vous les implémentez correctement.

Essayez CouchDB.

Découvrez Pourquoi les grands scientifiques de collisionneurs de hadrons utilisent CouchDB et CouchDB à la BBC en tant que magasin de valeurs clés tolérant aux pannes, évolutif et multi-centre de données

jbellis · Answer

~ 3000 signaux/minute = 50 écritures/s que n'importe lequel de ces systèmes pourra gérer facilement.

Cassandra fonctionnera probablement mieux à mesure que votre ensemble de données grandit plus que la mémoire, et l'intégration Hadoop vous aidera avec votre exploration de données.

Kiran Subbaraman · Answer

Vous recherchez une banque de données qui peut autoriser des écritures "ultra-rapides" (les données ont persisté sur le disque), et l'exploration de données aura lieu à un stade ultérieur (c'est le cycle de LECTURE). En outre, compte tenu des chiffres que vous indiquez, il s'avère que vous collecterez 159 Mo d'informations par jour, soit environ 5 Go par mois.

Dans ce cas, pourquoi ne pas regarder Redis.

Vous pouvez toujours archiver le fichier de données Redis quotidien et y faire référence plus tard (si vous avez des problèmes de chargement de 5 Go ou plus de RAM espace, alors cet archivage pourrait être une solution)