Forum Programmation.SQL mySQL Taille des tables et perf

Posté par Mais qui suis-je ? :) le 04 août 2008 à 18:40.

Étiquettes : aucune

août

2008

Bonjours a tous
Voilà mon problème est assez simple
J'ai un appareil qui prend une mesure par seconde ( Pour simplifier on va dire que j'ai comme info timestamp,valeur de la mesure, 4-5 colonnes de statuts de l'instrument), J'ai pratiquement 2 ans de donnes dans des fichiers ASCII et je voudrais les passer dans une base mySQL.
A priori 90% des requêtes se feront par rapport au timestamp, qui sera donc indexé, il n'est pas prévu de comparer ces résultats avec d'autres table en tout cas pour l'instant
La question est toute simple.
En terme de perf est ce que je gagne a travailler dans plusieurs table ( par exemple une table par mois soit tout de même 2600000 Entrées si tout se passe bien).
Ou bien est ce que mySQL ne voit pas la différence avec une mega table (Sachant que la gestion du changement de table à un cout aussi)
Faire une VIEW afin d'avoir une seule requette a formulé est il intéressant ?

Je précise que le serveur mySQL tourne sur un serveur généraliste ( et que les autres utilisateurs n'apprécierons pas si ils sont bloqués par la database) est ce envisageable de travailler sur de grosse table sans avoir un serveur dedié SQL ?

Merci

# Optimisation manuelle

Posté par Kerro le 04 août 2008 à 22:52. Évalué à 5.

Il est toujours plus efficace de le laisser gérer les données comme il le souhaite (sauf si le gestionnaire de bases de données est mal conçu). Tout dans une seule table sera au moins aussi efficace que de gérer toi-même des optimisations.

Là où tu peux intervenir, c'est dans le choix du SGDB, dans le choix de l'emplacement des fichiers, le choix de "quelle info dans quelle table" etc. Par exemple des tables très souvent utilisées en même temps peuvent être situées sur des disques différents. Ou une base utilisée majoritairement en lecture peut être mise sur du RAID 1 avec 4 disques. Enfin bon, ça commence à être du ressort de l'extrême.
# MySQL?

Posté par mac le 05 août 2008 à 01:07. Évalué à 3.

On a souvent tendance à penser que MySQL est la seule et la meilleur solution pour traiter beaucoup de données, mais...

- Tes données ne sont apparement pas relationnelles
- Tu as potentiellement besoin de les insérer en temps réel
- Leur structure est très simple

As-tu *vraiment* besoin d'une base de données SQL? (il est clair que je ne connais pas le type de requêtes que tu fais).

Si tu penses que MySQL est la bonne solution, tu peux jeter un oeil sur le partitionnement de données (http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.ht(...) - (MySQL >= 5.1), qui devrait répondre à ton soucis de saucisonnage.
- [^] # Re: MySQL?
  
  Posté par Nicolas Boulay (site web personnel) le 05 août 2008 à 15:41. Évalué à 2.
  
  ça existe encore des base de données hiérarchique ? Dbase c'est de l'ibm non ? Je ne sais plus si c'est ouvert.
  
  Les bases de données hiérarchiques ont de problèmes pour faire des requêtes croisé mais on des performances supérieurs d'un ordre de grandeur sur les cas "normaux".
  
  (ce qui a fait dire par des vieux de le vielle, que les bases de données relationnel ont trouvé le moyen de traiter les cas normaux aussi lentement que les cas spéciaux...:)
  "La première sécurité est la liberté"
- [^] # Re: MySQL?
  
  Posté par Mais qui suis-je ? :) le 05 août 2008 à 16:24. Évalué à 2.
  
  Pour te répondre, mon besoin principal sera de sortir la valeur du champ electrique dans une période donnée. ( L'instrument mesure le champ électrique).
  donc des requettes de type SELECT `Field` WHERE ` Timestamp` BETWEEN...
  Des fichiers ASCII sont me semble t'il un peu trop limité pour ça.
  
  Après, je sais pas si passer par un autre type de stockage des données ( hierarchique ?) va vraiement apporter un gain énorme par rapport à une base mySQL. Ici le choix de mySQL est motivé par des raisons purement extérieure
  -Il y a déjà une base mySQL installée sur le serveur en question
  -Libre (donc grat^W inclus dans la licence suse Novell de la machine et facile à installer)
  -Commun donc première base à laquelle on pense, mais aussi à peu près tout de compatible avec.
  - [^] # Re: MySQL?
    
    Posté par mac le 05 août 2008 à 16:38. Évalué à 1.
    
    Si tu as des fichiers texte, un peu de temps et un peu de talent de développeur, il te serait facile de mettre en place un programme qui serait plusieurs fois plus rapides que MySQL sur ce genre de requêtes...
    
    Sinon, MySQL devrait être "suffisament bon" - fais quand même attention aux LOCKs qui peuvent se produire - tes INSERT peuvent dans certains cas prendre plusieurs secondes (typiquement pendant un backup de la base, mais il y a d'autres possibilités).
    
    Et si tu ne veux JAMAIS perdre aucune donnée, n'oublie pas que MySQL ne devras JAMAIS s'arrêter ;)
- [^] # Re: MySQL?
  
  Posté par PLuG le 07 août 2008 à 02:59. Évalué à 1.
  
  J'abonde, au dela des problèmes de perf, je suppose qu'il va falloir purger les données trop anciennes au bout d'un certain temps (ou alors la table ne va faire que grossir ...).
  Il faut donc prévoir la suppression, et un partitionnement par année ou mois semble etre le genre de solutions utilisées dans ces cas la.
  Sinon on peut le faire avec une vue et des tables mensuelles mais c'est ce qu'utilisent les dba quand la DB ne supporte pas le partitionnement ... (IBM DB2 pendant longtemps par exemple).
# SQLite

Posté par alouali (site web personnel) le 06 août 2008 à 18:40. Évalué à 2.

Pour transformer un gros fichier texte en base de données et ne pas se prendre la tête à faire soit même les optimisations, SQLite peut être une bonne solution.

Tu n'as pas besoin de serveur, tu peux faire tous les essais que tu veux sur ton PC local, et en mono-utilisateur il n'y a rien de plus performant. Ça peut être bien pour faire des essais avant de migrer vers une base en client / serveur.

En tout cas c'est une solution que j'ai utilisé avec bonheur, et tes 63 millions d'enregistrements devraient être gérables sans difficulté.

Juste un rappel : il n'y a pas de INSERT MULTIPLE pour remplir ta table (ça a peut être changé depuis), l'idée est donc d'en faire plein dans un BEGIN / COMMIT, sinon ça va prendre des jours pour remplir ta base puisque à chaque INSERT il va tout transférer sur le disque.

Bref quelque chose comme ça :

BEGIN;
INSERT INTO grossTable ....
INSERT INTO grossTable ....
INSERT INTO grossTable ....
INSERT INTO grossTable ....
...
..
COMMIT;

L'avantage en phase de test est que tout est dans un seul fichier que tu peux facilement tout détruire et recommencer.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.