Une grande base de données contre plusieurs plus petits

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 comme le mélange de 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. Une façon très 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 dans chacune 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? Si c'est le cas, 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 une colonne userid / applicationid dans toutes les tables. Cela réduira considérablement les coûts de développement / maintenance de vos applications. D'après mon expérience, c'est l'une des meilleures approches pour stocker des données multi-locataires.

Voir également ce grand livre blanc de Microsoft sur l'architecture de données multi-locataires

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

Chacun se tablentrouve dans un dossier différent. Cela peut être très bénéfique si vous ne souhaitez 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.

• Sous le programme d'installation A, les 128 000 tables se trouveraient sous une seule base de données.
• Sous Configuration B, chaque ensemble de 160 tables se trouve dans un sous-dossier sous / var / lib / mysql.

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:

• Sous Configuration A, vous vous inquiétez de 128 000 fichiers dans un seul dossier. Votre système d'exploitation peut-il prendre en charge autant de fichiers dans un seul dossier?
• Sous Configuration B, pas de soucis.

Si vous deviez modifier les structures de table en utilisant ALTER TABLEou un autre DDL:

• Sous la configuration A, vous devez créer le script DDL requis à l'aide de PHP (ou de scripts MySQL spécialisés) par rapport au nom de table spécifique et aux requêtes correspondantes avant d'y accéder et d'apporter des modifications.
• Sous Configuration B, connectez-vous à la base de données de droite, puis accédez à la même table nommée à chaque fois. Le paradigme d'accès serait toujours propre:
  • Base de données spécifique
  • Dossier spécifique sous /var/lib/mysql
  • Specfic TableName.

Si vous souhaitez placer différentes bases de données sur différents disques:

• Sous le programme d'installation A, les liens symboliques pour chaque table déplacée vers un disque distinct ne feront qu'exacerber le problème du "nombre d'inodes dans un dossier". Les E / S disque et l'accès global aux tables compliquent davantage et augmentent la charge globale du serveur car les .frmfichiers sont accédés de manière répétée.
• Sous Configuration B, déplacez simplement un dossier de base de données entier dans un montage de données distinct. Les E / S disque peuvent être distribuées sur demande.
• CAVEAT: fortement découragé pour InnoDB

Parlant métaphoriquement, lequel préféreriez-vous avoir?

• un gigantesque appartement avec une chambre, une salle de bain et une cuisine (SetupA)
• plusieurs appartements, chacun avec sa propre chambre, salle de bains et cuisine (SetupB)

Quand il s'agit de fixer un radiateur dans un appartement:

• Avec la configuration A, chaque locataire peut être gêné et doit être impliqué car vous devez parler avec les locataires concernés devant tout le monde comme si c'était l'affaire de tous
• Avec la configuration B, à part entendre des coups sur le mur ou dans les tuyaux, les locataires peuvent continuer leur vie privée
• Cette liste et ses métaphores peuvent continuer indéfiniment

IHMO Bien que les budgets puissent être une force motrice 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 devriez avoir 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 aurez besoin d'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é [QA]), 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 (utilisez 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 s'exécutant sur différents ports - il suffit d'avoir suffisamment de RAM 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 les clients VIP vers un serveur de base de données plus sécurisé / disponible afin de protéger vos revenus. N'oubliez pas que bien des fois, 20% des clients représentent 80% de vos revenus. Prenez soin de clients spéciaux.

• Vous devriez 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.