Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
653 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Plusieurs tables ou une seule grosse dans ce cas?

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[MySQL] Plusieurs tables ou une seule grosse dans ce cas?

n°2328221
PeK
Posté le 26-01-2019 à 13:49:50  profilanswer
 

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 ? :D

mood
Publicité
Posté le 26-01-2019 à 13:49:50  profilanswer
 

n°2328269
rufo
Pas me confondre avec Lycos!
Posté le 27-01-2019 à 16:46:10  profilanswer
 

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. ;)


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2328279
mrbebert
Posté le 27-01-2019 à 19:39:26  profilanswer
 

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 :)

Message cité 1 fois
Message édité par mrbebert le 27-01-2019 à 19:39:46
n°2328282
PeK
Posté le 27-01-2019 à 22:49:24  profilanswer
 

rufo a écrit :

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. ;)


 
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à.  
 
 

mrbebert a écrit :

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 :)


 
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.  
 
 

n°2328285
rufo
Pas me confondre avec Lycos!
Posté le 28-01-2019 à 08:15:37  profilanswer
 

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...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL] Plusieurs tables ou une seule grosse dans ce cas?

 

Sujets relatifs
Plusieurs tableaux mais avec couleurs différentes ?copier coller plusieurs feuilles dans une feuille
Calcul points de plusieurs events et membres[Perl] Utiliser LibXML pour concatener plusieurs fichiers XML
Choix de formation entre plusieurs organismesincrémentation auto vba excel en fonction de plusieurs cellules
Déplacer plusieurs fichier en ajoutant la dateAffichage évènement de plusieurs jours sur un calendrier
[RESOLU] variable contenant plusieurs valeurs possiblesLibreOffice.Base : Dédoublonner : Jointure de 2 tables
Plus de sujets relatifs à : [MySQL] Plusieurs tables ou une seule grosse dans ce cas?


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR