Indexation d'une base documentaire pour Liberation

Indexation d’une base documentaire pour lequotidien Libération

Gaël LE MIGNOT — Pilot Systems

25 juin 2010

Gaël LE MIGNOT — Pilot Systems Indexation d’une base documentaire pour le quotidien Libération

Plan

1 Introduction2 Architecture

Architecture actuelleNouvelle architecturePremières expériences

3 Nécessité d’une heuristiqueAnalyse des résultatsDéfinition de l’heuristiqueFinitions

4 Contributions et partitionsAjout des contributionsUtilisation des partitions

5 Accès concurrents6 Conclusion


Contexte

Contexte général

Quotidien LibérationUtilisation en back-office dans un premier tempsUtilisation en frontal prévue pour l’avenir

Utilisation de la rechercheNavigationRecherches simplesRecherches documentaires

Solution actuellePropriétaire, sous Windows (TextML)Problèmes de performances et de stabilité


Base d’indexation

Volumétrie583 675 articles140 870 pages1 134 382 contributions (non indexées dans TextML)104 595 contenus divers

Types d’indexRecherche en texte pleinRecherche sur texte exactFiltres sur des méta-données : auteurs, catégories, . . .Tri par date


Interface de recherche


Architecture

Architecture


Schéma de l’architecture actuelle


Schéma de la nouvelle architecture


Points clés de la nouvelle architecture

Avantages directement recherchés

Performances et stabilitéPossibilité d’indexer les contributionsPossibilité d’aller vers l’utilisation en frontalContrôle plus fin du comportement

Avantages connexes

Gestion des dépendances(entre auteurs et articles par exemple)Ré-indexation massive facilitéeRé-indexation partielle possiblePlus grande liberté de recherche


Première approche

Structure de la baseUne seule table, libeindexclassname et id comme clé primaireNombreuses colonnes, dont des champs en tsvector

Matériel et logicielMachine virtuelle sous XenDebian 5.0PostgreSQL 8.3Deux cœurs dédiés à la machine virtuelleMémoire variant de 4Go à 12Go suivant les tests


Premiers résultats

Modalités de mesureLog des requêtes effectuées en productionDeux périodes : 10 au 19 juin, et 1er juillet au 19 aoûtEnvoi séquentiel dans n threads, par défaut 1

Résultats statistiques sur la première version


Exemple de requête

La requêteSELECT classname, id, modifiedAtFROM libeindexWHERE fulltext_tsv @@ plainto_tsquery(’public.simple_french’, ’gauche’)ORDER BY modifiedAt DESC LIMIT 20;

Le query planLimit (cost=3.03..3.03 rows=3 width=19)

(actual time=25657.959..25658.011 rows=20 loops=1)-> Sort (cost=3.03..3.03 rows=3 width=19)

(actual time=25657.955..25657.971 rows=20 loops=1)Sort Key: modifiedatSort Method: top-N heapsort Memory: 26kB-> Bitmap Heap Scan on libeindex

(cost=1.47..3.00 rows=3 width=19)(actual time=559.153..25568.663 rows=46328 loops=1)Recheck Cond: (fulltext_tsv @@ ’’’gauche’’’::tsquery)-> Bitmap Index Scan on libeindex_fulltext_index

(cost=0.00..1.47 rows=3 width=0)(actual time=548.904..548.904 rows=46328 loops=1)Index Cond: (fulltext_tsv @@ ’’’gauche’’’::tsquery)

Total runtime: 25658.085 ms


Nécessité d’une heuristique

Nécessité d’une heuristique


Émergence de l’idée

ConstatationsLes requêtes sont lentes quand les termes recherchéssont très fréquents.Cependant, seules certaines de ces requêtes sont lentes.La plupart des requêtes demandent les 20, 50 ou 100éléments les plus récents.

ConclusionPostgreSQL se trompe donc parfois de query plan.


Explication : terme rare


Explication : terme fréquent


Optimisation manuelle de la requête

La requêteSELECT classname, id, modifiedAtFROM (SELECT * FROM libeindex ORDER BY modifiedAt DESC LIMIT 2500) subqueryWHERE fulltext_tsv @@ plainto_tsquery(’public.simple_french’, ’gauche’)ORDER BY modifiedAt DESC LIMIT 20;


(actual time=150.467..651.747 rows=20 loops=1)-> Subquery Scan subquery (cost=0.00..1100.22 rows=12 width=528)

(actual time=150.464..651.701 rows=20 loops=1)Filter: (subquery.fulltext_tsv @@ ’’’gauche’’’::tsquery)-> Limit (cost=0.00..1068.97 rows=2500 width=1418)

(actual time=29.239..288.642 rows=426 loops=1)-> Index Scan Backward using libeindex_modifiedat_index on libeindex

(cost=0.00..359616.93 rows=841035 width=1418)(actual time=29.237..287.880 rows=426 loops=1)



Fonctionnement de l’heuristique

