Une grande base de données MySQL pour plusieurs clients

Question

N.B. Ce n'est pas une autre question "Une grande base de données ou plusieurs petites bases de données". En utilisant une grande base de données MySQL pour plusieurs clients (même structure, etc), avec une colonne user pour séparer les clients, est-il possible de limiter l'accès à la table pour l'utilisateur avec la colonne correspondante user`?

Je ne connais pas très bien SQL Server de Microsoft, mais j'ai lu quelque chose à propos de "l'architecture de données multi-locataires" qui semblait offrir cela.

Est-ce que MySQL a quelque chose de similaire?

Answer 1

MySQL dispose de privilèges au niveau de la table et de la colonne, mais pas de droits au niveau de la ligne. La chose la plus proche serait de définir une VUE à travers laquelle un utilisateur accède à la table. La vue a le privilège d'accéder à la table de base, et chaque utilisateur a des privilèges pour accéder à la vue.

Définissez la vue pour restreindre l'accès à l'utilisateur actuel.

mysql> create table base (user varchar(16), x int); 
mysql> insert into base values ('root@localhost', 123), ('bill@localhost', 456); 
mysql> create view v as select * from base where user = USER() with check option; 
mysql> select * from v; 
+----------------+------+ 
| user   | x | 
+----------------+------+ 
| root@localhost | 123 | 
+----------------+------+ 

Answer 2

Je recommande contre avoir une grande base de données pour tous vos clients pour de multiples raisons:

1. J'ai travaillé à une start-up où l'instance AWS pour l'un de nos DB vient de donner suite (sans faute de les notres). Disons que c'était une journée agitée pour tout le monde au bureau. Si cela arrive à votre seule base de données, comment allez-vous assurer la satisfaction du client? Comment allez-vous maintenir un système robuste? Il y a un dicton que chez google, un serveur va toutes les 2 secondes. Bien que cela ne se produise pas lorsque vous démarrez, sachez que vous n'êtes pas à l'abri de l'échec de vos serveurs. Sharding votre DB dans plusieurs instances est un bon moyen de couverture contre un échec majeur.
2. Si vous avez de nombreuses transactions, votre pool de threads sera toujours verrouillé. Vous ne voulez pas cela parce que cela va augmenter le temps nécessaire pour effectuer des opérations CRUD sur votre base de données, ce qui à son tour va affecter la satisfaction du client.

Une meilleure mult-locataire archticture vous voulez avoir est:

1. Have 1 maître DB pour chaque client (peut-être tous les 2 clients au début), puis des esclaves pour chaque DB maître que vous avez . Maintenant, vous pouvez effectuer toutes vos écritures sur les esclaves et effectuer toutes vos lectures sur le maître. Tant que vous conservez la synchronisation de vos bases de données, c'est le meilleur moyen de garantir la disponibilité de votre pool de threads et d'effectuer rapidement toutes les transactions.

Voici un excellent article intitulé "High Availability, Load Balancing, and Replication", qui vous donnera une bonne introduction à la construction d'un système multi-locataire robuste. Je recommande également de lire les articles sur High Scalability

S'il vous plaît laissez-moi savoir si vous avez des questions!