MyIsam

Version imprimable

02/01/2012, 13h37
flagodzki

Bonne pratique InnoDb/trigger/MyIsam

Bonjour à tous,

je me pose des questions sur la bonne pratique à employé dans le cas ou j'ai une table qui est fortement sollicité en lecture et en écriture.

J'ai un site web avec une table de "News" actuellement en "MyIsam" dans laquelle de nombreux utilisateurs peuvent ajouter,editer,supprimer des enregistrements (via le backoffice du site), de même cette table est elle même très consulté en lecture.

Après avoir lu pas mal de doc sur le sujet étant donné qu'en écriture toute la table MyIsam étant locké pour chaque écriture dans ce cas il était conseillé d'utiliser InnoDB (car lock uniquement les enregistrements)

Par conséquent, je pensais passer ma table "News" en InnoDB et créer une seconde table destiné uniquement à la lecture en "MyIsam" avec une réplication par Trigger.

Cependant ne vais-je donc pas reporter mon problème ? car à chaque sollicitation en écriture de ma table "News" (en InnoDB) un trigger effectuera une écriture sur mon autre table (MyIsam).

N'y a t'il pas un moyen de temporiser mon écriture sur ma table "MyIsam" et de donnée une priorité à la lecture ?

Si quelqu'un à une idée sur une solution intéressante je suis preneur.

merci d'avance
02/01/2012, 13h51
CinePhil

On peut avoir la structure de la table news ?

S'il vous plait,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CREATE TABLE IF NOT EXISTS `news` (
  `Ref` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `DateInsert` datetime DEFAULT NULL,
  `Sujet` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `SujetNL` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `Contenu` text COLLATE utf8_unicode_ci,
  `ContenuNL` text COLLATE utf8_unicode_ci,
  `Path` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `Actif` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `Ref_activite_p` smallint(5) unsigned NOT NULL,
  `Ref_Categorie` smallint(5) unsigned NOT NULL,
  `Ref_SousCategorie` smallint(5) unsigned NOT NULL,
  `Etat` tinyint(3) unsigned NOT NULL,
  `Duree` smallint(5) unsigned NOT NULL,    
  `Ref_Customer` mediumint(8) unsigned DEFAULT NULL,
  `Ref_Account` mediumint(8) unsigned NOT NULL,
  `Hit` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `APS` mediumint(8) unsigned NOT NULL DEFAULT '0',  
  PRIMARY KEY (`Ref`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=83 ;

02/01/2012, 19h34
CinePhil

Comment est interrogée cette table ?

J'imagine qu'elle peut l'être par activité, catégorie, sous-catégorie...

Il faudrait indexer les colonnes qui sont utilisées dans les jointures avec les autres tables (ce qu'on appelle les clés étrangères, même si elles ne sont pas fonctionnelles avec le moteur MyIsam) et les colonnes qui sont le plus souvent dans les clauses WHERE des requêtes, sous réserve pour ces dernières que l'idnex soit significatif, c'est à dire qu'il donne un nombre de valeurs différentes suffisant pour que le SGBD utilise l'index.

Les requêtes devrait déjà être beaucoup plus rapides avec cette simple opération d'indexation.
02/01/2012, 20h03
flagodzki

Merci du conseil, Le site n'est pas encore en production et je n'ai pas encore optimiser les index. c'est dans un soucis d'analyse que je me posais la question décrite plus haut étant donné que le moteur MyIsam bloque toute la table en écriture et que Innodb est bcp plus lent en lecture...
02/01/2012, 20h10
CinePhil

Avec des tables correctement indexées, tu à le temps de voir venir avant de constater des lenteurs avec InnoDB !
02/01/2012, 20h14
flagodzki

Vous pensez que je doit passer ma table en Innodb ou pas nécessairement ?

ca ne pose pas de problème d'avoir des tables qui fonctionnent avec des moteurs différents ?
02/01/2012, 20h19
CinePhil

Pour des raisons de rigueur (utilisation des clés étrangères), je préfère InnoDB. Je n'ai à ce jour jamais constaté de lenteurs significatives avec.

Le seul cas où je pourrais être contraint d'utiliser MyISAM est si je dois faire de la recherche FULL TEXT. Dans ce cas, il est possible de scinder les données entre une table InnoDB et une table MyISAM contenant les seules colonnes faisant l'objet des recherches FULL TEXT.

Dans ton cas, ce pourrait être les colonnes sujet et contenu.
05/01/2012, 13h29
lechat1712

une piste ?

je suis un peu dans la meme situation ... besoin d'une recherche de type fulltext mais on me deconseille myisam

on m'a oriente vers l'installation d'un moteur de recherche comme sphinx ou lucene qui permet d'avoir des performances superieures au fulltext et de conserver les avantages d'innoDB mais a cote de ca, je surnage un peu dans la doc de sphinx

si tu arrives a creuser un peu plus loin le sujet ou si des experts ont des infos positives ou negatives sur cette solution ...

a bientot
24/01/2012, 11h18
flagodzki

je reviens sur ce sujet. Etant donné que mes requêtes deviennent de plus en plus complexe, je pense de plus en plus à répliquer dans une table MyIsam certaines données pour accélérer mes requêtes lors de la lecture en donnant une priorité plus haute à la lecture.

j'ai trouver ce sujet pour donner des priorités différents en lecture et en écriture sur la table : http://dev.mysql.com/doc/refman/5.0/...e-locking.html

Est-ce que quelqu'un aurait une meilleur suggestion ?