Quelle est la durée de requête raisonnable pour les tables associées comportant de très grands ensembles de données?

Question

Dans No podcast StackOverflow. 19 , Joe décrit la décision de Fogcreek d’avoir une base de données par client au lieu de une base de données pour TOUS les clients . Cela me fait penser un peu à ce qui suit.

1. En supposant que j'ai 1 000 utilisateurs .
2. Chaque utilisateur a 100 clients .
3. Chaque client dispose de 1 000 produits .

Cela signifie donc que je vais avoir des produits 1000 x 100 x 1000 = 100 000 000 associés aux utilisateurs. Maintenant, si je fais une requête de tables de jointure pour un utilisateur et tous les produits de son client, quel devrait être le temps de requête raisonnable si je n’utilise qu’une seule base de données à cette fin?

MISE À JOUR

Peut-être que je n'ai pas été assez clair dans ma question. Supposons que je doive faire toutes sortes de requêtes géniales (min, max, groupe, etc.) avec les jeux de données décrits ci-dessus, serait-il lent (ou pas) au point qu'il est plus logique d'avoir plusieurs stratégies de base de données, par exemple . 1 DB / client, partage de base de données, etc.

Answer 1

J'imagine que la réponse dépend de votre choix de SGBD. Avec Oracle, par exemple, 1 grosse base de données serait définitivement préférable, en fait, 1 000 bases de données identiques seraient considérées comme absurdes et ingérables.

De plus, n’auriez-vous jamais besoin d’exécuter des requêtes sur plusieurs utilisateurs? par exemple. trouver l'utilisateur avec le plus de produits. Ou sont-ils vraiment 1000 discrets "privé"? bases de données et personne n'a un accès global aux données? Même dans ce cas, Oracle propose par exemple "Base de données privée virtuelle". pour répondre à cela dans une seule base de données.

Answer 2

Une stratégie basée sur une base de données par client repose principalement sur la sécurité et la facilité de gestion. Bien que le concept de sauvegarde / restauration sur une base de données unique plutôt que 100 bases de données spécifiques à un client vous permette de gagner, il présente certains inconvénients. Certains des problèmes avec une base de données partagée sont les suivants:

• Les utilisateurs ne peuvent pas directement communiquer avec la base de données sans mesures de sécurité supplémentaires (telles que les vues) pour les empêcher de voir les données des autres. Dans le cas de données sensibles, cela devient également un problème de conformité.

• Toute l'application doit être consciente du modèle de sécurité, ce qui ajoute un certain degré de complexité. Là encore, avec des données sensibles, cela a des implications en termes de conformité.

• Les tâches de maintenance du système ou de ticket d'assistance impliquant les données d'un client risquent de provoquer des erreurs qui pourraient affecter les données des autres.

La compartimentation inhérente à plusieurs bases de données simplifie l'application et élimine des classes entières d'erreurs, de problèmes de configuration et de sécurité. Si vous créez l’application de manière à ce qu’elle puisse être gérée de manière automatisée et déployée dans plusieurs environnements, vous pouvez obtenir quelque chose de relativement facile à gérer, même sur plusieurs instances.

De plus, avec les volumes de données et les types de rapports que vous décrivez, il serait peut-être préférable de créer un sous-système de rapports ou un magasin de données qui déplace les rapports hors du serveur de production. Les rapports analytiques de ce type sont beaucoup plus efficaces sur les schémas en étoile que sur le type de schéma normalisé que vous utiliseriez dans une base de données transactionnelle.

Answer 3

Dans la plupart des cas, vous devez inclure un utilisateur et / ou un client dans le PK. Par conséquent, vos performances dans le scénario multi-locataire ne devraient pas être affectées de manière très différente de celles du cas avec un locataire unique.

Answer 4

Si vous voulez obtenir tout cela, toutes les colonnes et toutes les lignes, sans filtrage ni agrégation, vous devrez attendre très longtemps. Je ne pense pas que vous puissiez utiliser ici un laps de temps raisonnable. Vous devez juste attendre :))

Mais ces types de requêtes se produisent rarement (sauf si vous migrez vos données - il existe encore des alternatives). En général, vous renvoyez un sous-ensemble de lignes, une page de lignes, une sélection de colonnes ou des agrégats. Dans ce cas, le "montant raisonnable" dépend du type de requête et des calculs impliqués.