Dois-je séparer la base de données NoSQL sur des serveurs distincts?

Question

Nous sommes encore dans les premières étapes de déterminer si nous allons avec RDBMS ou NoSQL. L'un des domaines d'intérêt est si nous allons avec NoSQL (probablement CouchDB bien que pourrait être MongoDB), séparer la base de données NoSQL sur différents serveurs serait mieux qu'une instance d'un serveur NoSQL?

Nous allons construire un système de gestion de fichiers où certains fichiers/vidéos seront regroupés sur différents serveurs. Les fichiers/vidéos liés aux comptes seront stockés sur le serveur de comptes, etc. Pour rechercher un fichier lié à un compte, nous rechercherons probablement la base de données sur le serveur de comptes.

Je peux voir à l'avenir que quelqu'un dira "pourquoi je ne peux pas rechercher sur tous les serveurs pour un type de fichier ou de vidéo"? Clairement ayant une base de données serait mieux ici.

Cependant, mis à part la latence dans les requêtes http pour interroger les serveurs, y a-t-il de meilleures façons de le faire ou les avantages et les inconvénients d'avoir une grande base de données?

JD

Answer 1

L'idée de (la plupart) des produits NoSQL est qu'ils offrent une évolutivité horizontale. Cela signifie que votre seule instance logique peut se trouver sur des dizaines de serveurs. Dans MongoDB, par exemple, vous pouvez utiliser auto-sharding. Pour votre programme, ceci est complètement transparent: votre code est (presque) le même que celui que vous utiliseriez pour un seul serveur de base de données, mais les données résident, par exemple, sur 5 serveurs. Il existe de nombreux avantages: vous avez un emplacement central pour administrer votre base de données, vous pouvez interroger toutes les bases de données si nécessaire, vous n'avez pas besoin de manipuler w/plusieurs connexions db dans votre code, la db équilibre automatiquement ces les collections qui doivent être équilibrées, les opérations de mappage/réduction peuvent être exécutées en parallèle si la requête le permet, etc.

Les plus importants pour moi: les frais généraux d'administration sont minimes et vous n'avez pas à en mettre trop pensé dans ce maintenant, parce que vous pouvez ajouter l'auto-sharding plus tard.

Je n'essaierais pas de faire du sharding moi-même, parce qu'il réinvente la roue, et ce n'est pas facile non plus. C'était l'un des principaux moteurs de NoSQL en premier lieu.