Bases de données multiples V / s simples

17

J'ai construit cette application web (php et mysql) qui stocke des informations pour diverses organisations (environ 20 clients actuellement).

Le scénario actuel stocke les informations relatives au client dans des bases de données individuelles, il y a donc 20 bases de données client et 1 base de données master.

L'un des principaux avantages ici est que, comme chaque base de données client est isolée, la numérotation des artefacts clients (rapports, audits), etc. est séquencée; donner à nos clients un sentiment de sécurité.

Chaque base de données possède environ 15 tables, et le plus grand nombre de lignes dans une table est d'environ 2000. Cela devrait être augmenté jusqu'à 5 000 enregistrements, au maximum.

La gestion d'une seule modification au niveau de la base de données signifie la modification de 20 bases de données, mais dans les rares cas où je dois effectuer une telle modification, j'utilise un script qui le fait en un seul appel de fonction.

Nous sommes sur un arrangement d'hébergement partagé, et notre FAI nous fournit un nombre limité. des bases de données; et c'est ce qui m'a amené à penser en termes de centralisation de la base de données; afin que TOUTES les données client puissent être stockées dans la base de données master.

Bien sûr, certains problèmes importants qui surgissent sont:

une. Maintenir la séquence des artefacts (cela pourrait être résolu en créant une clé de référence supplémentaire) b. Vitesse et performances (auquel cas je peux créer des index pour accélérer les choses) c. Sécurité: cela sera géré comme chaque requête qui récupère les informations client. suivra également leur client_id

À l'avenir, nous devrons peut-être envisager de comparer les ensembles de données d'une organisation à une autre, mais je pense que cela peut également être réalisé sur une base de données centralisée. Je suis quelque peu enclin (pour des raisons de performances et de maintenabilité) à passer à une base de données centralisée.

Pensez-vous que passer à une base de données centralisée est plus logique que de rester tel que nous sommes (sur des bases de données individuelles)?

Merci pour vos conseils.

Narayan
la source
Cela ressemble plus à une question StackOverflow qu'à un problème de Webmasters pour moi?
kander
C'est pour stackoverflow.com.
vmarquez
En plus des excellentes suggestions ici, il est également sage de savoir s'il existe des lois applicables dans votre région sur la façon dont les informations spécifiques sur les clients peuvent être stockées. De plus, en cas de violation, il y a un facteur de risque / responsabilité avec lequel vous devez être à l'aise. Juste une pensée.
lâche anonyme
Ou passez à PostgreSQL où vous bénéficierez de ses schémas, qui adhèrent à la définition standard SQL, contrairement à MySQL. Dans PostgreSQL, vous avez database.schema.table tandis que dans MySQL, la base de données et le schéma sont synonymes.
Mario

Réponses:

13

Il existe des risques et des avantages hérités pour les deux systèmes. J'ai travaillé pour une société financière qui a accompagné environ 40 clients (banques nationales) sur 1 base de données. Nous avons ensuite acheté une autre entreprise qui vendait des logiciels similaires et qui était allée avec 1 base de données par client. Enfin, l'entreprise a fait faillite et nous avons dû exporter toutes les données des utilisateurs. Voici ce que les gens avec qui j'ai travaillé et que j'ai trouvé:

Avantages de Single DB:

  1. Les mises à jour logicielles et les corrections de bogues sont plus faciles.
  2. Facile à gérer et à générer des rapports sur toutes les données client.
  3. La mise à jour des données devient plus facile.
  4. Facile à créer une fonctionnalité modulaire souhaitée par 1 client, désactivez-la pour les autres clients, puis désactivez-la quand ils le souhaitent à l'avenir.

Les inconvénients de Single DB:

  1. Intégrité des données - Nous avons eu 2 ou 3 cas où les utilisateurs d'une banque ont vu les données d'une autre banque. Ce fut un cauchemar. Surtout parce que les utilisateurs du site n'étaient pas seulement les employés de la banque, mais les véritables clients de la banque! C'est de loin le plus gros problème avec 1 base de données
  2. Exporter les données des clients -Lorsque nous y étions confrontés, ce n'était généralement pas un gros problème. Vous vous retrouvez avec 1 table qui contient tous les clients et vous vous déconnectez de cette table pour obtenir les données spécifiques de votre client.

Avantages de plusieurs bases de données:

  1. Il n'y a aucun problème de contamination ou de violation de données entre clients
  2. Exporter les données d'un client est très simple.

