Quels problèmes vais-je rencontrer en créant une base de données par client?

Je me souviens des podcasts stackoverflow que Fog Creek utilise une base de données par client pour Fogbugz . Je suppose que cela signifie que les serveurs Fogbugz On Demand ont des dizaines de milliers de bases de données.

Nous commençons tout juste à développer une application Web et avons un problème similaire à résoudre (beaucoup de clients avec leurs propres données isolées).

À quels problèmes dois-je m'attendre avec l'utilisation d'une base de données par client? Comment puis-je les résoudre?

Mes pensées initiales

Avantages d'une base de données par client

• Schéma de base de données plus simple
• Sauvegardes plus simples: vous pouvez sauvegarder chaque client à son tour sans que cela ait réellement un impact sur les autres clients.
• Permet d’exporter facilement les données d’un client donné.
• Meilleures performances du cache - une écriture dans l'une des tables les plus actives n'a d'impact que sur le seul client qui a effectué l'écriture.
• Plus facile à adapter à travers le matériel. Par exemple, lorsque nous devons passer de 1 à 2 serveurs, nous ne déplaçons que la moitié de nos clients vers le nouveau serveur.

Désavantages

• MySQL peut-il gérer 5 000 bases de données? La performance serait-elle nulle?
• Les modifications apportées au schéma peuvent être difficiles à répliquer dans toutes les bases de données. Nous aurions vraiment besoin d'un plan automatisé pour cela, tel qu'une version du schéma et un script qui explique comment passer d'une base de données à une autre.
• Faire tout ce qui est commun à tous nos clients peut être gênant ou impossible
• Semblable à ce qui précède, mais toute analyse que nous souhaitons effectuer sur tous nos clients peut être impossible. Comment devrions-nous suivre l'utilisation de tous les clients, par exemple?

Cette solution s'appelle une conception multi-locataires où chaque locataire (client) a sa propre base de données. Compte tenu de cela, l'approche alternative, qui consiste en une base de données unique, doit être prise en compte:

1. Avec une seule base de données, tout le monde doit être sur la même version, peu importe quoi. Il n'est pas possible de mettre à niveau certains clients et pas d'autres. Cela peut poser problème si un client souhaite un correctif logiciel d’application qui n’est pas prêt pour une diffusion à grande échelle.
2. Avec une base de données unique, lorsque vous effectuez une mise à niveau, chaque client est en panne. Si quelque chose ne va pas, chaque client est foutu.
3. Avec une seule base de données, il est beaucoup plus difficile de limiter les ressources. Par exemple, si un client est en train de marteler la base de données, il est plus difficile de leur donner plus de ressources séparées de tout le monde.
4. Il est beaucoup plus difficile d'autoriser les utilisateurs à héberger leurs propres versions de votre application. Si vous construisez une solution qui sera utilisée par les grandes entreprises, il s'agit souvent d'un non-débutant. Leur service informatique veut un contrôle complet sur l'accès au système.
5. Il est probablement moins coûteux de développer les bases de données plutôt que de les agrandir. En d'autres termes, il est probablement plus coûteux d'investir dans du matériel plus rapide pour héberger une base de données afin de les gérer toutes que de pouvoir adapter les clients à des serveurs de base de données plus petits et moins coûteux. Je ne peux pas le dire définitivement car cela dépend beaucoup du logiciel serveur. Si vous vous en tenez à MySQL, c'est probablement parce que les coûts de licence sont négligeables. Toutefois, si vous passez à SQL Server par exemple, l’extensibilité devient beaucoup plus onéreuse, sauf si vous utilisez un environnement VPS et le rapport coût-efficacité de l’augmentation par rapport à l’évolution des modifications. Je peux toutefois dire qu’une fois que votre base de données devient très volumineuse, la gestion nécessite des niveaux d’expertise de plus en plus importants. Les bases de données très volumineuses nécessitent de manipuler plusieurs groupes de fichiers et de pousser certains index dans différents piles pour obtenir de meilleures performances. En bref, ils peuvent se compliquer très rapidement.

Avoir des bases de données séparées signifie que vous devez créer un mécanisme de mise à jour qui correspond à la version de la base de données avec la version de l'application / du site. Cependant, des bases de données séparées fournissent une isolation supérieure des données et les coûts d'hébergement d'IMO sont moins élevés. Ce n'est pas une solution pour tous les scénarios. Si votre système ne devait jamais être hébergé en dehors de votre hébergement et devait évoluer rapidement chez les clients et qu'il était souhaitable que tous les utilisateurs utilisent la même version du schéma d'application et de base de données, disposer d'une seule base de données constitue une meilleure approche.

D'après mon expérience, vous ne devriez pas créer une base de données par client. Laisse moi te donner un exemple:

L'année dernière, j'ai travaillé avec 70 bases de données (beaucoup moins de 5 000), chacune avec le même schéma et le même. En théorie, les choses se dérouleraient comme prévu (comme vous le mentionnez dans la section des avantages), mais en réalité pas beaucoup. Nous avons eu beaucoup de problèmes avec la mise à jour des schémas, le support utilisateur, la mise à jour logicielle, vous le nommez. C'était horrible.

