Discussion :

[boteha]

Bonjour,

OVH me suggère :

Après vérifications, les administrateurs m'ont indiqués que si vous passez les tables de vos bases de données de FULLTEXT à BTREE, le problème que vous rencontrez ne devrait plus être présent.

Qu'en pensez-vous ?

[ericd69]

un index fulltext est un index spécial sur des vecteurs de texte (des expressions de comparaison, un peu comme les regexp) et un fichier de "mots stop" (ceux qui sont ignorés)... les valeurs sont donc "vectorisées" et ce qui est indexé c'est la ligne par rapport à chaque vecteur trouvé
un index btree (arbre binaire ou n-aire) est en fait la forme classique des index, ils sont basés sur l'indexation de valeurs de colonnes intégrales (si tu mets un index sur du texte, tu indexes le texte complet, du moins jusqu'à la limite configurée dans my.ini, c'est -à-dire 1024 caractères maximum par défaut)

la syntaxe de recherche fulltext n'est accélérée qu'avec un index... fulltext, à priori un index btree ne sera jamais utilisé, fais un explain sur une recherche pour voir (nomme toujours tes index et contraintes pour mieux les identifier en débogage et optimisation)

[boteha]

Bonjour,

Merci de ta réponse rapide.
A vrai dire je ne comprends pas bien ta réponse, je ne suis pas expert en matière d'index.

Plus simplement la suggestion d'OVH te semble-t-elle valable et non risquée ?
Non pénalisante en temps de réponse ? Les requêtes actuelles avec index FULLTEXT sont très rapides.

Avec un index btree, les "mots" de 1 ou 2 lettres sont-ils pris en compte ?
En quel cas il faudrait les éliminer au niveau du scriot PHP qui prépare la requête.

[ericd69]

oui mais tu utilises des index fulltext je suppose, même si pas configurés comme tu veux...

valable non je ne pense pas puisque qu'un index "btree plain text" n'a rien à voir avec un index "fulltext"... donc niveau optimisation de recherche... rien je pense...
sans risque oui... sans conséquences sur les performances d'insertion/suppression/update, ça c'est une autre histoire... surtout sur des grosses tables...

si tu n'as pas compris ce que j'ai dit avant, je te conseille de regarder des cours sur les avantages/inconvénients des index selon leur types...

[boteha]

Encore merci pour ton suivi.

Je vais creuser un peu.

[Artemus24]

Salut à tous.

A vrai dire je ne comprends pas bien ta réponse, je ne suis pas expert en matière d'index.

La réponse faite par OVH, est de ne pas utiliser le "FULL TEXT SEARCH" mais d'utiliser les index classiques.
C'est un peu trop facile de dire cela !

ericd69 explique la différence entre ces deux types d'index.

Plus simplement la suggestion d'OVH te semble-t-elle valable et non risquée ?

C'est une solution de remplacement, mais non performante.

Les requêtes actuelles avec index FULLTEXT sont très rapides.

Car le FTS est adapté à ce genre de recherche.
Inversement avec les index classiques, la performance ne sera pas du tout au rendez-vous.
Pire, si tu fais une recherche multicolonne, car cette solution (index classique) n'est pas adapté à ce genre de recherche.

Avec un index btree, les "mots" de 1 ou 2 lettres sont-ils pris en compte ?

Oui car ces mots seront présents dans la ou les colonnes que tu veux indexer.

En quel cas il faudrait les éliminer au niveau du script PHP qui prépare la requête.

Tu ne peux pas les éliminer et c'est ça le problème.

@+

[boteha]

Bonjour,

Merci de tes précisions.

Je vais tenter une réclamation auprès du service commercial d'OVH.

S'il n'est pas possible d'accéder au fichier de config qu'ils arrêtent de parler de SQL "privé".

[boteha]

Bonjour,

Pour info, après 10 jours d'échanges avec le support OVH, une tonne de mails, plusieurs appels, ils ont fini par me mettre ft_min_word_len à 3 sur mon SQL "privé".

J'ai fait un REPAIR TABLE et les requêtes marchent de nouveau bien, jusqu'à la prochaine maintenance d'OVH je suppose...

Je me pose la question de passer en VPS.
Il faudrait trouver un technicien freelance capable de bien paramétrer la chose et d'assurer un support en cas de problème, tout en restant chez OVH.
Avez-vous des adresses ?

[Artemus24]

Salut boteha.

Par défaut, "ft_min_word_len" est à 4.
--> http://dev.mysql.com/doc/refman/5.7/...t_min_word_len
--> http://dev.mysql.com/doc/refman/5.7/...t_max_word_len

Quel est l'intérêt de le passer à 3 ?
La valeur minimale est 1.

Dans un script MySql, on ne peut pas modifier cette variable car elle est définie uniquement en lecture. Idem aussi pour "ft_max_word_len".
Mais pour d'autres variables, elles sont modifiables depuis un script.

C'est vraiment une contrainte pour toi d'avoir "ft_min_word_len" à 4 ?

@+

[ericd69]

Salut,

l'intérêt? simple si tu as des expressions de 3 caractères (sigles, mots dans certaines langues, etc) que tu veux rechercher...

