Devrais-je utiliser une ou plusieurs bases de données pour une application multi-client?

Question

Je travaille sur une application PHP visant à faciliter le flux de travail et la gestion de projet au sein de l'entreprise. Disons quelque chose comme Basecamp et GoPlan .

Je ne suis pas sûr de la meilleure approche en termes de base de données. Devrais-je utiliser une base de données unique et ajouter des colonnes spécifiques au client à chacune des tables ou devrais-je créer une base de données pour chaque nouveau client? L’automatisation est un facteur important: je veux qu’il soit très simple de créer un nouveau client (et peut-être d’ouvrir la possibilité de s’inscrire pour vous-même).

Contre possible, je peux penser à utiliser une base de données:

• Manque d'extensibilité
• Problèmes de sécurité (même si les bogues ne devraient pas exister )

Quelles sont vos pensées à ce sujet? Avez-vous une idée de la solution que les entreprises susmentionnées sont les plus susceptibles d’avoir choisie?

Answer 1

J'ajoute généralement ClientID à toutes les tables et n'utilise qu'une base de données. Mais étant donné que la base de données est généralement difficile à mettre à l’échelle, il sera également possible de s’exécuter sur différentes instances de la base de données pour certains ou tous les clients.

De cette façon, vous pouvez avoir plusieurs petits clients dans une base de données et les gros sur des serveurs distincts.

Un facteur clé de la facilité de maintenance, cependant, est que le schéma reste identique dans toutes les bases de données. Il y aura assez de maux de tête pour gérer le contrôle de version sans introduire de schémas spécifiques au client.

Answer 2

Écoutez le podcast Stackoverflow où Joel et Jeff parlent de la même question. Joel parle de leur expérience en proposant une version hébergée de leur logiciel. Il souligne que l'ajout d'identifiants client sur l'ensemble de votre base de données complique la conception et le code (êtes-vous sûr de ne pas l'avoir oublié par inadvertance en l'ajoutant à une clause WHERE?) Et complique la fonctionnalité d'hébergement, telle que les sauvegardes spécifiques au client.

C'était dans l'épisode 20 ou 21 (vérifiez les transcriptions pour plus de détails).

Answer 3

À mon avis, cela dépendra de votre clientèle probable. Si vous pouviez vous trouver dans une situation où vos rivaux utilisent votre système, il serait préférable de disposer de bases de données séparées. Cela dépend également de la manière dont plusieurs bases de données sont implémentées par votre SGBD. Si chaque base de données possède une copie distincte de l'infrastructure, cela suggère une base de données unique (ou un changement de SGBD). Si plusieurs bases de données peuvent être desservies par une seule copie de l’infrastructure, je choisirais des bases de données distinctes.

Pensez à la sauvegarde de la base de données. Le client A dit "Veuillez m'envoyer une copie de mes données". Beaucoup, beaucoup plus facile dans une configuration de base de données séparée que si une base de données unique est partagée. Pensez à retirer un client. encore une fois, beaucoup plus facile avec des bases de données séparées.

(La partie "infrastructure" est mal inspirée, par exemple, car il existe des différences majeures entre les différents SGBD en ce qui concerne ce qui constitue une "base de données" par rapport à une "instance de serveur". Add : la question est: étiqueté 'mysql', alors peut-être que ces pensées ne sont pas complètement pertinentes.)

Ajouter : Un autre problème - avec plusieurs clients dans une même base de données, chaque requête SQL doit s’assurer que les données du bon client sont choisies. Cela signifie que le code SQL sera plus difficile à écrire et à lire et que le SGBD devra s’efforcer davantage de traiter les données, et les index seront plus gros, et ... j’aimerais vraiment utiliser une base de données séparée. client à de nombreuses fins.

Clairement, StackOverflow (à titre d’exemple) n’a pas de base de données séparée par utilisateur; nous utilisons tous la même base de données. Mais si vous utilisiez des systèmes de comptabilité pour différentes sociétés, je ne pense pas qu'il serait acceptable (pour les sociétés et peut-être pas pour les personnes juridiques) de partager des bases de données.

Answer 4

• DÉVELOPPEMENT Pour un développement rapide, utilisez une base de données par client. Pensez à quel point il sera facile de sauvegarder, restaurer ou supprimer les données d'un client. Ou pour mesurer / surveiller / facture l'utilisation. Vous n'avez pas besoin d'écrire du code pour le faire vous-même, utilisez simplement les primitives de votre base de données.

• PERFORMANCES Pour la performance, utilisez une base de données pour tous. Pensez au regroupement de connexions, à la mémoire partagée, à la mise en cache, etc.

• ENTREPRISE Si votre plan d’entreprise est d’avoir beaucoup de petits clients (pensez hotmail), vous devriez probablement travailler sur une seule base de données. Et assurez-vous que toutes les tâches administratives telles que l'enregistrement, la suppression, la migration de données, etc. sont entièrement automatisées et exposées dans une interface conviviale. Si vous envisagez de disposer de dizaines voire de centaines de gros clients, vous pouvez travailler dans une seule base de données par client et disposer de scripts d’administration système pouvant être gérés par votre service client.

