MySQL: Beaucoup de tables ou de bases de données?
Pour un projet, nous avons un tas de données qui ont toujours la même structure et qui ne sont pas liées entre elles. Il existe deux approches pour enregistrer les données:
- Création d'une nouvelle base de données pour chaque pool (environ 15-25 tables)
- Créer toutes les tables dans une base de données et différencier les pools par les noms de table.
Laquelle est la plus simple et la plus rapide à gérer pour MySQL?
EDIT: Je ne suis pas intéressé par les problèmes de conception de base de données, je suis simplement intéressé par laquelle des deux possibilités est plus rapide.
EDIT 2: Je vais essayer de le rendre plus clair. Comme nous l'avons dit, nous aurons des données, où une partie de la date appartient rarement ensemble dans différents pools. Mettre toutes les données d'un type dans une table et les lier à un identifiant de pool n'est pas une bonne idée:
- Il est difficile de sauvegarder/supprimer un pool spécifique (et nous nous attendons à ce que nous manquions de clés primaires après un certain temps (même en cas d'utilisation de big int))
L'idée est donc de créer une base de données pour chaque pool ou de créer un grand nombre de tables dans une base de données. 50% des requêtes sur la base de données seront simples inserts. 49% sera un simple selects sur une clé primaire.
La question est, qu'est-ce qui est plus rapide à gérer pour MySQL? De nombreuses tables ou de nombreuses bases de données?
Il ne doit pas y avoir de différence de performances significative entre plusieurs tables dans une seule base de données et plusieurs tables dans des bases de données distinctes.
Dans MySQL, les bases de données (SQL standard utilise le terme "schéma" pour cela) servent principalement d'espace de noms pour les tables. Une base de données n'a que quelques attributs, par ex. le jeu de caractères et le classement par défaut. Et cette utilisation de GRANT facilite le contrôle des privilèges d'accès par base de données, mais cela n'a rien à voir avec les performances.
Vous pouvez accéder aux tables de n'importe quelle base de données à partir d'une seule connexion (à condition qu'elles soient gérées par la même instance de MySQL Server). Il vous suffit de qualifier le nom de la table:
SELECT * FROM database17.accounts_table;
Il s'agit purement d'une différence syntaxique. Cela ne devrait avoir aucun effet sur les performances.
En ce qui concerne le stockage, vous ne pouvez pas organiser les tables dans un fichier par base de données comme le spécule @Chris. Avec le moteur de stockage MyISAM, vous avez toujours un fichier par table. Avec le moteur de stockage InnoDB, vous avez soit un seul ensemble de fichiers de stockage qui fusionnent toutes les tables, soit vous avez un fichier par table (il est configuré pour l'ensemble du serveur MySQL, pas par base de données). Dans les deux cas, il n'y a aucun avantage ou inconvénient en termes de performances à créer les tables dans une seule base de données par rapport à de nombreuses bases de données.
Il n'y a pas beaucoup de paramètres de configuration MySQL qui fonctionnent par base de données. La plupart des paramètres qui affectent les performances du serveur ont une portée à l'échelle du serveur.
Concernant les sauvegardes, vous pouvez spécifier un sous-ensemble de tables comme arguments de la commande mysqldump. Il peut être plus pratique de sauvegarder des ensembles logiques de tables par base de données, sans avoir à nommer toutes les tables sur la ligne de commande. Mais cela ne devrait pas faire de différence en termes de performances, uniquement pour votre confort lorsque vous entrez la commande de sauvegarde.
Pourquoi ne pas créer une seule table pour garder une trace de vos pools (avec un PoolID et PoolName comme colonnes, et tout ce que vous voulez suivre), puis sur vos 15-25 tables, vous ajouteriez une colonne sur chacune d'entre elles qui serait une clé étrangère de retour à votre table de pool afin que vous sachiez à quel pool cet enregistrement particulier appartient.
Si vous ne voulez pas mélanger les données comme ça, je suggère de créer plusieurs bases de données. Créer plusieurs tables pour la même fonctionnalité fait vibrer mon sens de l'araignée.
Si vous ne voulez pas un ensemble de tables avec poolID poolname comme TheTXI l'a suggéré, utilisez des bases de données distinctes plutôt que plusieurs tables qui font toutes la même chose.
De cette façon, vous limitez la variation entre l'accès aux différents pools à l'instruction initiale "use database", vous n'aurez pas à recoder vos SELECT à chaque fois, ou à avoir SQL dynamique.
Les autres avantages de cette approche sont:
- Sauvegarde/restauration facile
- Démarrage/arrêt facile d'une instance de base de données.
Les inconvénients sont:
- un peu plus de travail administratif, mais pas beaucoup.
Je ne sais pas quelle est votre application, mais réfléchissez bien avant de créer toutes les tables dans une seule base de données. De cette façon, la folie se trouve.
Edit: Si la performance est la seule chose qui vous concerne, vous devez la mesurer. Prenez un ensemble représentatif de requêtes et mesurez leurs performances.
Edit 2: La différence de performances pour une seule requête entre le modèle plusieurs tables/plusieurs bases de données sera négligeable. Si vous ne possédez qu'une seule base de données, vous pouvez vous en débarrasser. Si vous avez de nombreuses bases de données, vous pouvez régler l'enfer de toutes.
Mon (notre? - je ne peux parler pour personne d'autre) est que, pour des bases de données bien réglées, il n'y aura pratiquement aucune différence de performances entre les trois options (poolid dans le tableau, plusieurs tables, plusieurs bases de données), donc vous pouvez choisir l'option la plus simple pour vous, à court ET à long terme.
Pour moi, la meilleure option est toujours une base de données avec poolId, comme l'a suggéré TheTXI, puis plusieurs bases de données, en fonction de vos besoins (principalement administratifs). Si vous avez besoin de savoir exactement quelle est la différence de performances entre deux options, nous ne pouvons pas vous donner cette réponse. Vous devez le configurer et le tester.
Avec plusieurs bases de données, il devient facile d'y jeter du matériel pour améliorer les performances.
Dans la situation que vous décrivez, l'expérience m'a amené à croire que vous trouverez les bases de données distinctes plus rapides lorsque vous avez un grand nombre de pools.
Il y a cependant un principe général très important à observer ici: Ne pensez pas à quelle vitesse ça va être, profilez-le.
Je ne suis pas trop sûr de bien comprendre votre scénario. Voulez-vous que tous les pools utilisent les mêmes tables, mais se différencient simplement par une clé distinctive? Ou voulez-vous des pools de tables séparés dans la même base de données, avec un suffixe sur chaque table pour distinguer les pools?
Quoi qu'il en soit, vous devez avoir plusieurs bases de données pour deux raisons principales. La première étant que si vous devez modifier le schéma sur un pool, cela n'affectera pas les autres.
La seconde, si votre charge augmente (ou pour toute autre raison), vous souhaiterez peut-être déplacer les pools sur des machines physiques distinctes avec de nouveaux serveurs de base de données.
De plus, l'accès de sécurité à un serveur de base de données peut être verrouillé plus étroitement.
Toutes ces choses peuvent encore être accomplies sans nécessiter de bases de données distinctes - mais la séparation facilitera tout cela et réduira la complexité d'avoir à suivre mentalement les tables sur lesquelles vous souhaitez opérer.
Faire la différence entre les pools par nom de table ou les placer dans des bases de données distinctes, c'est la même chose. Cependant, si vous avez beaucoup de tables dans une base de données, MySQL doit charger les informations de la table et effectuer un contrôle de sécurité sur toutes ces tables lors de la connexion/connexion.
Comme d'autres l'ont mentionné, des bases de données distinctes vous permettront de déplacer les choses et de créer des optimisations spécifiques à un certain pool (c'est-à-dire des tables compressées). C'est une surcharge administrative supplémentaire, mais il y a beaucoup plus de flexibilité.
En outre, vous pouvez toujours "regrouper" les tables qui se trouvent dans des bases de données distinctes en utilisant des tables fédérées ou de fusion pour simplifier les requêtes si nécessaire.
En ce qui concerne le manque de clés primaires, vous pouvez toujours utiliser une clé primaire composée si vous utilisez des tables MyISAM. Par exemple, si vous avez un champ appelé groupCode (tout type) et un autre appelé sequenceId (incrémentation automatique) et créez votre clé primaire en tant que groupCode + sequenceId. Le sequenceId incrémentera en fonction de l'ID unique suivant dans l'ensemble de codes de groupe. Par exemple: AAA 1 AAA 2 BBB 1 AAA 3 CCC 1 AAA 4 BBB 2 ...
Bien qu'avec les grandes tables, vous devez faire attention à la mise en cache et vous assurer que le système de fichiers que vous utilisez gère les gros fichiers.
FTR, dans des circonstances normales, je prendrais l'approche décrite par TheTXI.
En réponse à votre question spécifique, j'ai trouvé que cela dépendait de l'utilisation. (Cop je sais, mais écoutez-moi.)
Une base de données unique est probablement plus simple. Vous devrez vous soucier d'une seule connexion et devrez toujours spécifier des tables. Cependant, plusieurs bases de données pourraient être plus rapides sous certaines conditions.
Si j'étais vous, j'essaierais les deux. Il n'y a aucun moyen que nous puissions vous donner une réponse utile.
Je ne connais pas très bien mysql, mais je pense que je vais devoir donner la réponse de performance standard - "Cela dépend".
Quelques réflexions (traitant uniquement des performances/maintenance, pas de la conception de la base de données):
- La création d'une nouvelle base de données signifie un ou plusieurs fichiers séparés dans le système de fichiers. Ces fichiers pourraient alors être placés sur des systèmes de fichiers différents si les performances de l'un doivent être séparées des autres, etc.
- Une nouvelle base de données gérera probablement la mise en cache différemment; par exemple. Toutes les tables dans une base de données vont signifier un cache partagé pour la base de données, tandis que la division des tables en bases de données distinctes signifie que chaque base de données peut avoir un cache séparé [évidemment toutes les bases de données partageront la même mémoire physique pour le cache, mais il peut y avoir une limite par base de données, etc.].
- En ce qui concerne les fichiers séparés, cela signifie que si l'un de vos ensembles de données devient plus important que les autres, il peut facilement être retiré vers un nouveau serveur.
- La séparation des bases de données présente l'avantage supplémentaire de vous permettre de déployer les mises à jour une par une plus facilement qu'avec la base de données unique.
Cependant, en revanche, avoir plusieurs bases de données signifie que le serveur utilisera probablement plus de mémoire (car il a plusieurs caches). Je suis sûr qu'il y a plus de "contre" pour l'approche multi-base de données, mais je dessine un blanc maintenant.
Je suppose donc que je recommanderais l'approche multi-bases de données. Évidemment, ce n'est qu'avec la compréhension qu'il peut très bien y avoir une meilleure façon "de conception de base de données" de gérer tout ce que vous faites réellement.
Compte tenu des restrictions que vous y avez placées, je préfère faire tourner plus de tables dans la base de données existante, plutôt que d'avoir à vous connecter à plusieurs bases de données. La gestion des chaînes de connexion a tendance à être plus difficile, en plus de gérer les différentes optimisations de base de données que vous pouvez avoir.