Diviser la base de données mysql par client

Question

Je travaille sur une base de données relativement petite. Il a un total de 67 tables, avec un peu plus d'un million de dossiers. C'est environ 254 MB. L'application qui fonctionne avec elle fonctionne depuis environ 5 ans et la quantité d'utilisation a doublé chaque année. Cette année, nous prévoyons tripler ce qui va presque doubler la base de données en taille une saison. Mes questions sont, est-ce une mauvaise idée de diviser la base de données en plusieurs bases de données. Supposons que nous ayons 300 clients, il y aurait alors 300 bases de données individuelles contenant les 67 tables mais seulement des données relatives à ce client. Il n'y a pas beaucoup de raisons pour que les données soient ensemble en plus pour les statistiques internes qui peuvent être effectuées sur un serveur différent. Nous ne devrions pas devenir plus grand que 10.000 clients dans sa vie.

Les problèmes que je vois que cette configuration est quand nous avons besoin d'apporter des modifications au schéma « base de données maître », il faudrait reproduire le changement dans l'ensemble des « bases de données esclaves »

réplication aussi serait un défi quand un nouveau client est ajouté.

L'application au niveau du code est pratiquement configurée pour ce type d'installation.

Y at-il quelque chose qui me manque? Est-ce une idée terrible?

La base de données a été créée à la hâte (pas par moi) sans aucune pensée d'avenir, et maintenant c'est ma responsabilité.

Il y a beaucoup à faire en ce qui concerne la normalisation, l'audit de type de champ, l'optimisation sql, l'indexation et le réglage du serveur. Tous commentaires serait grandement apprécié.

Answer 1

La question que j'ai est de savoir comment accéder à la base de données? Y a-t-il une application installée par client? Si c'est le cas, la séparation des bases de données peut vous faire gagner du temps lors de la mise à niveau de l'application (puisque vous n'avez besoin de mettre à jour la base de données que lorsque vous mettez à jour l'application). Si elles sont accessibles par une application, gardez-les ensemble.

Mais il y a d'autres considérations à l'esprit. Vous mentionnez que la taille actuelle est de 1 million de lignes @ 256 MB. Cela devrait être très facilement à la portée d'un serveur de marchandises. Donc, si vous vous attendez à une croissance du pire des cas 5 fois par an, vous parlez de 5 millions de lignes cette année, 25 prochaines, 125 la troisième, 625 la quatrième et 3125 millions la cinquième. Même les 3 milliards de lignes (en fonction de l'utilisation exacte et des types de requêtes) ne sont pas si difficiles à gérer pour MySQL (Toujours dans la limite supérieure d'un serveur de base) ...

De plus, si vous commencez à vous heurter problèmes, vous pouvez toujours partition chaque (ou seulement les tables principales) sur la clé client ... Il est automatiquement géré par MySQL pour vous, donc vous n'avez pas le cauchemar de maintenance de les gérer vous-même ...

Answer 2

Actuellement vous avez un quart d'un gig de données. Vous envisagez de doubler (un demi-concert) cette année. Est-ce 1997? Non, il est 2010 et les gens ont des gigaoctets de données sur leurs téléphones. Donc, la question est, quel problème tentez-vous de résoudre? Il ne peut pas être stockage, parce que c'est une quantité triviale de données. Si c'est la performance, alors je pense que la division en plusieurs bases de données est susceptible d'empirer les choses et d'envisager un serveur par base de données. Il y a un argument en faveur de bases de données séparées du point de vue de la sécurité, mais il existe différentes manières de répondre à ces préoccupations.

Avez-vous des problèmes avec votre environnement actuel? Ou au moins les tendances qui suggèrent que vous pourriez avoir des problèmes dans douze mois? Si non, alors asseyez-vous bien.Si oui, formulez-les clairement et déterminez ensuite comment 300 bases de données résoudront ces problèmes, et si elles en valent la peine inévitable. Recalibrez ensuite ce chagrin pour représenter 10000 utilisateurs et posez à nouveau la question.

Il peut y avoir quelques questions auxquelles la meilleure réponse est "dix mille bases de données" mais pas très nombreuses.

---

"Notre plus gros client ajoute environ 12000 dossiers par an."

En d'autres mots sur un enregistrement toutes les dix minutes de travail (en supposant une journée de huit heures). Cela ne semble pas être une grosse charge d'écriture.

« L'idée est plutôt qu'un client aller à travers toutes les données, il accède simplement leurs données. »

Mais ce n'est pas beaucoup de données, et certainement rien qu'une stratégie d'indexation décente ne peut pas résoudre.

Je ne comprends toujours pas si vous avez un vrai problème réel maintenant ou vous pensez juste à quelque chose qui pourrait être un problème à un moment donné dans le futur.

Answer 3

Modifiez le schéma actuel pour admettre plusieurs clients et si, sur le chemin, votre performance souffre lorsque vous atteignez le nième client (et que l'optimisation SELECT n'aide pas), vous pouvez ajouter de nouveaux serveurs. Dans notre cas, nous divisons les données par «sites» afin qu'un utilisateur ne puisse pas accéder aux données qui ne sont pas sur leur site.

Answer 4

Vous avez vos mains pleines avec la « normalisation, vérification de type de champ, l'optimisation SQL, l'indexation et l'optimisation du serveur »

Il n'y a aucune raison de séparer que dans 300 bases de données. Et beaucoup de bonnes raisons de ne pas le faire, que vous avez articulées. Tant que CustomerId sépare clairement les données du Client via la base de données, tout va bien.

Alors travaillez sur ce que vous avez à faire, et ne vous donnez pas un travail plus complètement inutile. Lorsque la taille de la base de données et la vitesse médiocre l'exigent, passez à une plate-forme SQL réelle.

Answer 5

Regardons SAP ERP. Il est potentiellement capable de contenir des milliers de clients et des milliards de recodrs. C'est le système de pouvoir relly. Et toutes les tables (à l'exception des tables système) ont un champ "MANDT" qui spécifie le client. Offcource SAP fonctionne généralement avec ORACLE mais dans votre cas, ce n'est pas suffisant en raison d'une petite partie des données.
Donc, selon SAP hystory succès et les opinions aimables sur MySQL comme bon SGBD, je peux conclure que vous ne devriez pas glisser la DB parmi les clients. Cela ne donnerait pas beaucoup