Nous avons une situation où nous pouvons (A) déployer des instances d'une application dans une base de données MySQL en utilisant le préfixe de table ou (B) utiliser différentes bases de données MySQL pour chaque instance de l'application, par exemple,
Mettre en place un":
central_database
app1_table1
app1_table2
app1_tablen
...
appn_table1
appn_table2
appn_tablen
Le résultat final étant une grande base de données avec de nombreuses tables.
Configuration "B":
app1_db
table1
table2
tablen
...
appn_db
table1
table2
tablen
Le résultat final étant de nombreuses bases de données avec quelques tables.
Toutes choses étant égales par exemple (quantité de données, nombre d'instances d'application, etc.), quels sont les avantages et les inconvénients de l'une ou l'autre approche? Qu'est-ce qui serait préjudiciable aux performances et à la maintenance de la base de données? L'application est basée sur PHP 5, exécutée sur Apache 2.x, et nous exécutons MySQL 5.x.
Merci beaucoup pour votre temps et vos pensées!
J'ai géré un système avec la meilleure partie d'un millier de bases de données, réparties sur plusieurs serveurs. Ils étaient tous d'une structure identique et étaient synchronisés avec une base de données de modèles qui se trouvait sur chacune des machines.
Cela m'a permis de migrer des bases de données d'une base de données à l'autre si l'une était excessivement surchargée, et au fur et à mesure que la composition des clients changeait, je pouvais créer de nouvelles bases de données sur différents serveurs pour équilibrer la charge entre les serveurs. C'était le plus grand avantage que j'ai obtenu du système, en ce sens que j'avais plusieurs gros morceaux d'étain effectuant simultanément plusieurs requêtes compliquées sur des serveurs séparés.
La grande chose à ce sujet, c'est que vous pouvez ajouter des serveurs à la configuration à votre propre vitesse, car chaque serveur commence à être surchargé, en ajouter un autre dans le mix, migrer quelques dbs vers le nouveau serveur et se retrouver avec un bien charger un ensemble équilibré de serveurs. Un moyen vraiment agréable et simple d'ajouter de l'échelle au système au fur et à mesure des besoins!
La raison pour laquelle j'ai choisi cette approche plutôt que l'approche de base de données unique énorme, était la taille même de la base de données potentielle qui aurait été créée ... chacune des 1000 bases de données avait 200 tables et de nombreuses tables individuelles au sein de chacun des les bases de données comprenaient plusieurs centaines de millions de lignes de données!
Une configuration de base de données unique aurait nécessité que certaines tables (environ 8 d'entre elles) contiennent plusieurs milliards de lignes de données, et la taille totale de la base de données aurait dépassé 10 To. Nous avons pu avoir plusieurs serveurs avec 5 To de stockage RAID 10, avec de nombreuses bases de données sur chacun.
Voilà ce que je ferais! J'espère que cela aide votre prise de décision ... :)
L'application que vous créez est-elle une application SaaS? Dans l'affirmative, je vous suggère d'envisager une troisième approche - avoir une base de données, avec une structure commune pour toutes les instances d'application avec une différence - ajouter un ID utilisateur/applicationid colonne dans toutes les tables. Cela réduira considérablement vos coûts de développement/maintenance d'application. D'après mon expérience, c'est l'une des meilleures approches pour stocker des données multi-locataires.
Voir aussi ceci grand livre blanc de Microsoft sur l'architecture de données multi-tenant
Il met également en évidence les avantages/inconvénients des approches que vous avez mentionnées.
La configuration B est beaucoup plus facile à gérer
Chaque tablen
se trouve dans un dossier différent. Cela peut être très bénéfique si vous ne voulez pas tester les limites du système d'exploitation.
Par exemple, mon employeur héberge MySQL pour un système CRM de concessionnaires automobiles. Le client compte 800 concessionnaires. Chaque base de données de concession a 160 tableaux. C'est 128 000 tables.
Du point de vue du système d'exploitation et de sa capacité à gérer les i-nœuds (ou les tables FAT pour Windows), ce qui comprend le fait d'avoir un nombre maximal de fichiers par dossier:
Si vous deviez tweek des structures de table en utilisant ALTER TABLE
ou un autre DDL:
/var/lib/mysql
Si vous souhaitez placer différentes bases de données sur différents disques:
.frm
les fichiers sont consultés à plusieurs reprises.Parlant métaphoriquement, lequel préféreriez-vous?
Quand il s'agit de fixer un radiateur dans un appartement:
IHMO Bien que les budgets puissent être un moteur pour les décisions de conception/infrastructure, je serais facilement en faveur de séparer les bases de données par client.
J'ai également un produit SaaS et j'utilise la même configuration que Dave Rix mentionnée.
Chaque client a sa propre base de données
Je ferais encore quelques suggestions:
Vous devez disposer d'un "contrôleur" de base de données à charge équilibrée (maître-maître), qui stocke l'emplacement de la base de données (ip), le nom de la base de données et le nom du client. Ce contrôleur est l'endroit où votre application sait où se trouve chaque base de données clients.
Votre application peut être n'importe où: vous pouvez disposer de bases de données pour de nombreux centres de données à travers le monde.
Votre application peut évoluer autant que vous le souhaitez. S'il s'agit d'un Web SaaS, vous pouvez créer une batterie de serveurs Web à charge équilibrée pointant vers chaque base de données, au moment de la connexion du client.
Vous pouvez créer une VUE/Base de données personnalisée pour certains clients - sans impact sur les autres. C'est important si vous essayez de proposer la personnalisation dans le cadre de votre entreprise.
Vous pouvez configurer deux batteries de serveurs Web + batteries de bases de données: une pour les versions "Edge" et une autre pour les versions "STABLE". Ensuite, vous devrez avoir un petit groupe de clients prêts à tester les choses et à confirmer que tout fonctionne comme prévu (en d'autres termes, l'assurance qualité [AQ]), avant de postuler à tous vos clients.
Vous devez avoir un travail de sauvegarde automatisé par base de données au moins une fois par jour.
Vous devez avoir un autre serveur pour effectuer la réplication. Un même hôte peut répliquer de nombreuses bases de données (utiliser des ports différents pour chaque serveur sur le même hôte) si vous ne pouvez pas vous permettre la même quantité de serveurs hôtes "maître" et "esclave".
Par exemple, 5 serveurs maîtres + 1 serveur esclave avec 5 bases de données fonctionnant sur différents ports - il suffit d'avoir RAM assez pour le faire).
Vous devez faire un outil de "migration" pour déplacer une base de données vers un autre serveur à tout moment.
Vous devez migrer VIP clients vers un serveur de base de données plus sécurisé/disponible afin de protéger vos revenus. Souvenez-vous, souvent, 20% des clients représentent 80% de vos revenus. Prenez soin de clients spéciaux.
Vous devez avoir un collecteur de sauvegarde "supprimer", pour faire une "dernière sauvegarde" et supprimer la base de données lorsqu'un client quitte votre entreprise.
Vous devez avoir une image de base de données où vous exportez et utilisez pour de nouveaux comptes.
Vous devez disposer d'un outil de correction de base de données pour appliquer de nouveaux correctifs aux comptes existants.
Conservez les versions de tous vos correctifs SQL, en utilisant un outil de versioning comme Subversion ou git et créez également votre propre numérotation. xxx-4.3.0.sql - parfois les correctifs se passent mal et vous devez savoir comment récupérer/terminer la tâche de correction.
Eh bien, c'est tout ce que je fais dans mon entreprise avec un produit qui a environ 5k bases de données avec environ 600 tables chacune.