Tu as les prix pour la version ssd.
Si tu veux discuter de configuration voir de tarifs, mp moi, je suis dev pas ingénieur système par contre je te préviens ...

Tu te connectes via user/mp en ssh, le temps de mettre une clé de connexion puis seulement avec elle en bloquant la connexion via user/mdp, tu génères un fichier de sécurité pour le firewall via fwdbuilder, un logiciel gratuit. tu crées un ou d'autres utilisateurs système (leur version ne contient que root) pour les applications que tu veux déployer...
là, tu pars sur une débian 8.0 nue (ce que j'utilise) et tu installes ce que tu veux, perso, pour le web, je suis php/nginx/postgresql, j'ai scripté une grande partie de l'installation des services (avec des fichiers de commande .sh) pour une réinstallation rapide sur les versions les plus hautes de chaque composant
et hop tu es prêt...

L'avantage, c'est que tu gères tous tes fichiers de configuration et que tu peux tout avoir sur un seul serveur, donc communication possible par "unix sockets" plus performants que tcp/ip entre services... toutes tes communications pour la configuration ou l'envoi de fichiers se font ainsi avec un chiffrement ssl (grâce à ssh, sftp)...
L'offre vps est évolutive ascendante, tu ne peux que monter en gamme pas descendre...

J'espère que ça t'auras éclairé

[boteha]

Bonjour,

Salut boteha.
C'est vraiment une contrainte pour toi d'avoir "ft_min_word_len" à 4 ?

J'ai plus de 200 mots de 3 lettres qui sont des motifs de recherche pertinents.
Il y a aussi des mots de 2 lettres qui sont pertinents, mais beaucoup moins, et je les traitent en amont dans PHP par une table de concordance élaborée au fil de l'eau.
Par exemple RJ 45 devient rj45, LC devient connecteurlc, etc.

Autrement, ericd69, merci de tes conseils, je vais y réfléchir.
Je te teins au courant si migration, ce n'est pas trop urgent mais j'y pense.

[Artemus24]

Salut à tous.

@ boteha : Il y a une chose que je ne comprends pas bien.

Normalement, le fichier my.ini est destiné à tous les utilisateurs du serveur MySql et non pour un utilisateur en particulier, comme c'est le cas avec le fichier php.ini.
Quand tu parles d'un "sql privé", je ne comprends pas très bien, puisque tu es sur un serveur mutualisé.
Il faudra que l'on m'explique comment procéder car je ne connais pas la possibilité d'avoir un fichier my.ini par utilisateur.

Si tu utilises un fichier "stopword" ou si tu passes le minimum à 3 caractères, cela va avoir un impact pour les autres utilisateurs qui utilisent FTS.
Est-ce bien le moteur "MyIsam" que tu utilises et non "InnoDB" ?

@ ericd69 : à qui est adressé ton message ? A boteha, je suppose.

Le prix n'est pas très cher pour la version "VPS SSD 1", soit 2.99€ HT avec 10Go d'espace disque.
Peut-on vraiment disposer d'un serveur web avec cette configuration ?

@+

[ericd69]

ovh proposait des "sql privé" avec un my.ini accessible pour compenser les serveur limité des versions mutualisés


oui tu as un vrai serveur (tu mets ce que tu veux dessus), avec divers distributions, 100Mo/s de bande passante jusqu'à 10To puis 1Mo/s, après la puissance (vcore/mémoire) et la capacité (taille disque ou ssd) dépendent de ce que tu veux...
l'installation de la distrib est en un clic ce qui n'est pas plus mal...

[boteha]

Bonjour

Normalement, le fichier my.ini est destiné à tous les utilisateurs du serveur MySql et non pour un utilisateur en particulier, comme c'est le cas avec le fichier php.ini.
Quand tu parles d'un "sql privé", je ne comprends pas très bien, puisque tu es sur un serveur mutualisé.
Il faudra que l'on m'explique comment procéder car je ne connais pas la possibilité d'avoir un fichier my.ini par utilisateur.

On ne va faire de la publicité à OVH mais le SQL privé te permettait d'accéder à my-ini depuis le manager, cela avec un hébergement mutualisé.
Nouvelle version, on n'accède plus qu'à quelques variables, d'où mon problème.
Je ne sais pas si OVH l'a résolu en me remettant sur l'ancienne architecture ou par une personnalisation.

Si tu veux en savoir plus va voir la doc SQL privé chez OVH.

[Artemus24]

Salut Boteha.

Je suis chez AlwaysData, et je n'ai pas la possibilité d'avoir un fichier my.ini personnalisé dans la version mutualisée.

Dans mon WampServer qui se trouve installé sur mon ordinateur, j'ai qu'un seul fichier my.ini, quelque soit le nombre de bases de donnes que j'utilise.
Tout ce que tu peux faire, c'est modifier quelques variables de ton serveur MySql, en les mettant dans ton script.
Elles auront un effet que durant la session de ton script.

@+

[boteha]

Je suis chez AlwaysData, et je n'ai pas la possibilité d'avoir un fichier my.ini personnalisé dans la version mutualisée.

C'est devenu comme cela chez OVH, même avec un SQL "privé".