InnoDB + Transactions ou MyIsam

Bonjour,

J'ai un application qui insert environ 10 000 enregistrements par jours. Toutes les tables de cette base de donnés fonctionnent avec le moteur InnoDB.

Ce logiciel est en fonction depuis un certain temps et jusqu'ici la plus grosse table contient plus de 4 millions d'enregistrements, ce qui à pour effet d'avoir un assez gros impact sur les performances :roll:.

Malgré tout, j'ai judicieusement créé mes indexes de façon à ce que les performances en lecture soit prioritaires.

Je me demande si je n'aurais pas mieux fait de tout bâtir sous MyIsam ?
J'avais choisis InnoDB parce que j'ai lu que la sécurité des données est plus fiable et que les transactions y sont possibles.

Pour la sécurité, je me dis qu'au pire on pourrait perdre une journée de données (backup journalier) mais nous pourrions récupérer ces données perdues puisqu'elles provienent de fichiers et que ces fichiers sont conserver sur un autre poste.

Pour ce qui est des transactions, quand DOIT-ON les utiliser ?
Si par exemple un nouvel utilisateur web est créé :

- Insertion l'utulisateur dans la table Users
- Insertion des rôles de cet utilisateur dans la table UsersRoles
- ...
- Etc.

Dans ce cas-ci, si un plantage survent lors d'une de ces lignes, l'utilisateur ne peu être créé à MOITIÉ ! Donc les enregistrement relatifs ne doivent pas être gardées... Est-ce un bon exemple pour l'utilisation de transaction ?

Si les transactions ne me sont pas vraiment utiles, alors je modifierais mes table sous MyIsam pour récupérer les performances en lecture que j'ai besion.

Merci à tous.

Salut,

InnoDB et les transactions sont là pour garantir la robustesse de la base dans un contexte OLTP, avec beaucoup d'insertions concurrentes. Ca a l'air d'être ton cas et je ne pense pas que tu y gagnes en termes de fiabilité en passant à MyISAM.
La rapidité est un objectif louable mais si c'est pour que le serveur merdoie ou que les données se retrouvent dans un état incohérent régulièrement, il y a mieux à faire ;)

Tu as peut-être aussi des données "obsolètes" que tu pourrais archiver, à ce moment-là du MyISAM ou Archive (MySQL 5.0) suffiraient effectivement...

Citation:

---

Envoyé par Maximilian

Tu as peut-être aussi des données "obsolètes" que tu pourrais archiver, à ce moment-là du MyISAM ou Archive (MySQL 5.0) suffiraient effectivement...

---

Que veux-tu dire par là ?

J'ai longuement chercher comment faire un système de partition sur MySQL (un peu comme sur Oracle). Les données sont souvent consultées pour le mois courrant mais après elles sont plus considérées comme des archives. Bien qu'elles doivent être consultablent quand même.

Par la même occasion, j'ai des données qui proviennent de plusieurs stations et celle-ci sont regroupées par date. Donc ma clé primaire est basée sur la station et la date. J'ai établie mon index sur la date car c'est sur celle-ci que les SELECT exécutés. Est-ce que c'est bien un index sur un champs DateTime ?

Citation:

---

Envoyé par Erakis

Que veux-tu dire par là ?

---

Par archives je voulais dire données qui ne sont plus modifiées mais seulement consultées. Si tu veux absolument utiliser du MyISAM autant le faire sur ces données-là.

Citation:

---

J'ai longuement chercher comment faire un système de partition sur MySQL (un peu comme sur Oracle).

---

MySQL 5.1 (alpha release) le propose.

Citation:

---

Par la même occasion, j'ai des données qui proviennent de plusieurs stations et celle-ci sont regroupées par date. Donc ma clé primaire est basée sur la station et la date. J'ai établie mon index sur la date car c'est sur celle-ci que les SELECT exécutés. Est-ce que c'est bien un index sur un champs DateTime ?

---

Oui, tout autant que sur un varchar par exemple.

Merci beaucoup.

C'es toujours agréable de se faire répondre par une personne aussi expérimenté dans le domaine :D.

De rien. Tiens-nous au courant si jamais tu réalises quand même des tests ou autres ;)