Voici la suite du post MySQL 5.6 rock, dans lequel je test MySQL 5.5 & 5.6, MariaDB 5.3 & 5.5 et Percona server 5.5.

Pour cet article, toujours un bench. Le contexte est assez proche, à la différence près que cette fois les serveurs sont testés en lecture (65%) et écriture (35%).

Comme d'habitude, mon but n'est pas de connaître les possibilités maximales du serveur (d'autres le font mieux que moi), mais plutôt d'avoir une idée assez précise de leurs comportements respectifs dans un environnement le plus proche possible de ma prod.

pour ce test, les candidats sont, Percona 5.5, MariaDB 5.3 & 5.5, MySQL 5.5 et la dernière milestone de MySQL 5.6. L'idée est de voir comment se comporte les différentes versions dans un contexte I/O bounds ie un faible hit ratio du buffer pool (ou du moins le plus bas possible), en d'autres termes, simuler le comportement du serveur MySQL dans un environnement où la quantité de données est énorme (comme à Viadeo).

--dump-rows

Cette option va regénérer un code sql dans une fichier.

Ce code SQL va regénérer une table basée sur nom de la source d'indexation et en y insérant ce qui a été lu par l'indexation.

donc

si j'ai

source  ma_source {
(...)
sql_query = "Select id, nom, prenom, age From ma table_source"
}

ca va donner

Une table rows_ma_source

avec 4 colonnes dans la quelle on voit un insert des valeurs récoltées.

C'est tout simple avec --print-queries on voit directement à l'écran les requêtes SQL qui sont exécutées.

C'est bien pratique pour le debug.

Ca me fait penser à une autre astuce, non spécifique à Sphinx, mais que j'ai commencé à utiliser avec Sphinx.

Dans mes requêtes sql , je met toujours derrière le select un commentaire par exemple

Select /* blablah */ champs1 From  matable

Pourquoi ?

pour la reconnaître facilement dans mytop.

Vous ne connaissez pas mytop ? et vous utilisez mysql ?

Faite donc vite un

sudo apt-get install mytop

et lisez ceci : http://wiki.goldzoneweb.info/mytop

source : http ://sphinxsearch.com/docs/2.0.4/ref-indexer.html

--sighup-each

Problème en indexant plusieurs indexs avec un seul appel ca me donne

indexer --config sphinx.conf --rotate --quiet  chunk-1 chunk-2 chunk-3 chunk-4 chunk-5 chunk-6

Il fallait attendre que le chunk-6 soit fini pour que le chunk1 indexé depuis un certain temps soit en ligne. Dommage.

du coup j'avais refait

   ./indexer --config sphinx.conf --rotate --quiet chunk-1 && 
   ./indexer --config sphinx.conf --rotate --quiet chunk-2 && 
   ./indexer --config sphinx.conf --rotate --quiet chunk-3 && 
   ./indexer --config sphinx.conf --rotate --quiet chunk-4 && 
   ./indexer --config sphinx.conf --rotate --quiet chunk-5 && 
   ./indexer --config sphinx.conf --rotate --quiet chunk-6 

indigeste mais ca fonctionne …

Il n’existe pas de fonction dans MySQL  (et bien d’autres SGBD) pour trouver le nombre d’occurrences d’une chaîne de caractères dans une autre.  Par exemple, combien de fois « ait » apparaît dans la chaîne « Il était grand mais il avait peur » ?

Ou, comme on me l’a récemment demandé sur IRC, vous cherchez à déterminer le nombre d’occurrences d’une sous-séquence particulière (par exemple, « TAT ») dans la séquence génomique suivante :

ATTGGTGGGCTCTACTAAGATATCAACGGGACTTCGGAGCGTGCCGCACTATTT

Évidemment, vous pouvez lire les données du SGBD puis faire la recherche en mémoire en utilisant votre langage de programmation préféré mais comment faire le tout en SQL ?

La solution est simple et elle a la forme suivante :

SELECT FLOOR(( LENGTH(source) - LENGTH(REPLACE(source, chaineAChercher, '')) ) / (LENGTH(chaineAChercher))) as occ …

Selon le livre «Audit & optimisation, MySQL 5 - éditions Eyrolles», le cache de requêtes ou query cache est un système de cache mémoire interne à MySQL, transparent pour l'application, qui ne stocke que les requêtes SELECT et leurs résultats.

L'apport de ce cache est particulièrement dépendant de votre application. Il est coutume de dire qu'il est (très) pénalisant dans des environnements où les requêtes d'écritures sont nombreuses, notamment à cause de son mécanisme d'invalidation (et de problèmes de contentions de façon générale).

A l'opposé, il peut être intéressant de l'activer, dans des environnements à forte charges de lectures, si les mêmes requêtes reviennent très fréquemment, plus particulièrement lors de l'utilisation de tables MyISAM.

Cependant, un environnement à forte charge en lecture n'est pas une condition suffisante pour s'assurer de bonne performances avec le query …

Last weekend Vadim from Percona published his MariaDB 5.3.4 benchmark results. As the new benchmark guy at Monty Program I take this oportunity to add some more results of my own.

One question in the comments to Vadim was if it is fair to compare MariaDB-5.3 with MySQL-5.5. Or if this comparison should be done with MySQL-5.1. The answer is: it does not matter much. MySQL-5.5 and MySQL-5.1 show very similar results in the Sysbench OLTP benchmark.

Dernier volet dans notre série sur la configuration de MySQL, cet article va vous donner les clés pour paramétrer correctement et simplement InnoDB.

InnoDB est un moteur extrêmement complexe qui mériterait un livre complet pour expliquer son fonctionnement. Selon les versions, il peut exister plus de 80 paramètres pour contrôler son fonctionnement : pas question de les examiner tous ! Je vais me concentrer sur les 2 principaux, qui devraient suffir dans la majorité des cas.

Le 1er, innodb_buffer_pool_size, contrôle la taille du cache mémoire pour les données et les index. Il s’agit assurément du paramètre de base pour obtenir de bonnes performances InnoDB puisqu’il vous permet de remplacer de nombreuses lectures ou écritures sur disque par des lectures ou écritures en mémoire. Pour le configurer, c’est simple, essayez de mettre la valeur la plus élevée possible… Evidemment, il faut penser à …

Mes données liées à des nœuds ou feuilles d'un arbre et je veux pouvoir faire une recherche en filtrant sur un nœud en espérant trouver toutes les entrées liés à ce nœud ou a sa descendance.

Mes données sont donc

* id_ressource
* id_category
* ...

Et j'ai un arbre stocké dans une structure classique

* id_category
* id_category_parent
* ...

 1    null
 2    null
 3    1
 4    3
 5    3
 6    2
 7    6
 8    6

Solution 1.

J'indexe les données sans me préoccuper de l'arbre, juste en stockant l'id_category d'appartenance.

Lorsque que je veux chercher un nœud, je récupère la liste de ses enfants et puis je cherche tous les objets appartenance à un de ces catégories

donc pour la catégorie 2

;filter:id_category,2,6,7,8

Le problème avec cette solution, c'est qu'avec un arbre imposant, on se retrouve avec des filtres très grands.