Mise à l'échelle Couch DB et de la performance

Question

Je cherche à mettre en œuvre un serveur CouchDB pour faciliter la recherche ad hoc de certaines métadonnées que nous enregistrons pour une opération commerciale interne.

Nous conservons un certain nombre de « attributs », comme la taille, la source, soumettre la date et l'URL pour les « emplois » dans notre processus interne.

Ceci est très bien dans notre base de données relationnelle, mais nos utilisateurs souhaite créer des listes d'emplois similaires en fournissant des « critères de recherche » similaire à faire une recherche sur Google. Ainsi, l'utilisateur pourrait dire « montrez-moi tous les emplois qui sont supérieurs à XXX et soumis après YYY » et récupérer une liste des descriptions et des URL.

Cela semble parfait pour Couch, et de ce que j'ai fait des recherches, il semble que cela va bien fonctionner.

Ma question est comment il va évoluer avec le matériel approprié? Nous avons entre 150-200000000 ces documents, et entre 11-30 attributs par document. Les métadonnées sont quelques kilo-octets en taille au maximum.

Je cherche d'abord d'avoir un serveur quadcore (VM) servant pour ce test mais je besoin à l'échelle pour soutenir entre 100-250 utilisateurs simultanément.

Je sais que je peux le faire avec la plupart des serveurs db, mais je suis à la recherche de quelque chose qui offre l'aspect interrogation ad hoc (sur REST ou HTTP est très bien, nous avons nos propres outils de recherche).

Quelqu'un at-il eu l'expérience et la mise en place Couch utiliser pour des charges de production à ce niveau?

Answer 1

Connexions simultanées ne sont pas un problème, Erlang et CouchDB sont construits pour des performances simultanées.

Pensez-vous que vous aurez à générer de nouvelles fonctions de carte dynamique, parce que ce genre de sons comme ça?

Chaque fois que vous ajoutez une nouvelle fonction voir la carte que vous allez frapper un goulot d'étranglement dans la génération de vue initiale.

Si vous utilisez des vues Erlang ils génèrent beaucoup plus vite que javascript vues parce qu'ils ne frappent pas l'étape de sérialisation JSON, cela peut accélérer considérablement la performance de génération de vue.

Une fois que la vue est généré, il sera assez rapide, même avec la taille que vous parlez.