Kamelot Blog

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 1 septembre 2010

mer
01
sep '10

Nombre de résultats d'une recherche SphinxSe

Logo Sphinx Sphinx est un moteur de recherche full-text

On peut l'interroger au travers de son api, SphinxQL, en ligne de commande ou avec l'engine MySql SphinxSE

J'utilise MySqlSE;

SELECT * from INFORMATION_SCHEMA.ENGINES;

ENGINE SUPPORT COMMENT                     TRANSACTIONS  XA      SAVEPOINTS
------ ------- --------------------------- ------------  ------  ----------
...
SPHINX YES     Sphinx storage engine 0.9.9 NO            NO      NO        

La question du jour était : Y a-t-il un moyen de connaître le nombre total de résultats quand on utilise un limit ?

En Mysql simple, il y a SQL_CALC_FOUND_ROWS

mysql> SELECT SQL_CALC_FOUND_ROWS * 
    -> FROM tbl_name
    -> WHERE id > 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

Le second SELECT retourne un nombre indiquant combien de lignes le premier SELECT aurait retourné s'il n'avait pas été écrit avec une clause LIMIT.

Mais avec avec SPHINX

En testant sur ma table tbl_name_sphinx qui contient 2410 rows.

select SQL_CALC_FOUND_ROWS * from tbl_name_sphinx WHERE query='' LIMIT 10;
SELECT FOUND_ROWS();
Résultat
FOUND_ROWS()
------------
          20

20 parce que c'est la valeur par défaut du limit de sphinx

# limit - amount of matches to retrieve from result set, default is 20; (ref)

En effet si je force ce limit à 10

select SQL_CALC_FOUND_ROWS *
 from tbl_name_sphinx 
 WHERE query=';limit=10';

SELECT FOUND_ROWS();
Résultat

FOUND_ROWS() -> 10

Pourquoi ? parce que c'est sphinx qui fait la vraie recherche et remonte son résultat à MySql

Donc quand je fait

select SQL_CALC_FOUND_ROWS * 
 from tbl_name_sphinx 
 WHERE query=';limit=1000' 
 LIMIT 10;

Je reçois 10 résultats sur 2410 réels et sur les 1000 que sphinx a remonté

Donc

SELECT FOUND_ROWS(); -> affiche 1000 et pas 2410.

Donc je vais monter mon limit à 1000000.

Gloups, je viens de demander à Sphinx de me préparer en résultat de 100K rows, tout renvoyer à mysql dans une table temporaire qui me retournera uniquement les 10 premiers.... Fameux gaspillage

Quand on sait que sphinx ne me retourne que les id et que donc il faut faire un join avec la table de données, ca fait mal.

la solution

SHOW ENGINE SPHINX STATUS;

On oublie le 'SQL_CALC_FOUND_ROWS'

Et on remplace FOUND_ROWS() par SHOW ENGINE SPHINX STATUS;

On remet le limit 10 au niveau de sphinx;

select  * 
 from tbl_name_sphinx 
 WHERE query=';limit=10';

SHOW ENGINE SPHINX STATUS;

Type    Name    Status                                           
------  ------  -------------------------------------------------
SPHINX  stats   total: 1000, total found: 2410, time: 0, words: 0

Bingo j'ai mon info, planquée dans une "chaine" mais je l'ai.

re bingo

 SHOW STATUS LIKE 'sphinx_%';

Mais je préfère INFORMATION_SCHEMA.

SELECT *
 from information_schema.GLOBAL_STATUS
 WHERE VARIABLE_NAME like 'SPHINX%';
VARIABLE_NAME       VARIABLE_VALUE
------------------  --------------
SPHINX_ERROR        208409        
SPHINX_TIME         0             
SPHINX_TOTAL        1000          
SPHINX_TOTAL_FOUND  2410          
SPHINX_WORD_COUNT   0             
SPHINX_WORDS                      

Et je suis un heureux.

Si vous êtes intéressés par Sphinx, voici un bon article pour l'installer.

Si vous vous êtes déjà intéressé à Zend_Search_Lucene, (bien décrit ici) il me semble avoir que celui-ci peut utiliser Sphinx comme backend. je corrigerai si je retrouve la source.

dimanche 18 avril 2010

dim
18
avr '10

Timestamp VS Datetime

