Mise à l'échelle et performances de DB de diviseurs

Question

Je cherche à mettre en place un serveur CouchDB pour effectuer une recherche ad-hoc de certaines métadonnées que nous stockons pour une opération métier interne.

Nous stockons un certain nombre d '«attributs» comme la taille, la source, la date de soumission et l'URL pour les «travaux» dans notre processus interne.

Tout cela est très bien dans notre base de données relationnelle, mais nos utilisateurs voudraient construire des listes d'emplois similaires en fournissant des "critères de recherche" similaires à faire une recherche google. Ainsi, l'utilisateur pourrait dire «montrez-moi tous les emplois qui sont plus grands que XXX et soumis après YYY» et récupérez une liste de descriptions et d'URL.

Cela semble parfait pour Couch, et d'après ce que j'ai recherché il semble que ça va bien fonctionner.

Ma question est de savoir dans quelle mesure sera-t-elle mise à l'échelle avec le matériel approprié? Nous avons entre 150 et 200 millions de documents, et entre 11 et 30 attributs par document. Les métadonnées ont au plus quelques kilo-octets. Je cherche d'abord à avoir un serveur quadcore (VM) qui sert à tester, mais j'ai besoin de l'étendre pour prendre en charge entre 100 et 250 utilisateurs simultanément.

Je sais que je peux le faire avec la plupart des serveurs de base de données, mais je cherche quelque chose qui fournit l'aspect ad hoc de recherche (sur REST ou HTTP est bien nous avons nos propres outils de recherche).

Est-ce que quelqu'un a déjà eu l'expérience de la mise en place de Couch et de l'utiliser pour des charges de production à ce niveau?

Answer 1

Les connexions simultanées ne sont pas un problème, erlang et CouchDB sont construits pour des performances concurrentes.

Pensez-vous que vous allez générer dynamiquement de nouvelles fonctions de carte, parce que ça sonne comme ça? Chaque fois que vous ajoutez une nouvelle fonction de carte de visualisation, vous allez rencontrer un gros goulot d'étranglement dans la génération de la vue initiale. Si vous utilisez des vues erlang, elles génèrent des vues beaucoup plus rapides que les javascript, car elles n'atteignent pas l'étape de sérialisation JSON, ce qui peut considérablement accélérer les performances de génération de vue.

Une fois la vue générée, elle sera assez rapide même avec la taille dont vous parlez.