Bonjour
 
Je suis en train de designer un logiciel qui va s'appuyer sur une base SQL.  
Connaissant un tout petit peu MySQL, je pensais partir sur cette solution, ou sur son clone MariaDB.  
Maintenant, je ne suis pas du tout expert en MySQL et du coup je me pose des questions structurantes.  
 
Pour schématiser: chaque utilisateur du logiciel à son propre espace de travail.  
Tous les espaces de travail sont indépendants, mais conserve exactement la même structure.  
Il s'agit d'un ensemble d'enregistrements avec tous la même structure.  
 
Sachant que :  
- d'un user à l'autre:  
 - on peut varier de 100 à 100.000.000 d'enregistrements
 - on peut varier de 1 opération / jour à - estimation grosse maille - 100.000
- on peut estimer qu'il y aura 10% des utilisateurs actifs au même moment  
- tous les utilisateurs actifs sont indépendants, et ne doivent pas trop se perturber et se ralentir mutuellement lors des opérations d'écritures, qui seront à 1/3 d'update, 1/3 d'insert, 1/3 de delete en gros
- le profil typique sera soit très chargé en lecture, soit très chargé en écriture. Une répartition du genre 90/10 ou 10/90, mais pas de 50/50
- l'ensemble de toutes les data ne tient évidement pas en RAM et de très très loin ... Estimation de la base à 1To de data, hors index et autre.  
 
 
Typiquement, je me pose donc le choix:  
- faire une table indépendante pour chaque user
- faire une grosse table pour tous les user, avec les mêmes colonnes que la table ci-dessus + une colonne genre "id_user", qui interviendrait dans la PRIMARY KEY.
 
 
Je pensais au points suivants:
- Cas de la lecture et utilisation de la RAM pour tout ce qui est cache  
Je dirais "avantage grosse table".  
En effet, j'imagine que dans le cas des petites tables, chaque petite table prendrait un minimum de ressources... et dans le cas des petites tables non utilisées, ses ressources sont gâchées.  
 
- vitesse d'écriture  
La, je ne sais pas trop comment fonctionne MySQL pour les écritures sur disques.  
Mais déjà, je me dis que le "INSERT" va poser problème si il y en a beaucoup en // sur une seule et même grosse table.  
Ensuite, en terme d'IO disque, je me dis que là, c'est plusieurs petites tables qui vont être problématique.  
Une seule grosse table <=> 1 gros fichier à sync lors d'un commit <=> plus facile que plusieurs petites tables indépendantes que nécessiteront autant de fichiers...
A moins que je désactive le fonctionnalité qui fait des fichiers / table (innodb_file_per_table) ..
 
Quelqu'un à un avis ?

Si t'as beaucoup de users et beaucoup de données identiques au niveau structure, tu peux regarder du côté des BD noSql de type "document" (MongoDB par ex).
Sinon, si tu veux rester sur du Mysql ou similaire, à mon sens, clairement, reste sur un ensemble de tables communes à tous les users. Faire une table par user serait une vraie galère pour faire des requêtes transversales aux users. Du coup, si ta table ou tes tables sont très grosses, utilises le système de partition qui existe nativement. C'est comme le découpage en plusieurs tables plus petites que tu envisageas mais sans les inconvénients puisque c'est le SGBD qui va se débrouiller pour la répartition des données.

Ce serait compliqué de faire un script qui simule un utilisateur, plutôt en lecture ou plutôt en écriture ?
Au vu de ton explication, ça ne me semble pas très difficile de faire un test de performance, avec une table ou avec plusieurs

 
Je vais regarder MongoDB... je dois avouer que à part le nom, je ne connais pas du tout.  
Je n'ai en pratique aucune raison d'avoir des requêtes transversales à tous les users. En tout cas, dans toute la conception du projet aujourd'hui, je n'en ai jamais eu besoin.  
Les users sont vraiment indépendants de ce coté là.  
 
 

 
C'est ce que je suis en train de me dire.  
C'est sur que cela oblige à réécrire toutes les requêtes et certaines parties du programme de passer de l'un à l'autre, mais au final, c'est pas si énorme comme différence.  
Et pour le coup, faire un script qui simule, je peux le faire pour environ 50% des profiles d'accès je pense. Et ça serait les plus gros.  
 
 

Les requêtes transversales, ça peut être à des fins de stats, par ex. Nb d'accès moyen, espace ou nb d'enregistrements min/moy/max par user, user le plus ancien ou le plus récent...