Les inconvénients de plusieurs bases de données:

  1. Mises à jour et corrections de bugs - Ce fut le vrai cauchemar. Lorsque vous avez 20 clients sur 20 bases de données différentes, vous rencontrez rapidement le cas où 1 client souhaite un bug corrigé et un autre pense que le bug est une fonctionnalité ou ne veut pas risquer la mise à jour. De plus, vous aurez des cas où 1 client souhaite une amélioration du jeu mais pas les autres clients. Lorsque cela se produit, vos bases de données commencent à diverger. Soudain, vous devrez mettre à jour les clients 1-15 avec 1 script 16-19 avec un autre et 20 avec un troisième. Nous avons vu que cela devenait un problème tel qu'une correction de bogue prenait 15 à 20 fois plus de temps pour l'entreprise que nous avions achetée que pour nous, car ils devaient exécuter tous les tests pour chaque client et gérer le code spécial de chaque client. En effet, ils avaient besoin d'une nouvelle personne de soutien pour chaque nouveau client,
  2. Gestion des bases de données - Lorsque vous accédez à un grand nombre de clients, la gestion de toutes les bases de données devient un véritable problème. Vous aurez sans aucun doute besoin de plus de temps DBA pour les gérer.

Au final ma recommandation après avoir vu et fait les deux c'est d'avoir de la "discipline"! Je pense que le choix multi-db est légèrement meilleur car il vous protège mais vous ne pouvez jamais laisser vos clients faire un choix qui vous oblige à ajouter des fonctionnalités uniquement à eux ou vous vous mettrez sur la voie de l'échec.

Ben Hoffman
la source
Merci mon pote, apprécie ton aide. Je suis d'accord pour dire que cela se résume à s'attaquer à un tel problème avec une approche disciplinée et à garder un contrôle strict sur la façon dont le système est étendu.
Narayan
14

J'aurais une base de données distincte pour des clients distincts. Un client peut l'exiger pour des raisons de sécurité - c'est-à-dire que seul son site a accès à ses données. Cela signifie également que si un client souhaite déplacer ses données, cela sera beaucoup plus facile à gérer.

Cela signifie également que s'il y a un problème avec la base de données d'un client, cela n'affecte pas tous les autres.

Si vous souhaitez comparer les données entre les clients, vous devez le faire séparément.

Si vous manquez de bases de données que vous pouvez avoir, vous devriez peut-être envisager de changer de fournisseur d'hébergement.

ChrisF
la source
+1 pour les clients qui demandent leurs données. Il pourrait rapidement devenir plus coûteux d'écrire quelque chose pour extraire uniquement les données des clients que de payer pour des bases de données distinctes.
carson
1
Non seulement cela, cela permet aux clients individuels de «évoluer» à des taux différents, ce qui est un avantage majeur.
Tim Post
@Tim - bon point.
ChrisF
Oui, j'ai oublié de voter. +1 :)
Tim Post
Merci @Tim et @Chris, vos idées ont été utiles.
Narayan
0

La seule raison pour laquelle je n'aurais pas de base de données individuelle pour chaque client est si vous allez avoir des centaines ou des milliers de clients / bases de données. Cela pourrait devenir très difficile à gérer, y compris apporter des modifications à la base de données ou faire quelque chose dans toutes les bases de données. Les actions qui se produisent sur un grand nombre de bases de données multiples peuvent également être lentes car vous devez ouvrir (et donc fermer) autant de tables.

Mais à part ce cas, je pense que plusieurs bases de données sont meilleures.

Un avantage, qui peut ne pas être important mais peut être utile, est que chaque client obtient ses propres ID séquentiels (au lieu de sauter éventuellement un groupe car un autre client a ajouté des enregistrements).

De plus, plusieurs bases de données permettent aux sous-tables (comme le type de téléphone) d'être facilement personnalisables par client sans avoir besoin d'un ID d'enregistrement parent dans ces tables également.

Darryl Hein
la source
0

D'abord le séquençage des artefacts. Je suppose que vous utilisez des clés primaires entières pour fournir cela. Vraiment, vous devriez avoir une colonne "numéro d'artefact" séparée. Les PK devraient être des PK et rien d'autre. Les gens parlent de "clés naturelles" et autres et je grince des dents. Chaque fois que vous comptez sur le PK pour être plus qu'un identifiant, il revient à vous mordre. Si vous voulez connaître la séquence de quelque chose, enregistrez une date ou un numéro de séquence.

