France Telecom's Search Engine based on a 24 TB database powered by PostgreSQL

In the Following text, Severine Aubry and Robin POUGET, who are respectively Project Manage and Database Manager at France Telecom, demonstrate their use of PostgreSQL for a major tool of they company.

France Telecom has build a web search engine called “Le Moteur” (http://www.lemoteur.fr/). Behind this engine lies a back office that includes all that the machinery needed to store the keywords contained by web sites (URLs), analyzing them, indexing them, etc.. This application is highly critical because as it determines the quality of the results produced by the search engine.

This back office must be refreshed in 24hours/24 and 6days/7.

In other words, we can tolerate a non-updated weekly.

The “back office” of the search was conducted between 2001 and 2002, only with PostgreSQL. At that time, the project began with version 7.4. Today the project is based on PostgreSQL 8.2. The “back office” has, over the years, of course, been some improvements and fixes.

In detail, the engine is composed of a “crawler”, whose charge is to browse internet with a list of URLs and key thousands of reference sites. It follows links automatically.

The charge of “crawler” is to retrieve URLs and associated content.

This data is then processed through several scripts written in TCL.

Data is stored in a schema with a few thousand tables. The partitioning is based on technology developed internally, based on hash key type.

The thrust of the project are from the beginning to have a solution:

  stable
  robust
  very maintainable
  scalable, capable of cashing a soaring volume and therefore
  free from the problems of disk space, or the number of servers needed PostgreSQL

Some figures:

  5 billion and tuples are distributed
  160 machines that are home to 800 servers PostgreSQL on Linux,
  for a total volume of 24 terabytes
  Note that PostgreSQL is not only running on these machines, there are also applications

The machines are spread over three geographical sites, with a logical division, called “software blocks.”

There are data export this set to other data servers for various uses.

This results in high flexibility of the entire application: if a server has to fall, there is no interruption of service because the data it contains are redundant. There is no more dependence between the elements.

There has been in the history of the project a few minor issues that were fixed by the community, whose support is deemed “effective”:

  problems of fragmentation of data, linked to massive UPDATE. This has been fixed with the new features of PostgreSQL over the years (remember the project over 10 years with PostgreSQL!)

  Version 8 has corrected any concerns in terms of memory management;

  VACUUM FULL's almost ancient history. We went into this project from March to April VACUUM FULL to 1 year only.

In conclusion, PostgreSQL gives satisfaction here over 10 years. The few problems encountered were all treated with the utmost effectiveness of the community. New versions of PostgreSQL have brought more or solutions to these problems, or improvements or simplifications.

[Interview by Jean-Paul Argudo, March-June 2011] Séverine AUBRY and Robin POUGET témoignent de l'utilisation de PostgreSQL pour un outil de France Télécom.

Il s'agit du moteur de recherche “Le moteur”: http://www.lemoteur.fr/. Plus exactement, il s'agit du “back office” de ce site: c'est à dire, toute la machinerie nécessaire pour stocker les mots-clés contenus par des sites webs (URLs), les analyser, les indexer, etc.

La criticité de cette application est haute car elle conditionne la qualité des documents indexés dans le moteur de recherche.

Ce “back office” a une contrainte de rafraichissement en 24/7, mais 6 jours sur 7 uniquement. En d'autres termes, on peut tolérer une non-mise à jour une fois par semaine.

La partie “back office” de ce moteur de recherche a été réalisée entre 2001 et 2002, exclusivement avec PostgreSQL. À cette époque, le projet a débuté avec la version 7.4. Aujourd'hui, le projet est basé sur PostgreSQL 8.2. Le “back office” a, au fil des années, bien sûr connu quelques améliorations et corrections.

Dans le détail, le moteur est composé d'un “crawler”, dont la charge est de parcourir internet grâce à une liste d'URL-clés et plusieurs milliers de sites de référence. Celui-ci suit les liens de manière automatique.

La charge du “crawler” est donc de récupérer des URLs et un contenu associé.

Ces données sont ensuite traitées via plusieurs scripts, écrits en TCL.

Les données sont stockées dans un schéma comportant quelques milliers de tables. Le partitionnement repose sur une technologie développée en interne, basée sur des clés de type hash.

Les idées-force du projet, sont depuis le début, d'avoir une solution:

  stable
  robuste
  très maintenable
  scalable, propre à encaisser une volumétrie galopante et donc,
  affranchie des problèmes d'espace disque, ou du nombre de serveurs PostgreSQL nécessaires

Quelques chiffres:

  5 milliards de tuples sont ainsi répartis sur
  160 machines qui abritent 800 serveurs PostgreSQL, tous sous Linux,
  pour une volumétrie totale de 24 téra-octets
  à noter qu'il n'y a pas que PostgreSQL qui fonctionne sur ces machines, on y trouve aussi des applications

Les machines sont réparties sur 3 sites géographiques, grâce à un découpage logique, dit de “blocs logiciels”.

Il existe des exports de données de cet ensemble vers d'autres serveurs de données, pour des utilisations diverses.

Il en résulte une extrême souplesse de l'ensemble applicatif: si un serveur vient à tomber, il n'y a aucune coupure de service, car les données qu'il contient sont redondées. Il n'y a de plus aucune dépendance entre les éléments.

Il y a eu dans l'histoire du projet quelques soucis mineurs qui ont été corrigés par la communauté, dont le support est jugé “efficace”:

  des problèmes de fragmentation de données, liés à des UPDATE massifs. Cela a été corrigé grâce aux nouvelles fonctionalités de PostgreSQL au fil des ans (pour rappel le projet a plus de 10 ans avec PostgreSQL!);

  la version 8 a permis de corriger des soucis au niveau de la gestion de la mémoire;

  les VACUUM FULL sont presque de l'histoire ancienne. On est passé dans ce projet de 3 à 4 VACUUM FULL par an à 1 seul.

En guise de conclusion, PostgreSQL donne ici entière satisfaction depuis plus de 10 ans. Les quelques soucis rencontrés ont tous été traités avec la plus grande efficacité de la communauté. Les nouvelles versions de PostgreSQL ont de plus apporté, soit des solutions à ces problèmes, soit des améliorations, voire des simplifications.

[Propos recueillis par Jean-Paul Argudo, de mars à juin 2011]