Nous avons utilisé Firebird et j'ai été embauché après l'envoi du produit, mais cela m'a permis de ne jamais travailler avec des bases de données séparées.

Je ne dis pas que vous ne pouvez pas vous en sortir, je dis que les choses peuvent mal se passer et pour être honnête, votre liste d’avantages n’a pas semblé assez attrayante pour prendre le risque. La plupart d'entre eux peuvent être réalisés avec une seule base de données.

Vous voudrez probablement conserver une autre base de données pour suivre la version de chaque client, afin de savoir quelles versions ont ou non subi la dernière série de modifications.

Écrire les mises à niveau ne serait pas si difficile… vous pouvez écrire quelque chose qui examine le catalogue des bases de données et applique les modifications nécessaires pour que chaque base de données possède la dernière version, en ignorant éventuellement celles qui ne devraient pas être mises à niveau pour une raison quelconque.

Comme les bases de données mysql ne sont que des schémas, comme l'a souligné Gaius, si tout est exécuté à partir de la même instance de serveur, vous pouvez simplement qualifier le nom des tables que vous essayez de modifier ou obtenir des informations:

alter schema.table ...
select ... from schema.table

...

Si vous commencez à casser des choses sur plusieurs serveurs, vous pouvez toujours scripter quelque chose qui établit des connexions à plusieurs serveurs afin que vous puissiez appliquer toutes les modifications; pour les analyses, encore une fois, vous pouvez définir un ensemble de liens de base de données à l'aide de tables fédérées dans votre base de données principale pour accéder aux données à partir d'un emplacement, comme vous le liriez simplement dans les tables.

...

Sachez également qu'ils n'utilisent pas MySQL pour l'échange de pile, ils utilisent SQL Server.

Et je ne sais pas du tout quel surcoût de performance il y aurait à cette échelle dans mysql, je ne pense pas avoir jamais dépassé les 30 «bases de données» dans mysql.

J'ai un client d'hébergement Web / DB qui a plus de 750 bases de données client avec le même nombre de tables (162) et les mêmes structures de table. Ensemble, toutes les données client de mes clients totalisent 524 Go (95% InnoDB)

Imaginez toutes ces bases de données en compétition pour 13G de pool de mémoire tampon Innodb sur neuf serveurs de base de données via une réplication circulaire. La mise à l'échelle avec cette configuration matérielle n'était pas suffisante. Immédiatement, nous avons recommandé au client d’agrandir ses activités.

Nous avons récemment migré ce client vers 3 serveurs de base de données avec beaucoup plus de puissance (Éloignez-vous toujours des disques durs SSD dans des environnements à forte écriture, TOUJOURS !!!). Nous les avons mis à niveau de MySQL 5.0.90 à MySQL 5.5.9. Des différences dramatiques ont été observées presque instantanément.

L'extension doit également être prise en compte, car si vous avez des centaines de clients utilisant la même mémoire et les mêmes ressources disque, leur réduction réduit leur utilisation linéairement (O (n)), où n est basé sur le nombre de serveurs de base de données dans un environnement multi-maîtres.

Dans le cas de mon client, mon entreprise le réduit de 9 serveurs de base de données (Quad Code, 32 Go de RAM, 824 G RAID10) à des serveurs de base de données plus rapides (Dual HexaCore [12 unités CPU], 192 Go de RAM, 1,7 To RAID) de MySQL 5.5 .9 (pour tirer parti des multiples processeurs). En outre, imaginez un pool de mémoire tampon Innodb de 150 Go dans 50 partitions de 3 Go chacune (les pools de mémoire tampon InnoDB multiples sont une nouvelle fonctionnalité de MySQL 5.5). Une plus petite échelle, mais une mise à l'échelle massive, avait fonctionné pour l'infrastructure unique de mon client.

La morale de l'histoire : Augmenter ou réduire n'est pas toujours la solution si vous avez des tables mal conçues. Ce que je veux dire, c’est ce qui suit: si les pages d’index ont une population de clés déséquilibrée pour les index multicolonnes, l’interrogation des clés à partir des parties déséquilibrées des index conduit à une analyse après analyse de la table, ou du moins à des index qui ne sont jamais utilisés du fait d’une requête MySQL exclue. Optimiseur. Il n'y a tout simplement aucun substitut à une conception appropriée.

MySQL crée des bases de données dans des répertoires distincts. Cela dépend donc beaucoup du système d'exploitation sous-jacent et du nombre de dossiers / fichiers qu'il peut gérer. Cela ne devrait pas être un problème avec les systèmes d’exploitation modernes, mais c’est de là que viendra une grande partie du goulot d’étranglement.

Rien ne dit que vous devez héberger différentes versions de la base de données ou de l'application. Qu'y a-t-il de mal à simplement isoler les données en faisant une base de données par client et en ayant une version de la base de données et de l'application? Bien entendu, chaque base de données client devra être clonée à partir d'un modèle de la version de travail actuelle. Du point de vue de la sécurité et de l’isolation des données, je pense que c’est l’idéal.

Le seul inconvénient que je puisse constater est que vous devez mettre à jour manuellement chaque base de données lors de la création d'une nouvelle version. Cela pourrait être facilement automatisé si.