Choisir MongoDb / CouchDb / RavenDb – conseils en performance et évolutivité

Nous examinons une solution de stockage de documents avec mise en cluster de basculement, pour certaines applications intensives en lecture / écriture.

Nous aurons une moyenne de 40 000 écritures simultanées par seconde écrites sur la firebase database (avec un pic pouvant atteindre 70 000 au cours de la période) et un nombre de lectures presque similaire.

Nous avons également besoin d’un mécanisme permettant à la firebase database de notifier les enregistrements nouvellement écrits (une sorte de déclencheur au niveau de la firebase database).

Quelle sera une bonne option en termes de choix approprié de la documentation et de la planification des capacités associées?

Actualisé

Plus de détails sur les attentes.

  • En moyenne, nous prévoyons 40 000 (40 000) encarts (nouveaux documents) par seconde sur 3 ou 4 bases de données / collections de documents.
  • Le pic peut atteindre 120 000 (120 K) inserts
  • Les inserts doivent être lisibles immédiatement – presque en temps réel
  • Parallèlement à cela, nous prévoyons environ 5000 mises à jour ou suppressions par seconde
  • Parallèlement à cela, nous prévoyons également 500 à 600 requêtes simultanées accédant aux données. Ces requêtes et ces plans d’exécution sont quelque peu connus, mais il faudra peut-être les mettre à jour, par exemple une fois par semaine.
  • Le système doit prendre en charge le clustering de basculement du côté stockage

    Si “20 000 écritures simultanées” signifie des insertions, je choisirais CouchDB et utiliserais “_changes” api pour les déclencheurs. Mais avec 20.000 écritures, vous auriez aussi besoin d’un sharding stable. Alors vous feriez mieux de regarder bigcouch

    Et si “20 000” écritures concurrentes sont constituées “principalement” de mises à jour, je choisirais certainement MongoDB, car sa “mise à jour en place” est plutôt géniale. Mais alors, vous devez gérer les déclencheurs manuellement, mais utiliser une autre collection pour mettre à jour 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 sélectionner une firebase database avec simplement la simultanéité, vous devez planifier l’API (comment récupérer les données), puis examiner les options en main.

    Je recommanderais MongoDB. Mes exigences n’étaient pas aussi élevées que les vôtres mais elles étaient raisonnablement proches. En supposant que vous utiliserez C #, je recommande le pilote officiel MongoDB C # et la méthode InsertBatch avec SafeMode activé. Il va littéralement écrire des données aussi rapidement que votre système de fichiers peut gérer. Quelques mises en garde:

    1. MongoDB ne supporte pas les déclencheurs (au moins la dernière fois que j’ai vérifié).
    2. MongoDB place initialement les données en mémoire vive avant de les synchroniser sur le disque. Si vous avez besoin de besoins en temps réel avec la durabilité, vous pouvez définir fsync plus bas. Cela aura un impact significatif sur la performance.
    3. Le pilote C # est un peu compliqué. Je ne sais pas si c’est juste moi mais j’obtiens des erreurs bizarres chaque fois que j’essaie d’exécuter des opérations de longue durée avec elle. Le pilote C ++ est bien meilleur et plus rapide que le pilote C # (ou tout autre pilote).

    Cela étant dit, je vous recommande également d’examiner RavenDB. Il supporte tout ce que vous recherchez mais pour la vie de moi, je ne pouvais pas le faire jouer près de Mongo.

    La seule autre firebase database proche de MongoDB était Riak . Son backend Bitcask par défaut est ridiculement rapide tant que vous avez suffisamment de mémoire pour stocker l’espace de clés mais, si je me souviens bien, il ne prend pas en charge les déclencheurs.

    Membase (et le prochain serveur Couchbase) sera facile à gérer et à fournir une évolutivité dynamic (ajout ou suppression de nœuds à la volée), réplication avec basculement. La couche de mise en cache memcached au-dessus gèrera facilement les opérations de 200 ko / s, et vous pouvez augmenter de façon linéaire avec plusieurs noeuds pour prendre en charge la conservation des données sur le disque.

    Nous avons des tests 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 d’avoir un produit de classe Entreprise pris en charge avec des ressources d’ingénierie et d’assurance qualité, mais cela est également possible.

    Edit: Vous avez oublié de mentionner qu’il existe déjà une interface de déclenchement intégrée, et nous l’étendons encore plus pour savoir à quel moment les données atteignent le disque (persistantes) ou sont répliquées.

    Poiré

    • Nous examinons une solution de stockage de documents avec mise en cluster avec basculement, pour certaines applications intensives en lecture / écriture

    Riak avec le backend de LevelDB de Google [voici une excellente référence de Google], avec suffisamment de cache et des disques solides très rapides. En fonction de la structure du document et de sa taille (vous avez mentionné 2 Ko), vous devrez bien sûr la comparer. [Gardez à l’esprit que si vous êtes en mesure de partager vos données (du sharepoint vue de votre activité), vous n’avez pas besoin de maintenir un débit de 40 Ko / 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 volerait littéralement.

    Riak avec des indices secondaires vous permet de créer des structures de données aussi documentées que vous le souhaitez => vous indexez uniquement les champs qui vous intéressent.

    Fail Over réussi et sans douleur est le deuxième nom de Riak. Il brille vraiment ici.

    • Nous avons également besoin d’un mécanisme permettant à la firebase database de notifier les enregistrements nouvellement écrits (une sorte de déclencheur au niveau de la firebase database)

    Vous pouvez compter sur pre-commit post-commit hooks pre-commit et de post-commit hooks dans Riak pour obtenir ce comportement, mais là encore, comme tout déclencheur, il est accompagné du prix => performance / maintenabilité.

    • Les inserts doivent être lisibles immédiatement – presque en temps réel

    Riak écrit sur disque (pas de surprise asynchrone 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 et l’ scalability sont importants pour vous, j’utiliserais les magasins de données écrits en Erlang, car Erlang résout ces problèmes avec succès depuis de nombreuses années.