Redis
 sql >> Base de données >  >> NoSQL >> Redis

Quelle base de données NoSQL pour des volumes de données extrêmement élevés

J'ai de l'expérience avec Redis et MongoDB, mais je ne le recommanderais pas non plus pour votre cas d'utilisation. Redis est génial à tous égards, mais comme il ne contient que de la RAM et n'a pas de fonctionnalités de clustering (pourtant, ils sont en cours de développement), il ne s'adapte pas très bien. Je n'utiliserais plus jamais MongoDB pour tout ce qui nécessite autre chose qu'un petit jeu de répliques.

Fondamentalement, MongoDB est immature et totalement inadapté à tout type d'exigences de haut volume et de haute performance. Il dispose d'un verrou d'écriture global qui est maintenu pendant les vidages de disque, ce qui signifie que les performances peuvent varier énormément en fonction de ce que vous faites. En pratique, cela rend impossibles les mises à jour qui augmentent les documents, et vous devez également être très prudent avec les suppressions. En parlant de suppressions, ils fragmentent gravement la base de données, donc si vous faites beaucoup de suppressions, vos performances vont en souffrir.

Le partage de 1.8.0 à 1.8.1 a été un désastre. Il y avait des bogues complets qui bloquaient le spectacle et qui n'auraient jamais dû en faire une version stable. La configuration n'a pas été correctement vidée et il a été très facile de mettre votre base de données dans un mauvais état afin que les morceaux ne sortent jamais du fragment principal. 1.8.2 résout la plupart d'entre eux et semble plus stable, mais je ne fais pas du tout confiance à l'implémentation du sharding. Ajoutez à cela que le sharding est difficile même lorsque tout fonctionne, il n'est pas toujours facile de sélectionner une clé de shard naturelle, et si vous ne le faites pas, le sharding vous causera beaucoup de chagrin.

MongoDB est vraiment facile à utiliser et l'ensemble de fonctionnalités est vraiment sympa. La documentation, les pilotes et la communauté sont tous géniaux. MongoDB fonctionne très bien en remplacement de MySQL, mais ne l'utilisez pas pour tout ce qui doit évoluer.

Nous envisageons actuellement de déménager à Cassandra. Je trouve le modèle dynamo (par exemple, pas de nœuds maîtres ; écrire et lire n'importe où ; ajouter simplement des nœuds pour développer le cluster) convaincant et les fonctionnalités nous conviennent plus ou moins. Le modèle de données est moins schématique, tout comme MongoDB, bien qu'un peu plus limité (vous pouvez choisir entre un ou deux hachages de niveau, en gros). Je suis sûr que la communauté est bonne une fois que vous y êtes entré, mais jusqu'à présent, j'ai du mal à trouver de bonnes informations sur la façon de résoudre les problèmes courants, et la documentation fait défaut. La plupart des informations que vous trouvez sur les blogs datent d'un an et beaucoup de choses se sont produites depuis (la 0.7 et la 0.8 semblent être des mises à jour vraiment importantes toutes les deux, mais la plupart des choses que vous trouvez concernent la 0.6). Les pilotes ne sont pas non plus très matures ou bien documentés, d'après ce que j'ai vu jusqu'à présent, et tout le monde semble se chamailler pour savoir si Thrift, Avro ou CQL est ce qu'il faut utiliser (et cela est passé de 0,6 à 0,7 à 0,8) .

Riak est intéressant, pour les mêmes raisons que Cassandra, mais pour nous un pur magasin clé-valeur ne suffit pas, il faut pouvoir mettre à jour sans faire de lecture préalable. Avec Riak, ce n'est pas possible puisque les valeurs ne sont que des blobs. Cela ne semble pas être un problème pour vous.

HBase est un autre concurrent. Cela semble pénible à configurer et à exécuter à cause des nombreuses pièces différentes, ZooKeeper, HDFS, etc. Mais le modèle de données est similaire à Cassandra (en colonnes, c'est-à-dire des hachages à un niveau), ce qui fonctionne bien pour nous, mais peut ne pas être important pour vous. Cela semble avoir fait ses preuves, mais comme avec MongoDB, vous devez faire attention aux problèmes de partitionnement, vous devez réfléchir à vos clés ou vous aurez des ennuis.

Il y a aussi CouchDB, Project Voldemort et d'innombrables autres choix possibles. Je pense que si vous êtes sérieux au sujet des "volumes de données extrêmement élevés", alors c'est entre Cassandra, Riak et HBase. Frappez Riak si le stockage de clé-valeur pur ne suffit pas. Selon ce que vous entendez par "réplication entièrement cohérente", Cassandra et Riak sont exclus, car il existe une possibilité (pas nécessairement importante et réglable) de lire une valeur obsolète.

En fin de compte, vous devez évidemment l'essayer sur votre cas d'utilisation particulier, donc tout ce que vous devriez vraiment retenir de cette réponse est :ne vous embêtez pas avec MongoDB.