Plusieurs schémas par rapport aux énormes tables

Question

Considérons un système de gestion de l'appareil mobile qui contient des informations pour chaque utilisateur, comme une table qui stocke les applications qu'il a installé sur le téléphone, les détails de la vérification, des informations de notification, etc., est-il sage de créer un séparé schéma pour chaque utilisateur les tables correspondantes? Le nombre de tables est grande pour un seul utilisateur un montant d'environ 30 tables chacun. Serait-il préférable d'avoir un schéma séparé où toutes ces informations sont placées dans ces tables (à son tour créer des tables énormes?) Ou un schéma pour chaque utilisateur?

Merci à l'avance

Answer 1

Je veux voir quelle méthode est la plus efficace en termes de requêtes dans la base de données.

Dans une base de données multi-locataire, l'interrogation est seulement une partie du problème. D'autres parties du problème sont le coût, l'isolement des données et la protection, l'entretien et la reprise après incident. Ceux-ci sont importants; vous ne pouvez pas considérer uniquement Efficacité de la requête dans une base de données multi-locataire.

solutions multi-locataires varient d'une base de données par locataire (rien partagé) à une ligne par locataire (partage intégral).

"rien partagé", "base de données séparée", ou une base de données par locataire

• La plupart des clients coûteux par. (Un grand nombre de clients impliquent un grand nombre de serveurs.)
• plus haut degré d'isolation des données.
• reprise après incident pour un seul locataire est simple et direct.
• L'entretien est théoriquement plus difficile, parce que les changements doivent être effectués dans chaque base de données. Mais votre DBMS peut facilement prendre en charge l'exécution des procédures stockées dans chaque base de données. (SQL Server dispose d'un système sans papier procédure stockée, sp_msforeachdb, par exemple. Vous pouvez probablement écrire votre propre.) « Rien partagé » est le plus facilement personnalisable, aussi, mais cela soulève également d'autres problèmes de maintenance.
• le plus bas nombre de lignes par table. la vitesse Interrogation est presque optimale.

"tout partagé", ou "schéma partagé" ou "une base de données par planète"

• moins cher locataire de par.
• le plus bas degré d'isolement de données. Chaque table a une colonne qui identifie le locataire d'une ligne appartient. Étant donné que les lignes de locataires sont mélangés dans toutes les tables, il est relativement simple d'exposer accidentellement les données des autres locataires.
• reprise après incident pour un seul locataire est relativement compliqué; vous devez restaurer des lignes individuelles dans de nombreuses tables. D'autre part, une catastrophe unique locataire est relativement rare. La plupart des catastrophes affecteront probablement tous les locataires.
• l'entretien structurel est plus simple, étant donné que tous les locataires partagent les tables. Il augmente la charge de la communication, bien que, parce que vous devez communiquer et coordonner chaque changement avec chaque locataire. Ce n'est pas facilement personnalisable.
• numéro le plus élevé de lignes par table. rapide est plus difficile interrogation, mais il dépend du nombre de locataires et le nombre de lignes. Vous pouvez facilement basculer en territoire VLDB.

Entre « rien partagé » et « tout partagé » est « schéma partagé ».

"schéma partagé"

• Les locataires partagent une base de données, mais chaque locataire a son propre schéma nommé. Le coût se situe entre « rien partagé » et « tout partagé »; grands systèmes ont besoin généralement moins de serveurs que « rien partagé », plus de serveurs que « tout partagé ».
• Beaucoup mieux que l'isolement « tout partagé ». Pas tout à fait autant l'isolement que « rien partagé ». (Vous pouvez accorder des autorisations et REVOKE sur les schémas).
• reprise après incident pour un seul locataire nécessitent la restauration de l'un des nombreux schémas. Ceci est relativement facile soit ou assez dur, en fonction de vos DBMS.
• L'entretien est plus facile que « rien partagé »; pas aussi facile que « tout partagé ». Il est relativement simple d'écrire une procédure stockée qui exécutera dans chaque schéma dans une base de données. Il est plus facile de partager des tables communes entre les locataires que par « rien partagé ».
• En général, plus les locataires actifs par serveur que « rien partagé », ce qui signifie qu'ils partagent (degrade) plus de ressources. Mais pas aussi mauvais que « tout partagé ».

Microsoft a un bon article sur architecture multi-locataires avec plus de détails. (Le lien est juste une page d'un document de plusieurs pages.)