Discussion :

[franckcl]

Bonjour à tous,

J'utilise un WAMP sur WIN10 en NTFS.

J'ai créé une table qui comportent les champs suivants


Le nombre de lignes affiché est de 20 712 471 et plus aucune ligne n'est ajouté;


Depuis PhpMyAdmin, si j'insère une ligne manuellement, je n'ai aucune erreur, il m'indique que l'opération s'est bien passée mais finalement je constate qu'aucune ligne n'est ajoutée.

Depuis PhpMyAdmin, je peux visualiser le début du contenu de la base mais pas la fin, le message "Chargement en cours" reste afficher en permanence et rien ne se passe.

Comme vous pouvez le constater j'utilise un index sur 4 colonnes avec l'option UNIQUE.
Je n'ai pas de colonne AUTO_INC, est ce obligatoire ?

Cette table est destinée à réaliser un data logger. Il y a environ 20 à 100 lignes qui sont créées toutes les secondes et j'aimerai tenir ce rythme pendant au moins 6 mois.
Je suis conscient que cela va faire une très grosse base de données mais pourquoi cette limite à 20 712 471 lignes ?
J'ai vu sur que MySQL était utilisé sur de très grosses bases comme Youtube, donc c'est pour cette raison que je suis parti avec cette base.

Merci pour vos avis.
Franck

[SQLpro]

….
J'ai vu sur que MySQL était utilisé sur de très grosses bases comme Youtube, donc c'est pour cette raison que je suis parti avec cette base.

En lisant des crétineries on se fait des opinions idiotes !

MySQL n'est PAS DU TOUT fait pour gérer de fortes volumétries.

YouTube et cie utilisent deux concepts pour gérer de fortes volumétrie avec MySQL
1) une version customisée de MySQL pour laquelle ils ont fait plusieurs années hommes en R&D
2) une répartition des données sur des milliers de serveurs.

Si vous voulez gérer de la volumétrie dans une seule et même machine, il faut un SGBDR ayant des techniques de stockages interne comme Oracle, MS SQL server ou DB2.

J'ai plusieurs clients qui ont dépassé le milliard de ligne dans une seule et même table dans SQL Server….

A +

[franckcl]

J'ai trouvé d'où venait mon problème, donc je donne la réponse pour partager.
J'en suis maintenant à 192 millions de lignes sur une même table et les temps de réponse sont absolument excellents pour le type de machine qui me sert de banc de test.
Il s'agit d'un vieux PC portable qui a 10 ans (un I7, sous Windows 10, avec 4G de RAM), la taille de la table occupe sur le disque 20Go.
La requete suivante s'effectue en seulement 10ms:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM `tag_values` WHERE hash_config=15135684329552187526 and id_system=1 and id_tag<5 and update_number=249505

Donc pour l'application que je veux en faire, c'est largement suffisant et ce sera encore meilleurs sur la machine définitive qui sera une bête de course.

J'ai tout simplement supprimé l'index unique qui était sur 4 colonnes et je l'ai remplacé par 4 index simple (1 par colonne). Je gère les restrictions au niveau du soft qui rempli la table.
J'ai aussi ajouté une colonne d'index primaire auto incrémental.

Franck

[SQLpro]

...
J'ai tout simplement supprimé l'index unique qui était sur 4 colonnes et je l'ai remplacé par 4 index simple (1 par colonne). Je gère les restrictions au niveau du soft qui rempli la table.
J'ai aussi ajouté une colonne d'index primaire auto incrémental.

Franck

Ce n'est pas du tout la même chose d'un point de vu sémantique ! Imaginez ce qui va se passer si vous avez des doublons… !!!!

A +

[Artemus24]

Salut à tous.

Le nombre de lignes affiché est de 20 712 471 et plus aucune ligne n'est ajouté;

Je constate que votre index unique est constitué des colonnes suivantes :
--> hash_config
--> id_system
--> id_tag
--> update_number.

Quel est l'intérêt de procéder ainsi ? Je vois que c'est pour optimiser une requête en terme de performance.

En l'état des informations fournis, nous ne pouvons répondre sur pourquoi votre clef primaire constitué de quatre colonnes est l'origine de votre problème.

Je confirme les propos de SQLPRO :
1) MySql n'est pas fait pour une grosse volumétrie. Dans ce cas, passez à Microsoft SQL Server qui est mieux adapter à ce genre de problème.
2) si vous supprimez votre index unique vous risquez d'avoir des problèmes de doublons.

Votre table est mal construite.
a) Vous devez créer une clef primaire basée sur un auto incrément.

b) je ne comprends pas l'intérêt de la colonne hash_config.
Soit elle est informationnelle ou si vous préférez à titre indicatif, soit elle joue un rôle particulier dans le pointage de vos données.
Elle peut servir de clef secondaire, dans le sens d'une clef candidate en tant que clef primaire.

c) Les colonnes id_system et id_tag doivent être des clefs étrangères, pointant sur les tables respectives.

d) la colonne update_number est un numéro séquentiel qui sert à dissocier les doublons sur les trois premières colonnes de votre index unique.
Cela peut se gérer automatiquement dans un déclencheur.
Sinon, il faudrait définir le rôle joué par cette colonne.

J'ai tout simplement supprimé l'index unique qui était sur 4 colonnes et je l'ai remplacé par 4 index simple (1 par colonne).

Ce que vous faites ne sert à rien, sinon à alourdir inutilement les performances de votre base de données.
MySql ne sait gérer qu'un seul index à la fois.
Utilisez EXPLAIN pour connaitre l'index utilisé dans votre requête.

Si vous créez un seul index sur hash_config, c'est largement suffisant en terme de performance pour accéder à un tout petit groupe de lignes.
C'est sur des tests de performances que l'on se rend compte de la pertinence de ce groupe de lignes.
De combien est constitué au maximum ce groupe de lignes ?

J'ai aussi ajouté une colonne d'index primaire auto incrémental.

C'est une bonne idée à la condition que cela vous serve à quelque chose dans vos traitements.

@+

[escartefigue]

En plus, je vois que vous êtes en MyISAM qui ne gère pas l'intégrité référentielle

[CinePhil]

Il y a plus de 10 ans, j'ai créé à l'INRA une BDD MySQL sur un portable de l'époque (ensuite exportée sur un petit serveur de l'époque) à partir de 4 années de la base de données nationale d'identification des bovins. Une de mes tables avait 63 millions de lignes et plusieurs autres en avaient plusieurs millions. Toutes mes requêtes, parfois complexes, à fins de statistiques pour un thésard, s'exécutaient au maximum en moins de 2 secondes.

Donc votre limite de 20 millions de lignes n'en est pas une. Peut-être est-ce une limite donnée par un paramètre de config dans MySQL ou dans phpMyAdmin ?