Answer 5

Le screencast ci-dessous explique comment cela se fait sur salesforce.com. Ils utilisent une base de données avec une colonne spéciale OrgId qui identifie les données de chaque locataire. Il y a beaucoup plus à cela, donc vous devriez examiner cela. J'irais avec leur approche.

Il existe un autre article à ce sujet sur MSDN. Il explique en détail quand vous devez utiliser une approche partagée ou isolée. N'oubliez pas que le fait d'avoir une base de données partagée pour tous vos clients hébergés a des conséquences importantes sur la sécurité. Si tous partagent les mêmes objets de base de données, vous pouvez utiliser [sécurité au niveau de la ligne], en fonction du SGBD utilisé (je suis sûr que c'est possible dans MS SQL Server et Oracle, probablement aussi dans IBM DB2). Vous pouvez utiliser des astuces telles que la sécurité au niveau de la ligne dans mySQL pour obtenir des résultats similaires (vues + déclencheurs ).

Answer 6

En ce qui concerne la multi-location, les performances augmenteront en fonction du nombre de ressources que vous parvenez à partager entre locataires, voir

http://en.wikipedia.org/wiki/Multitenancy

Donc, si vous le pouvez, utilisez la base de données unique. Je conviens que les problèmes de sécurité ne surviendraient qu'en raison de bugs, car vous pouvez implémenter tout le contrôle d'accès dans l'application. Dans certaines bases de données, vous pouvez toujours utiliser le contrôle d'accès à la base de données en utilisant soigneusement les vues (pour que chaque utilisateur authentifié obtienne une vue différente).

Il existe également des moyens de fournir une extensibilité. Par exemple, vous pouvez créer une table unique avec des attributs d'extension (indexés par client, enregistrement de base et identifiant d'attribut d'extension). Vous pouvez également créer des tables d’extension par client, de sorte que chaque client possède son propre schéma d’extension.

Answer 7

Lorsque vous concevez une base de données multi-locataires, vous avez généralement trois options:

1. disposer d'une base de données par locataire
2. Avoir un schéma par locataire
3. Tous les locataires partagent-ils la même table

L'option que vous choisissez a des implications sur l'évolutivité, l'extensibilité et l'isolation. Ces implications ont été largement discutées dans différentes questions StackOverflow et des articles de base de données.

En pratique, chacune des trois options de conception, avec suffisamment d’effort, peut répondre à des questions d’échelle, de données variables selon les locataires et d’isolement. La décision dépend de la dimension principale pour laquelle vous construisez. Le résumé:

• Si vous construisez à l'échelle: demandez à tous les locataires de partager la même table
• Si vous construisez pour l'isolation: créez une base de données par locataire

Par exemple, Google et Salesforce suivent le premier modèle et font partager les mêmes tables aux clients hébergés. Stackoverflow, quant à lui, suit le second modèle et conserve une base de données par locataire. La seconde approche est également plus courante dans les industries réglementées, telles que la santé.

La décision dépend de la dimension principale pour laquelle vous optimisez la conception de votre base de données. Cet article sur la conception de votre La base de données SaaS à l'échelle décrit les compromis et fournit un résumé dans le contexte de PostgreSQL.

Answer 8

Un autre point à considérer est que vous pouvez avoir l'obligation légale de séparer les données d'une entreprise de celles d'une autre.

Answer 9

Avoir une base de données par client ne s’adapte généralement pas bien. MySQL (et probablement d’autres bases de données) contient des ressources ouvertes par table, ce qui ne se prête pas bien à 10k + tables sur une instance, ce qui se produirait dans une situation de multitenancy à grande échelle.

Bien sûr, si vous rencontrez un autre problème susceptible de vous causer d'autres problèmes avant d'arriver à ce niveau, il se peut que cela ne soit pas pertinent.

De plus, "sharding" Une application multi-locataire est susceptible de constituer la bonne chose à faire à mesure que votre application grossit.

Éclatement ne signifie toutefois pas une base de données (ou instance) par locataire, mais une base par fragment ou ensemble de fragments, qui peuvent avoir chacun plusieurs locataires. Vous aurez besoin de découvrir les bons paramètres de réglage pour vous-même, probablement en production (par conséquent, il doit probablement être assez ajustable dès le départ)

€ je ne peux pas le garantir.

Answer 10

Vous pouvez commencer avec une base de données unique et la partitionner au fur et à mesure que l'application grandit. Si vous faites cela, voici quelques recommandations que je recommanderais:

1) Concevez la base de données de manière à pouvoir la partitionner facilement. Par exemple, si les clients vont partager des données, assurez-vous qu’elles sont facilement répliquées dans chaque base de données.

2) Lorsque vous n'avez qu'une seule base de données, assurez-vous qu'elle est sauvegardée sur un autre serveur physique. En cas de basculement, vous pouvez rétablir le trafic sur cet autre serveur tout en maintenant vos données intactes.