Valeurs définies par l'utilisateur MySQL - EAV vs sharding avec plusieurs tables

Question

Je suis actuellement en développement d'un système multi-locataire qui, en tant que fonctionnalité de base du système, permet à l'utilisateur de définir des types personnalisés. Ainsi, par exemple, ils définiraient un événement, un compte, une commande, un envoi quel qu'il soit. Chaque utilisateur du système aura des définitions différentes pour ce qu'il veut gérer en termes de champs. Ainsi, pour un utilisateur, une commande peut avoir un numéro de commande, un statut et une date d'échéance, alors qu'un autre utilisateur peut avoir 10 champs.

Les développeurs avec lesquels je travaille veulent utiliser EAV pour stocker ces données. Je suis contre cette idée. J'ai lu de nombreux articles sur ce site ainsi que sur l'Internet énumérant les inconvénients de ce modèle anti-design, mais aucun ne mentionne l'approche que je pense prendre. J'essaie de construire cette application de telle sorte qu'elle soit évolutive depuis le début.

Quand je fais le calcul, si j'ai 1000 locataires, avec une moyenne de 5 types chacun (5000 types). Chaque type a 1000 enregistrements par exemple (5.000.000 enregistrements). Chaque enregistrement a en moyenne 5 champs me donne un total de 25 000 000 lignes au plus bas niveau du modèle EAV. Un processus descendant liera également chaque donnée d'utilisateur à une grille jquery, donc la première extraction de ces données et la transposition des données me semblent si coûteuses. Que se passe-t-il quand vous avez 10k locataires ou 50k locataires ... Je comprends que MySQL peut gérer ce genre de chose lorsqu'il est optimisé, mais il me semble que je me tire dans le pied.

Je veux le faire d'une autre manière. Cependant, j'ai un mauvais pressentiment sur ce que je propose car cela va à l'encontre de tout ce que je sais, alors j'aimerais que de vrais experts ayant des connaissances pratiques puissent valider ou critiquer mon approche. Si vous validez, s'il vous plaît dites-moi ce que je dois faire pour le soutenir et le faire fonctionner. Si vous critiquez, s'il vous plaît dites-moi les pièges que j'aborderai à court et à long terme.

Ma proposition. Éclater le système en utilisant le partitionnement de domaine de sorte qu'il y ait un ensemble maximal de locataires dans un fragment particulier. Le catalogue principal référencera quel locataire appartient à quel segment

Pour chaque segment, lorsqu'un utilisateur définit un type, créez une nouvelle table pour contenir ce type. Tenez une table de mappage dans le fragment, qui lie l'utilisateur à ses types définis (tables personnalisées). Cela signifie essentiellement que je vais avoir une poignée de tables de base dans un fragment et 1000 de tables personnalisées. Maintenant, pour moi, le fait d'avoir autant de tables dans une base de données me dit généralement qu'il y a un problème avec le schéma ou que quelque chose a été mal conçu, mais pour ce scénario, je suis juste curieux de savoir s'il est une approche réalisable. Dans mon exemple précédent, cela signifierait que j'ai 5000 tables dans le fragment, avec seulement 1000 lignes chacune. ce qui me semble une meilleure approche que d'utiliser EAV. Basé sur l'utilisateur, vous trouvez le type et vous liez les données à la grille.

Quelques notes à considérer

1. L'architecture mutualisée permet aux utilisateurs d'avoir leurs propres utilisateurs. Donc potentiellement j'ai 1000 abonnés, mais 5000 utilisateurs. Les connexions à la base de données doivent donc être gérées. Vais-je rencontrer des problèmes pour gérer les connexions? Est-ce que je rencontrerai des problèmes liés à la mise en cache de table? Aurai-je des problèmes à nettoyer les tables?

2. Où puis-je rencontrer des problèmes de performance avec cette conception? Je comprends que la base de données master catalouge peut être un goulot d'étranglement, mais la charge sur cette base de données ne sera pas trop lourde.

3. Le développement a déjà commencé, ne me demandez pas de passer à une base de données NoSQL!

Une autre suggestion était de continuer à utiliser EAV mais dans la partition. Que penses tu de cette idée?

S'il vous plaît ne tirez pas de coups de poing! J'ai besoin de tout entendre. Merci d'avance.

Answer 1

Je pense qu'en termes de mise à l'échelle des données, vous constaterez que la gestion de milliers de tables personnalisées relativement petites vaudra mieux que l'utilisation d'EAV. J'ai consulté pour des clients avec plus de 100 000 tables sur une seule instance MySQL. Vous rencontrerez différents problèmes d'évolutivité lorsque vous avez des dizaines de milliers de tables sur une instance, mais si vous avez déjà une architecture qui prend en charge le sharding, vous êtes prêt à subdiviser les utilisateurs de sorte que vous ne le fassiez pas. en avoir trop sur n'importe quelle instance.

Les tables de catalogue sont vraiment bonnes à mettre en cache (par exemple memcached) car le mappage de l'utilisateur sur l'instance de partitionnement change très rarement. Cela réduira la charge sur le catalogue.

Je voudrais également regarder dans le partitionnement de MySQL pour le catalogue, et la table qui mappe les utilisateurs à leurs tables personnalisées. Ainsi que toutes les autres tables communes (non personnalisées). Vous pouvez partitionner n'importe lequel d'entre eux par ID utilisateur et utiliser l'élagage de partition pour que les tables multi-locataires agissent comme des tables beaucoup plus petites.