Différences

Ci-dessous, les différences entre deux révisions de la page.

--- en:temoignages:moteur_orange [2011/07/06 21:51]
daamien
+++ en:temoignages:moteur_orange [2011/07/06 23:56] (Version actuelle)
daamien
@@ Ligne 1: / Ligne 1: @@
 ====== 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.//
+<note warning>
+This translation is not finished yet ! Please do not forward this text until it gets properly reviewed...
+Please send your comments at : damien@dalibo.info
+</note>
-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.
+//In the following text, Severine Aubry and Robin POUGET, who are respectively Project Manager and Database Manager at France Telecom, demonstrate their use of PostgreSQL for a major tool of they company.//
-This back office must be refreshed in 24hours/24 and 6days/7.
+[[http://www.orange.com|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/7n which means it can tolerate a day without updates.
+This part of the search engine was build between 2001 and 2002, exclusively with PostgreSQL. At that time, the Postgres project was about to released its versionn 7.4. Nowadays the project is based on PostgreSQL 8.2. Of course, the back office has seen some improvements and fixes over the years.
+In details, the engine is composed of a crawler, whose charge is to browse the Internet through a list of URLs and thousands of key sites. It follows links automatically. 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 keys.
- In other words, we can tolerate a non-updated weekly.
+From the start, the goals of the project were to have stable and robust solution with an easy maintenance and the ability to handle a huge data growth... This meant that the project had to scale freely its disk space and its number of PostgreSQL servers.
-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.
+Here's some figures to describe the whole system : More than 5 billion tuples are distributed among 160 Linux servers that run 800 PostgreSQL instance. The overall data volume is 24 Terabytes. Note that PostgreSQL is not only running on these machines, there are also applications along the databases. The Linux servers are spread over three separate datacenters, based on a logical division, called "software blocks". There are data export from these data towards others databases for various uses.
-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 entire application is extremely flexible : even if a server falls, there's no service outage because the data is replicated. Moreover there's no dependency between the elements.
-The charge of "crawler" is to retrieve URLs and associated content.
-This data is then processed through several scripts written in TCL.
+There has been in the history of the project a few minor issues that were fixed by the community, whose support was effective. Among these issues, there were :
-Data is stored in a schema with a few thousand tables. The partitioning is based on technology developed internally, based on hash key type.
+  * Data fragmentation due to massive updates. This has been fixed with the new features of PostgreSQL over the years (remember the project has been running PostgreSQL for 10 years ! )
+  * Some concern with memory management that were corrected in version 8
+  * VACUUM FULL are now almost ancient history. At first, the system needed 3 or 4 VACUUM FULL per year. Now only 1 is enough.
-The thrust of the project are from the beginning to have a solution:
+In conclusion, PostgreSQL has been a satisfaction for over 10 years. The few problems encountered were all treated with the utmost effectiveness by the community. New versions of PostgreSQL have brought solutions to these problems either with bug fixes, improvements or simplifications.
-    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:
-billion and tuples are distributed
-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:
-milliards de tuples sont ainsi répartis sur
-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]
+//[Interview realized by Jean-Paul Argudo, March-June 2011]//

Communauté francophone de PostgreSQL

Outils pour utilisateurs

Outils du site

Différences

Outils de la page