MySQL: plusieurs tables ou plusieurs bases de données?

Question

Pour un projet, nous avons d'avoir un paquet de données qui ont toujours la même structure et n'est pas lié ensemble. Il existe deux approches pour enregistrer les données:

• La création d'une nouvelle base de données pour chaque piscine (environ 15 à 25 tables)
• La création de toutes les tables dans une base de données et de différer la piscine par les noms de table.

Ce qui est plus facile et plus rapide à gérer pour MySQL?

EDIT: je ne suis pas interessed dans les problèmes de conception de base de données, je suis juste interessed dans laquelle des deux possibilités est plus rapide.

EDIT 2: je vais essayer de le rendre plus clair. Comme l'a dit nous avons des données, où certains de la date rarement appartient, ensemble, dans les différents bassins. Mettre toutes les données d'un type dans un tableau et de le lier avec un id de pool n'est pas une bonne idée:

• Il est difficile de sauvegarde/supprimer un pool (et nous nous attendons à ce que nous sommes en cours d'exécution des clés primaires après un certain temps (même lors de l'utilisation de grandes int))

Donc l'idée est de faire une base de données pour chaque bassin 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 sera simple, inserts. 49% d'être un simple selects sur une clé primaire.

La question est, ce qui est plus rapide à manipuler, MySQL? De nombreuses tables ou plusieurs bases de données?

Answer 1

Il devrait y avoir aucune différence de performances significative entre plusieurs tables dans une base de données unique rapport de plusieurs tables des bases de données distinctes.

Dans MySQL, les bases de données (SQL standard utilise le terme de "schéma") servent principalement comme un espace de noms pour les tables. Une base de données a seulement quelques attributs, par exemple, le jeu de caractères par défaut et le classement. Et que l'utilisation de GRANT le rend pratique pour le contrôle des privilèges d'accès de données par base de données, mais qui n'a rien à voir avec la performance.

Vous pouvez accéder aux tables dans une base de données à partir d'une seule connexion (à condition qu'ils soient gérés par la même instance de Serveur MySQL). Vous avez juste à qualifier le nom de la table:

SELECT * FROM database17.accounts_table;

Ceci est purement syntaxique différence. Il ne doit avoir aucun effet sur les performances.

Concernant le stockage, vous ne pouvez pas organiser des tables dans un fichier de base de données comme @Chris spécule. Avec le moteur de stockage MyISAM, vous avez toujours un fichier par table. Avec le moteur de stockage InnoDB, vous disposez d'un seul ensemble de fichiers de stockage qui fusionnent toutes les tables, ou bien vous avez un fichier par table (ce qui est configuré pour l'ensemble du serveur MySQL, et non par la base de données). Dans les deux cas, il n'y a pas d'avantage ou de désavantage à la création des tables dans une base de données de rapport à de nombreuses bases de données.

Il n'y a pas beaucoup de la configuration de MySQL les paramètres qui fonctionnent par base de données. La plupart des paramètres qui influent sur les performances du serveur sont à l'échelle du serveur dans le champ d'application.

Concernant les sauvegardes, vous pouvez spécifier un sous-ensemble de tableaux comme arguments au mysqldump commande. Il peut être plus pratique pour sauvegarder des ensembles logiques de tables par base de données, sans avoir à le nom de toutes les tables sur la ligne de commande. Mais il devrait faire aucune différence de performance, seule la commodité pour vous que vous entrez dans la commande de sauvegarde.

Answer 2

Pourquoi ne pas créer une table unique pour garder une trace de vos piscines (avec un PoolID et PoolName que vous colonnes, et tout ce que vous voulez de piste), puis sur votre 15-25 tables, vous devez ajouter une colonne sur tous ce qui serait une clé étrangère dans la piscine de la table de sorte que vous savez qui la piscine cet enregistrement particulier appartient.

Si vous ne voulez pas mélanger les données comme ça, je vous suggère de faire plusieurs bases de données. Création de plusieurs tables à tous pour la même fonctionnalité permet à mon sens d'araignée de tingle.

Answer 3

Si vous ne voulez pas un ensemble de tables avec poolID poolname comme TheTXI suggéré, l'utilisation des bases de données distinctes, plutôt que de multiples tableaux qui tous la même chose.

De cette façon, vous limitez la variation entre les accès des différents pools à la première "base de données", vous n'aurez pas à recoder votre Sélectionne à chaque fois, ou avoir du sql dynamique.

Les autres avantages de cette approche sont:

• Facile de sauvegarde/restauration
• Easy start/stop d'une instance de base de données.

Les inconvénients sont les suivants:

• un peu plus d'admin de travail, mais pas beaucoup.

Je ne sais pas ce que votre demande est, mais vraiment vraiment bien réfléchir avant de créer toutes les tables dans une base de données. De cette façon, la folie réside.

Edit: Si la performance est la seule chose qui vous concerne, vous avez besoin de la mesurer. Prendre un ensemble représentatif de requêtes et de mesurer leurs performances.

Edit 2: La différence de performance pour une seule requête entre les tables de nombreux/plusieurs bases de données modèle sera négligeable. Si vous avez une base de données, vous pouvez régler l'enfer hors de lui. Si vous avez plusieurs bases de données, vous pouvez régler l'enfer hors d'eux tous.

Mon (notre? - on ne peut pas parler pour quelqu'un d'autre) le point est que, pour bien à l'écoute de la base de données(s), il y aura pratiquement pas de différence de performance entre les trois options (poolid dans le tableau, plusieurs tables, plusieurs bases de données), de sorte que vous pouvez choisir l'option qui est plus facile pour vous, dans le court ET le long terme.

Pour moi, la meilleure option est encore une base de données avec poolId, comme TheTXI suggéré, puis de multiples bases de données, en fonction de votre (principalement de l'administration) des besoins. Si vous avez besoin de savoir exactement ce que la différence de performance entre deux options, nous ne pouvons pas vous donner la réponse. Vous avez besoin de le configurer et de le tester.

Avec de multiples bases de données, il devient facile de jeter du matériel pour améliorer les performances.

Answer 4

Dans la situation que vous décrivez, l’expérience m’a amené à penser que les bases de données séparées sont plus rapides lorsque vous avez un grand nombre de pools.

Il y a cependant un principe général très important à observer: ne songez pas à la vitesse à laquelle cela va aller, profilez-le.

Answer 5

Je ne suis pas trop sûr que je comprends parfaitement votre scénario. Voulez-vous d'avoir toutes les piscines utilisant les mêmes tables, mais juste différant par un trait clé? Ou voulez-vous des piscines séparées de tables dans une base de données, avec un suffixe sur chaque table pour distinguer les piscines?

De toute façon, vous devriez avoir plusieurs bases de données pour deux raisons principales. La première étant que si vous avez à modifier le schéma d'une piscine, cela n'affectera pas les autres.

La deuxième, si votre charge augmente (ou pour toute autre raison), vous pouvez déplacer les piscines sur les machines avec de nouveaux serveurs de base de données.

Aussi, la sécurité de l'accès à un serveur de base de données peut être plus solidement verrouillé.

Toutes ces choses peuvent encore être accomplis sans exiger des bases de données distinctes - mais la séparation va rendre tout cela plus facile et de réduire la complexité d'avoir mentalement à suivre les tables que vous souhaitez utiliser.