Principe de l’heuristiqueOn commence par faire une subquery sur les élémentsrécents uniquement.Plan A : recherche sur un petit nombre d’éléments récents.Plan B : comme le plan A, mais sur plus d’éléments.Plan C : recherche classique, sans subquery.


Algorithme

Légende

INITIAL = 2500,THRESOLD = 0.35,MARGIN = 3.0ratio = found

wanted


Résultats

Résultats statistiques

Analyse des résultatsRésultats globalement très satisfaisant.Requête la plus lente : « france 2 »


Améliorations mineures

Listes des améliorations mineuresIndex croisés sur classname et les champs dates.Paramétrage de l’heuristique.PostgreSQL 8.4, avec un statistics à 10 000.



Requêtes courtes et longues

Limitations imposées par l’heuristiquePas de décompte du nombre de résultats.Pas de pagination possible.

SolutionDéfinition de deux méthodes dans SeSQL.Short queries pour la navigation ou les recherchessimples.Long queries pour les recherches documentaires, plusspécifiques.Amélioration possible : faire une short query pour afficherla première page, et en tâche fond effectuer la long query.


Contributions et partitions

Contributions et partitions


Ajout brutal

ExpérienceAjout des contributions dans la base, sans autremodification.Les requêtes ne portent pas sur les contributions.



Partitions PostgreSQL

DescriptionObjectif : séparer les contributions des autres contenus.Utilisation de l’héritage de tables.Utilisation des contraintes sur les sous-tables.

Résultats


Exemple de requête

La requêteSELECT classname, id, createdAtFROM (SELECT * FROM libeindex WHERE (classname=’article’)

ORDER BY createdAt DESC LIMIT 2500) subqueryWHERE fulltext_tsv @@ plainto_tsquery(’public.simple_french’, ’gauche’)ORDER BY createdAt DESC LIMIT 20;


Exemple de requête (suite)




(actual time=6158.128..6158.700 rows=203 loops=1)-> Sort (cost=75939.11..77434.83 rows=598286 width=1495)

(actual time=6158.125..6158.331 rows=203 loops=1)Sort Key: public.libeindex.createdatSort Method: top-N heapsort Memory: 3634kB-> Result (cost=0.00..39181.28 rows=598286 width=1495)

(actual time=0.064..3878.206 rows=583675 loops=1)-> Append (cost=0.00..39181.28 rows=598286 width=1495)

(actual time=0.060..2360.568 rows=583675 loops=1)-> Index Scan using libeindex_pkey on libeindex


Index Cond: ((classname)::text = ’article’::text)-> Seq Scan on libedefault libeindex


Filter: ((classname)::text = ’article’::text)Total runtime: 6161.217 ms


Exemple de requête (fin)

Le query plan idéalLimit (cost=0.00..299.07 rows=12 width=528)



(actual time=29.106..33.643 rows=203 loops=1)-> Index Scan Backward using libedefault_createdat_index on libedefault

(cost=0.00..64092.05 rows=598285 width=1495)(actual time=29.103..33.280 rows=203 loops=1)Filter: ((classname)::text = ’article’::text)



Gestion des partitions dans SeSQL

ContournementSeSQL va analyser la requête.Il effectue les requêtes sur les sous-tables directement, etfusionne.Uniquement en short query car inutile en long query.

Nouvelles partitionsPartitions séparées pour tous les éléments « nonéditorial ».Tous les éléments éditoriaux dans une table.Au total : 9 tables.


Résultats finaux



Accès concurrents

Accès concurrents


Modalités de tests

ContraintesJusqu’à présent, tests séquentiels uniquement.Dans la réalité, il y a des requêtes simultanées, en lecturecomme en écriture (mise à jour, indexation de nouveauxéléments).Problème : nous n’avons pas de logs exacts en ce quiconcerne l’écriture.

Tests réalisésEffectuer des requêtes depuis plusieurs threads.Chaque thread effectue des requêtes d’un seul type(recherche ou indexation), en continu.Variation du nombre de threads dédiés à chaque tâche.


Accès concurrents



Conclusion

Conclusion


Conclusion

Situation actuelleRésultats très positifs des testsDéployé sur la pré-productionEn attente de déploiement sur la production

Évolutions futuresUtilisation sur le frontalAmélioration du cas « france 2 »

Dépendances au niveau des colonnes


Le but secret...

... la migration de la base principale en PostgreSQL.


En attendant

RemerciementsMerci à la communauté PostgreSQL et à la communautéPythonMerci à Libération de nous avoir fait confianceMerci à Jérôme Petazzoni qui a contribué à la conception


En attendant

La page de pub

Pilot Systems, société de services en logiciels libres :http://www.pilotsystems.net

Contactez-nous sur [email protected]

Les slides

Licence CC-By-Sahttp://contributions.pilotsystems.net/

Des questions ?


Technology

Indexation d'une base documentaire pour Liberation