Choisir MongoDb/CouchDb/RavenDb - conseils en matière de performances et d'évolutivité

Question

Nous envisageons une solution de stockage de données de documents avec une mise en grappe en cas de défaillance, pour une application à lecture/écriture intensive.

Nous aurons une moyenne de 40 000 écritures simultanées par seconde dans la base de données (avec des pointes pouvant atteindre 70 000) - et un nombre presque similaire de lectures.

Nous avons également besoin d'un mécanisme pour que la base de données soit informée des nouveaux enregistrements écrits (une sorte de déclencheur au niveau de la base de données).

Quelle serait une bonne option en termes de choix approprié de la base de données documentaire et de planification de la capacité correspondante ?

Mise à jour de

Plus de détails sur l'attente.

• En moyenne, nous attendons 40 000 (40K) insertions (nouveaux documents) par seconde dans 3-4 bases de données/collections de documents.
• Le pic peut aller jusqu'à 120 000 (120K) encarts.
• Les insertions doivent être lisibles immédiatement, presque en temps réel.
• En plus de cela, nous attendons environ 5000 mises à jour ou suppressions par seconde.
• En outre, nous prévoyons que 500 à 600 requêtes simultanées accèdent aux données. Ces requêtes et les plans d'exécution sont quelque peu connus, bien que cela puisse devoir être mis à jour, disons une fois par semaine environ.
• Le système doit prendre en charge le failover clustering du côté du stockage.

Answer 1

Si "20 000 écritures simultanées" signifie des insertions, je choisirais CouchDB et utiliserais l'api "_changes" pour les triggers. Mais avec 20.000 écritures simultanées, vous aurez également besoin d'un sharding stable. Dans ce cas, vous devriez jeter un coup d'œil à bigcouch

Et si les "20.000" écritures simultanées consistent "principalement" en des mises à jour, je choisirais MongoDB à coup sûr, car sa "mise à jour en place" est assez impressionnante. Mais alors vous devriez gérer les triggers manuellement, mais l'utilisation d'une autre collection pour mettre à jour en place un document général peut être une solution pratique. Encore une fois, faites attention au sharding.

Enfin, je pense que vous ne pouvez pas choisir une base de données en vous basant uniquement sur la concurrence, vous devez planifier l'api (comment vous allez récupérer les données) puis examiner les options disponibles.

Answer 2

Je recommande MongoDB. Mes exigences n'étaient pas aussi élevées que les vôtres, mais elles étaient assez proches. En supposant que vous utilisiez C#, je vous recommande le pilote C# officiel de MongoDB et l'application InsertBatch méthode avec SafeMode allumé. Il écrira littéralement des données aussi vite que votre système de fichiers peut le supporter. Quelques mises en garde :

1. MongoDB fait no supportent les déclencheurs (du moins la dernière fois que j'ai vérifié).
2. MongoDB met d'abord les données en cache dans la RAM avant de les synchroniser sur le disque. Si vous avez des besoins en temps réel avec une durabilité, vous pouvez définir fsync plus bas. Cela aura un impact significatif sur les performances.
3. Le pilote C# est un peu bancal. Je ne sais pas si c'est moi, mais j'obtiens des erreurs bizarres dès que j'essaie d'exécuter des opérations longues avec lui. Le pilote C++ est bien meilleur et plus rapide que le pilote C# (ou tout autre pilote d'ailleurs).

Cela dit, je vous recommande également de vous intéresser à RavenDB. Il prend en charge tout ce que vous recherchez, mais je n'ai pas réussi à le rendre aussi performant que Mongo.

La seule autre base de données qui se rapprochait de MongoDB était Riak . Son backend Bitcask par défaut est ridiculement rapide tant que vous avez assez de mémoire pour stocker l'espace clé, mais si je me souviens bien, il ne supporte pas les triggers.

Answer 3

Membase (et le serveur Couchbase qui sera bientôt disponible) répondra facilement à vos besoins et offrira une évolutivité dynamique (ajout ou suppression de nœuds à la volée), une réplication avec basculement. La couche de mise en cache memcached qui se trouve au dessus gèrera facilement 200k ops/sec, et vous pouvez augmenter de façon linéaire avec plusieurs nœuds pour supporter la persistance des données sur le disque.

Nous avons obtenu des bancs d'essai récents montrant une latence extrêmement faible (ce qui équivaut approximativement à un débit élevé) : http://10gigabitethernet.typepad.com/network_stack/2011/09/couchbase-goes-faster-with-openonload.html

Je ne sais pas à quel point il est important pour vous de disposer d'un produit de classe entreprise soutenu par des ressources d'ingénierie et d'assurance qualité, mais cela est également disponible.

Edit : J'ai oublié de mentionner qu'il existe déjà une interface de déclenchement intégrée, et que nous l'étendons encore plus pour suivre le moment où les données atteignent le disque (persistant) ou sont répliquées.

Perry

Answer 4

• Nous recherchons une solution de stockage de données de documents avec mise en grappe en cas de défaillance, pour une application à lecture/écriture intensive.

Riak avec le backend LevelDB de Google [voici une Une référence impressionnante de Google], avec un cache suffisant et des disques solides, est très rapide. En fonction de la structure du document et de sa taille (vous avez mentionné 2 Ko), vous devrez bien sûr effectuer une analyse comparative. [Gardez à l'esprit que si vous êtes en mesure de partager vos données (pour des raisons commerciales), vous n'êtes pas obligé de maintenir un débit de 40K/s sur un seul nœud.]

Un autre avantage de LevelDB est la compression des données => stockage. Si le stockage n'est pas un problème, vous pouvez désactiver la compression, auquel cas LevelDB s'envolera littéralement.

Riak avec les index secondaires vous permet de rendre vos structures de données aussi documentées que vous le souhaitez => vous n'indexez que les champs sur lesquels vous souhaitez effectuer une recherche.

Succès et absence de douleur Fail Over est le second nom de Riak. Il brille vraiment ici.

• Nous avons également besoin d'un mécanisme pour que la base de données soit informée des nouveaux enregistrements écrits (une sorte de déclencheur au niveau de la base de données).

Vous pouvez compter sur pre-commit y post-commit hooks dans Riak pour obtenir ce comportement, mais une fois encore, comme tout déclencheur, cela a un prix => performances / maintenabilité.

• Les insertions doivent être lisibles immédiatement, presque en temps réel.

Riak écrit sur le disque (pas de surprises asynchrones MongoDB) => reliably readable tout de suite. Si vous avez besoin d'une meilleure cohérence, vous pouvez configurer le quorum de Riak pour les insertions : par exemple, combien de nœuds doivent revenir avant que l'insertion ne soit considérée comme réussie ?

En général, si fault tolerance / concurrency / fail over / scalability sont importants pour vous, j'opterais pour des magasins de données écrits en Erlang, car Erlang résout ces problèmes avec succès depuis de nombreuses années.