Jeudi en buvant un verre avec un ami, il me demande la différence entre un Datetime et un Timestamp.

J'ai répondu mais je me doutais que je n'étais pas exhaustif.

J'ai donc un peu relu. Ca fait toujours du bien.

1° la taille

  • Datetime -> 8 bytes
  • alors que timestamp c'est 4 bytes

Si on a pas besoin de stocker une date et une heure, on a d'autres possibilités.

  • Date ou Time c'est 3 Bytes
  • Year C'est 1 byte

2° Les dates représentables

  • Date et DateTime -> Année 1000 à 9999
  • Year -> Année 1901 à 2155
  • Timestamp -> Année 1970 à 2036[1]

3° "default" magiques

Timestamp peut être mis à jour automatiquement à la date serveur lors d'une création ou mise à jour de l'enregistrement.

4° Particularité supplémentaire pour mysql

Les valeurs ``zéro``

  • DATETIME '0000-00-00 00:00:00'
  • DATE '0000-00-00'
  • TIMESTAMP 00000000000000 (la longueur dépend de la taille de l'affichage)
  • TIME '00:00:00'
  • YEAR 0000

Cela peut-être désactivé avec certains modes.


Affichage et format

Bien que les valeurs TIMESTAMP soient stockées avec une précision d'une seconde, la seule fonction qui travaille directement avec ces valeurs est la fonction UNIX_TIMESTAMP(). Les autres fonctions opèrent sur des valeurs lues et formatées.

Notes

[1] En fait c'est 2037 mais pas jusqu'au 31 décembre.

mardi 4 mars 2008

mar
04
mar '08

Belgian MySQL Users meeting

Le 18 mars prochain, au Cafe Sport à Leuven se tiendra le prochain meeting du MySQL Belgian User Group Geert envisage d'aborder les points suivants

  • revue rapide de ce qui s'est passé dernièrement avec MySQL
  • Avenir de certaines activités en Belgique
  • Bonnes pratiques, en ce qui concerne l'installation, l'assistance, et quelques points sur les performances.

c'est là que ca se passe.

mercredi 30 janvier 2008

mer
30
jan '08

Plus jamais de crash de réplication avec mySQL 5 ?

Version originale

par peter

Comme vous le savez peut-être, même si vous êtes seulement des tables Innodb votre réplication n'est pas complètement sécurisée en cas de crash. Si le slave MySQL se plante ou est éteint, il est probable que les logs de relais en court de synchronisation (ils ne sont pas synchronisés sur le disque), deviennent obsolète et la synchronisation est perdue

Pour les séries MySQL 4.0 et 4.1 série il y avait un gros hack si vous utilisez uniquement des tables Innodb.

La suite

jeudi 24 janvier 2008

jeu
24
jan '08

SELECT WEEK( 1er Janvier);

SELECT WEEK('2008-01-01'); // 0;
SELECT WEEK('2008-01-07'); // 1;
SELECT WEEK('2008-02-03'); // 4;
SELECT WEEK('2008-12-31'); // 52;

WEEK ne compte que les semaines complètes.

Certains vont dire, mais non la première semaine c'est la 0.

Non, non, en voici la preuve

SELECT DAYOFWEEK('2008-01-01'), # 3
       DAYOFWEEK('2007-01-01'), # 2
       DAYOFWEEK('2006-01-01'), # 1 <- ICI l'année commence le premier jour de la semaine
       DAYOFWEEK('2005-01-01'), # 7
       DAYOFWEEK('2004-01-01'), # 6
       DAYOFWEEK('2003-01-01'), # 5
       DAYOFWEEK('2002-01-01'); # 4 

Du coup

SELECT WEEK('2008-01-01'), # 0
       WEEK('2007-01-01'), # 0
       WEEK('2006-01-01'), # 1 <-on est bien la première semaine complète de l'année
       WEEK('2005-01-01'), # 0
       WEEK('2004-01-01'), # 0
       WEEK('2003-01-01'); # 0 

et du coup

SELECT WEEK('2008-12-31'), # 52
       WEEK('2007-12-31'), # 52
       WEEK('2006-12-31'), # 53
       WEEK('2005-12-31'), # 52
       WEEK('2004-12-31'), # 52
       WEEK('2003-12-31'); # 52 

En fait maintenant il y a une deuxième paramètre.

WEEK(date ,mode)

Voici ce que dit le manuel.

Avec deux arguments, la fonction WEEK() vous permet de spécifier si les semaines commencent le Dimanche ou le Lundi et la valeur retournée sera dans l'intervalle 0-53 ou bien 1-52. Lorsque l'argument mode est omis, la valeur de la variable default_week_format (ou 0 en MySQL 4.0 ou plus ancien) est utilisée.

Voici un tableau explicatif sur le fonctionnement du second argument : Valeur Signification

  • 0 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année
  • 1 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
  • 2 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année
  • 3 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
  • 4 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
  • 5 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 0 à !2; la semaine 1 est la première semaine de l'année
  • 6 : La semaine commence le Dimanche;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année qui a plus de trois jours
  • 7 : La semaine commence le Lundi;l'intervalle de valeur de retour va de 1 à !2; la semaine 1 est la première semaine de l'année

Le mode 3 est disponible depuis MySQL 4.0.5. Le mode 4 est disponible depuis MySQL 4.0.17.

mercredi 16 janvier 2008

mer
16
jan '08

REPLACE reset les valeurs non spécifiées

# Je crée une table
DROP TABLE IF EXISTS `testReplace`;
CREATE TABLE `testReplace` (
  `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `a` INT(11) DEFAULT '1',
  `b` INT(11) DEFAULT '2',
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
#J'y ajoute 2 records /lignes/tuples
INSERT INTO `testReplace` 
	(`a`, `b`)
	VALUES
	(1, 1),(2,2);
SELECT * FROM  `testReplace`;
 id | a | b
============
  1 | 1 | 1
  2 | 2 | 2
#Je remplace la première valeur de la première ligne 
REPLACE INTO `testReplace` 
	SET `id`=1, a=3;
# que vaut b ? 
  SELECT * FROM  `testReplace`;
 id | a | b
============
  1 | 3 | 2
  2 | 2 | 2

B a repris sa valeur par défaut

En pratique cela veut dire que si on fait un replace et qu'on ne précise pas toutes les colonnes les colonnes non-spécifiées prennent la valeur par défaut alors qu'on peut s'attendre à un "non" changement.

Il est donc faux de croire que REPLACE c'est un exist(id) ? UPDATE : INSERT

C'est plutôt

  • exist(id) ? DELETE
  • suivi d'un INSERT

Il faut donc utiliser une autre méthode.

INSERT INTO table (id,a) VALUES (1,3)
  ON DUPLICATE KEY UPDATE a=3;

lundi 13 août 2007

lun
13
aoû '07

23 octobre Conférence MySQL 2007 à Paris

  • Découvrir comment tirer au mieux parti de MySQL
  • Bénéficier de conseils d'experts sur l'optimisation des performances
  • Assimiler les meilleures pratiques MySQL
  • Découvrir les nouvelles fonctionnalités et services pour mieux planifier vos déploiements de MySQL
  • Mieux comprendre comment sélectionner la solution de haute disponibilité pour MySQL la mieux adaptée à vos besoins
  • Poser toutes vos questions aux experts MySQL, et avoir l'opportunité de faire part de votre feedback et de vos commentaires
  • Nouer des relations avec l'équipe de MySQL AB
  • Découvrir comment vous pouvez bénéficier des solutions de nos partenaires

Agenda :

  1. Introduction : Bertrand Matthelié, Directeur Marketing EMEA
  2. La roadmap MySQL, nouveautés & fonctionnalités à venir : Robin Schumacher, Directeur Product Management
  3. Optimisation des performances: Session 1, meilleures pratiques : Stéphane Varoqui, Consultant
  4. MySQL pour les applications en ligne : Serge Frezefond Ingénieur Avant-Vente
  5. Optimisation des performances: Session 2, études de cas Stéphane Varoqui
  6. MySQL pour Datawarehouse & BI : Serge Frezefond
  7. Présentation Client: Skyblog et Crédit Mutuel
  8. Stratégies de Haute Disponibilité avec MySQL : Max Mether, Formateur
  9. Rendre la gestion de données d'abonnés flexible grâce à MySQL Cluster Carrier Grade : Christophe Thivend, Alcatel-Lucent
  10. Définition d'une stratégie de moteurs de stockage : Kaj Arnö, VP Community; Stéphane Varoqui, Serge Frezefond
  11. Conclusion et Questions/Réponses

MySQL AB :: Conférences Européennes MySQL 2007

Prix 199€, (159€ avant le 31 Août 2007)

lun
13
aoû '07

Quoi de neuf avec MySQL 5.1

Êtes-vous prêt pour passer à MySQL 5.1 ? Vous devriez. C'est vrai qu'il y a eu un grand écart de temps entre l'alpha et la beta, mais là c'est vraiment près de GA. Vraiment. Et puis, vous devrez vous habituer à lui. il y a pas mal de nouveautés attrayante. Laissez moi vous donner un aperçu.

Lire la suite...

dimanche 5 août 2007

dim
05
aoû '07

Jay Pipes veut voir ce qu'on connait de Mysql

Jay PipesPar un petit sondage assez rapide, expliqué ici

3 participants tirés au sort recevront 2 livres Apress chacun

Photo par duncandavidson

vendredi 3 août 2007

ven
03
aoû '07

Mysql-Proxy

LogoOn sait faire pas mal de choses intéressantes avec mysql-proxy mais celle qui me plait le plus c'est de pouvoir rediriger les écritures sur master et les lectures sur le slave.

Mais je vais comment trouver le temps de tester tout ca.

Planet Mysql

vendredi 13 juillet 2007

ven
13
juil '07

Livre Sécurité PHP 5 et MySQL: chapitres gratuits

J'annonçais la semaine dernière la parution du livre sur la Sécurité PHP 5 et MySQL.

Sachez que la table des matières et 4 chapitres sont disponibles en pdf chez l'éditeur (Eyrolles) couverture

  • Risques liés aux applications web
    • Introduction à la sécurité des applications web
    • Vulnérabilités des pages web
    • Formulaires et téléchargement ; valider les données
    • Cookies et sessions
  • Mesures de sécurité pour PHP
    • Installation et configuration de PHP
    • Intégrité des scripts PHP
    • Risques liés aux bases de données
    • Vulnérabilités des base de données
    • Mesures de sécurité pour MySQL
  • Mesures de sécurité pour les technologies connexes
    • Mesures de sécurité côté serveur
    • Techniques de sécurisation des applications web
    • Mener un audit de sécurité
  • Annexes
    • A. Fonctions de sécurité et caractères spéciaux
    • B. Sauvegardes
    • C. Ressources web

dimanche 8 juillet 2007

dim
08
juil '07

Livre Sécurité PHP 5 et MySQL

Livre Sécurité PHP 5 et MySQL Livre Sécurité PHP 5 et MySQL
Il est sorti. Il donne des conseils, des idées, des conduites, des approches, à chacun d'en tirer les leçons et développer les réflexes.

Disponible chez eyrolles.

jeudi 14 juin 2007

jeu
14
juin '07

Bon anniverssaire Mathieu & Geert

Ce jour c'est l'anniversaire de 2 personnes que j'apprécie particulièrement liées à 2 thématiques récurrentes de ce blog.

Mathieu et moiMathieu Laurent : le monsieur des serveurs de Claroline. Outre les développements qu'il effectue pour le projet, il gère les serveurs de dev et des sites claroline .net .com ... Tout Geek qu'il est il a aussi une vie après l'informatique. Animateur responsable de l'unité Scoute de Soignies, coureur de fond et organisateur d'un Festival de Musique : le Touch May Festival

Geert Vanderkelen L'autre c'est Geert Vanderkelen, Le belge de chez Mysql, véritable pilier du Belgian MySQL User Group. Même expatrié, il rentre au pays pour ces rencontres d'utilisateur.

A tous les deux je vous souhaite un heureux anniversaire

dimanche 27 mai 2007

dim
27
mai '07

Mysql User Group Meeting

Le site du groupe existe, inscrivez vous dès maintenant pour être au courant en temps et en heure de la 4ème rencontre toute proche

mercredi 23 mai 2007

mer
23
mai '07

SELECT WEEK( 1er Janvier);

WEEK ne compte que les semaines complètes.

SELECT WEEK('2007-01-01'); // 0;
SELECT WEEK('2007-01-07'); // 1;
SELECT WEEK('2007-05-23'); // 20;

Tags