Je pense que dans votre cas, la gestion de la configuration vous conduirait à une seule base de données. Regardez ce qu'il vous en coûte à temps pour maintenir et mettre à niveau les bases de données. Quels sont les coûts associés à chaque version du logiciel? Pensez également au coût lorsque vous obtenez un nouveau client et devez créer une base de données et configurer l'application pour cela. Tout peut être automatisé, la question est de savoir si cela en vaudra la peine lorsque vous aurez 100 bases de données?

En fin de compte, il est plus facile de faire évoluer (partitionnement, matériel, partitionnement, etc.) une seule base de données que de faire de même pour 100 bases de données.

Je pense que les autres affiches ont fait quelques excellents points donc je ne vais pas les passer en revue.

Gareth Farrington
la source
0

Pour ajouter aux avantages et aux inconvénients répertoriés jusqu'à présent:

Avantages de plusieurs bases de données:

  1. Les problèmes de verrouillage sont évités; nous avons des bases de données où les clients peuvent déclencher des modifications DDL sur certaines tables. Pour les tables plus grandes (> 2 m d'enregistrements), cela verrouille la table pendant une durée considérable. Les seules personnes désavantagées sont leurs propres utilisateurs, c'est donc en quelque sorte acceptable.

  2. Flexibilité - certains clients ont des souhaits spécifiques concernant les données qu'ils souhaitent stocker; multi-base de données nous a permis de modifier spécifiquement leur base de données, sans avoir à encombrer le modèle de données pour les autres clients.

Les inconvénients:

  1. Con majeur: se joindre à d'autres tables est beaucoup plus lourd. Nous avons une base de données principale qui contient la plupart des métadonnées. Les utilisateurs de la base de données spécifiques au client n'ont pas accès à cette base de données, donc toutes les jointures entre les tables de cette base de données et celles spécifiques au client sont gérées dans l'application plutôt que dans la base de données. Vous pouvez résoudre ce problème en donnant aux utilisateurs spécifiques au client l'accès à la base de données principale, mais l'application pourrait / pourrait alors à nouveau divulguer des informations.

Bonne chance dans le choix!

kander
la source
0

Je sais que vous avez déjà choisi une réponse, mais il semble qu'il y ait une autre solution qui n'a pas été suggérée:

Déplacez tout dans une base de données, mais créez des tables pour chaque client, en utilisant un préfixe, comme ceci:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

C'est en quelque sorte le meilleur des deux mondes.

  • Il est très facile de migrer de votre configuration actuelle vers la nouvelle configuration.
  • Vous pouvez créer 1 utilisateur par client et restreindre ses privilèges aux tables de son entreprise et rien d'autre
  • Vous pouvez créer un superutilisateur et agréger facilement les données si vous en avez besoin.
  • Utiliser une seule base de données
Sylver
la source
Je n'ai certainement pas pensé à cette approche. Cela semble tout à fait réalisable, mais là encore ce qui limite c'est le facteur de complexité lors de la mise à l'échelle. Étant donné que j'aurais au moins 18 tables par client, une configuration de 20 clients signifierait 360 tables dans la base de données pour commencer. Et si nous atteignons un niveau proche de nos prévisions de ventes, la gestion d'une base de données de 1800 tables serait pénible. Comparativement, il serait préférable de gérer 100 bases de données avec 18 tables chacune. Merci pour vos commentaires.
Narayan
@ Narayan: vous êtes les bienvenus. Ça fait beaucoup de tableaux. À l'autre extrémité, toutes ces opérations de table pourraient facilement être automatisées, donc ce n'est pas aussi grave qu'il n'y paraît. Tout ce dont vous avez besoin est une table clients répertoriant les noms des tables. Rend plus facile que d'avoir à se connecter / déconnecter à 100 bases de données différentes, en fait. Quoi qu'il en soit, ce n'était qu'une suggestion. Il existe de nombreuses façons d'écorcher ce chat.
Sylver
ps: La seule vraie limite au nombre de tables que vous pouvez avoir est le nombre de fichiers qui peuvent être ouverts simultanément sur votre OS. Pour une machine Linux typique, c'est 75 000 par défaut. Sinon, Ms SQL Server autorisera jusqu'à 2 milliards de tables.
Sylver