Le coût énergétique d’indexation des données

Un des précédents articles « Le coût des données n'est pas celui que l'on croit... » se référait à l’obésité des données et à ses coûts cachés. Un point technique particulier, le « padding », fut abordé. Cet article aborde un sujet peu abordé dans la littérature: le coût énergétique de l’indexation. 

Introduction et rappel(s)

« Lorsque vous effectuez une requête sur une application web, qu’elle soit de type Google/Bing ou interne à votre entreprise, vous vous attendez en tant qu’utilisateur à obtenir :

  • au moins une réponse,
  • à bénéficier d’une « rapidité de réponse» subjectivement admis pour être inférieure à 1 seconde,
  • une «puissance » dans la réponse, c'est à dire une « pertinence ».

Vous oubliez sans doute qu’un coût énergétique est associé à cette recherche.

Pour faire simple, il faut de l’énergie pour non seulement faire fonctionner mais aussi coordonner les ordinateurs nécessaires à fournir la réponse à la demande de l’utilisateur. Plus la quantité de données interrogée est importante, plus la réponse fournie doit être pertinente, plus le coût énergétique augmente. Voici trois éléments indicatifs :

  • en moyenne, « tout compris », cette énergie consommée lors d’une requête correspond à la consommation électrique d’une ampoule à économie d’énergie durant 1 H,
  • rien que pour une société comme Google, on estime sa consommation annuelle entre 1900 (source comptes Google) et 2500 Mégawatt (incluant production propre) par an, soit d’avantage qu’une centrale nucléaire,
  • deux requêtes sur Google généreraient 14 grammes d'émission de carbone, soit quasiment l'empreinte d'une bouilloire électrique (15 g) selon Alex Wissner-Gross (données 2009).

En conséquence, si pour n demandes utilisateur, les ordinateurs « travaillent » moins en effectuant moins d’opérations internes (se résumant à moins de temps de calcul CPU, moins de taille disque, à des temps de réponse meilleurs à ressources identiques…), on gagne en consommation énergétique et par conséquence on baisse les coûts.

Mutations importantes en cours

Par-delà les mutations technologiques en cours, qu’elles soient technologiquement propriétaires ou non, le sujet du « coût de l’indexation » des données est un vrai sujet qui doit être pris sérieusement en compte dans le développement d’applications. C’est plus particulièrement vrai pour celles qui manipulent de grandes quantités de données ou « big data ».

Aujourd’hui, avec des technologies conventionnelles ou implémentées de façon standard, la taille des index croit de façon exponentielle par rapport aux données sous-jacentes. Ainsi, si on trouve un article qui nous intéresse, pour trouver un article similaire, c'est-à-dire où l’on affine la recherche avec un requête supplémentaire à n termes, cela nécessite un calcul combinatoire de l’ordre de 2n-1 -1 pour n>1 !

Ainsi pour réduire la consommation énergétique il faut soit

-       Travailler à réduire la taille des données. On n’en prend pas trop le chemin puisque aujourd’hui il y a sur terre 500 Exabytes de données soit 500 milliards de Gigabytes, soit encore 13 fois piles de livres entre la Terre à Pluton et que l’on dématérialise de plus en plus d’informations, de processus de travail, … !

-       Travailler à réduire la taille des index.

-       Travailler à réduire le nombre de requêtes moyennes.

Les solutions qui offrent une « recherche instantanée » avaient l’objectif initial de réduire la consommation énergétique d’une requête en anticipant la demande de l’utilisateur. On abordera plus loin les notions de « cache », les notions de statistiques et de combinatoires qui vont penser dans un premier temps que la « recherche instantanée » offre un gain énergétique. En pratique, très rares sont ceux qui obtiennent un gain

Deux axes principaux d’optimisation

Deux grands axes principaux d’optimisation se dégagent :

  • celui lié aux capacités d’indexation en provenance de l’infrastructure ;
  • celui lié à la façon dont on demande l’information au niveau applicatif.

On peut s’intéresser aux éléments suivants pour déterminer les axes d’action :

  • Ratio : Taille des données / Taille de l’index               [Ratio VT]
  • Tableau de « Taille d’une requête en nb de termes / Temps de réponse (en millisecondes)       * 1000 »                                    [Ratio TR] (**)
  • « Temps Requête en mode cache » / « Temps Requête initiale »                                                                                         [Ratio CRi](***)

(**): Un terme est un mot, une locution. Exemple de 2 termes : « Abeille Bourbon » pour trouver le « remorqueur de haute mer » ; exemple de trois termes « Cul de Sac » qui en fait ne fut qu’une locution « cul-de-sac » pour une bonne solution d’indexation.

(***) : le « cache » représente l’information qui a déjà été demandée et qui demeure latente pour être disponible sans devoir effectuer une nouvelle requête. Le « cache web » est décrit sur cet article de Wikipédia

Ces trois ratios permettent  de comparer simplement la qualité d’une stratégie d’indexation existante comme nous allons le montrer plus bas.

Axe Infrastructure - Ratio VT

Le Ratio VT permet de mesurer entre elles les « taux de compression » d’une technologie ou d’une stratégie d’indexation. L’objectif ici est de réduire au maximum la taille d’un index pour les besoins listés.

Nous ne souhaitons pas entrer ici dans une logique de positionnement des technologies entre elles sur un « Cadran » car la « technologie seule » ne fait pas tout. Les faiblesses d’une technologie donnée peut en effet être compensée par une stratégie d’indexation optimisée ou applicative ciblée. On peut toutefois fournir une liste non exhaustive de solutions existantes : Google Search Appliance® (qui est fort différent du Google public), Microsoft Search Server®, Microsoft Fast® pour des environnements SharePoint®, les solutions Open Source utilisant l’indexation standard ou « texte riche » MySQL ou bien encore Oracle SQL Server …

On part du principe que la mesure du Ration VT est prise juste après la création d’un index. La taille d’un fichier d’index peut en effet varier significativement dans le temps ou se corrompre (partiellement).

Ce ratio VT a tendance à augmenter exponentiellement avec l’augmentation de la volumétrie des données si du moins on veut garder l’ensemble des possibilités.

Il est autour de 1 pour des technologies de base.

Plus il se rapproche de 0, plus il y un besoin d’amélioration.

Il peut être de 2 pour des technologies optimisées ou des solutions qui peuvent se permettre une « perte volontaire d’information d’indexation ». Des technologies permettent de « débruiter » c'est-à-dire supprimer les « informations parasites » ou « inutiles » permettant à ce ratio d’encore augmenter.

Pour les technologies qui n’utilisent plus la notion d’index, il faut prendre la taille prise en mémoire par la « zone de références ».

Résumé énergétique : Plus le ratio VT est élevé moins il y a de consommation d’énergie.

Axe Infrastructure et Axe Applicatif - Ratio TR

L’intérêt du second ratio, TR, réside principalement dans une étude de 1 à 64 termes. Il permet de comparer le comportement d’une technologie d’indexation ou d’une stratégie d’indexation d’un point de vue principalement « combinatoire ».  Ceci est particulièrement vrai pour les serveurs SQL utilisant des champs riches indexés.

Elle l’est moins avec un moteur de type Google par exemple qui s’arrête aux 32 premiers « termes » afin de réduire l’effet combinatoire qui pénalise ses temps de réponse et de privilégier le « gain statistique fournis par des utilisateurs humains». Il est en effet important de réduire au maximum cette problématique combinatoire par la « pertinence « statistique humaine » des demandes des utilisateurs ». En plus lever l'ambigüité par intersection de mots clefs, cette stratégie n'est plus très efficace dès lors que l'on dépasse 4 ou 5 termes, la probabilité de trouver un article diminuant drastiquement, même avec une base de l'ordre de quelques milliards d'articles.

Le corolaire de l’approche de type Google est qu’elle a tendance à enfermer une demande utilisateur dans ce que les autres personnes ont demandé plutôt que sur l’information brute recherchée. De plus, l’objectif de faire « cliquer sur un lien sponsorisé », augmente cette tendance à l’effet d’entonnoir ou « funneling ».

Plus ce ratio s’approche de 0, voire devient supérieur à 1, plus la stratégie d’indexation (cache inclus) est performante.

Pour un moteur de recherche mot clef traditionnel, ce ratio diminue linéairement avec le nombre de termes de la requête, généralement en 0 (n) du nombre de termes de la requête, soit 0,1 à 0,5 pour les mieux optimisés en cache comme Google ou Bing.

Pour une approche ou technique contextuelle, le temps de réponse à tendance à devenir quasi constant au-delà de 2-3 termes, indépendamment du nombre de termes dans la requête, donc ce ratio augmente linéairement en 0(n), du nombre de la requête.

Un expert plutôt que ce ratio préfèrera étudier la fonction EFF (n,t), avec n =      nombre de termes de la requête, et t = temps de réponse, qui est sans doute plus significative.

Ce type d’étude permet en tout cas de se poser des questions au niveau applicatif sur la façon dont des requêtes sont envoyées. Faut-il concaténer plusieurs petites requêtes ? Quelle requête faut-il envoyer dans « ce contexte » pour réduire un temps de réponse ? Faut-il éclater au contraire une longue requête en plusieurs ? Pour certaines technologies ces questions ne se posent pas puisqu’il n’y a plus d’indexation mais une « référencement contextuel ». Ainsi un « article similaire » est « proche contextuellement » et il n’est pas besoin d’effectuer un calcul combinatoire associé à une probabilité.

Résumé énergétique : L’analyse de la suite de ratios TR permet au niveau applicatif de rechercher une moindre consommation énergétique.

Axe Infrastructure et Axe Applicatif - Ratio CRi

Le troisième ratio, CRi, permet de définir la qualité d’une stratégie de cache contextuelle.

Un  CRi de 1 indique qu’il n’existe pas de stratégie de cache tant au niveau du serveur que localement.

Un CRi nul n’est pas possible (singularité) mais s’en approcher indique une stratégie locale de cache de plus en plus parfaite.

Plus le CRi s’approche de zéro plus la stratégie de cache est globalement efficace. Une stratégie de cache d’indexation bien configurée se situe aujourd’hui vers 0,5 ou 0,4.

Le ratio CRi est particulièrement intéressant lorsque l’on effectue des recherches dites « similaires » ou « des p@reils(1) » ((1) terme repris à M. David Hebert sur www.pareils.fr).

Ainsi, si l’on entre « Abeille Bourbon », la recherche pour « Abeille Flandre » de la même classe de remorqueur devrait être plus rapide. Il doit en être de même si l’on demande un article similaire à « remorqueur ». Un CRi faible est attendu.

Un CRi qui reste constant voire qui augmente avec le nombre de requêtes sur un nombre suffisant de requêtes montre que la stratégie d’indexation est ou non « contextuelle ».

Une adaptation du processus d’indexation peut permettre de moins solliciter les ressources physiques selon les besoins applicatifs. Il n’est donc pas nécessaire de remettre en cause l’infrastructure d’indexation en tant que telle. La conséquence est une baisse de la consommation d’énergie.

L’analyse du ratio CRi permet de discerner tant au niveau infrastructure qu’applicatif la « qualité » des résultats fournis à énergie constante.

Résumé énergétique : Plus le ratio CRi s’approche de 0, moins d’énergie est consommée pour une requête donnée.

Axe Applicatif – Deux Exemples

L’analyse du comportement applicatif par rapport aux besoins d’indexation, ou réciproquement, est important pour rechercher des gains de performances et des gains énergétiques.

Premier exemple : il vaut mieux aller chercher une information d’abord sur le cache local d’indexation (on évite ainsi les coûts de transit d’information et donc d’énergie) puis sur le cache serveur (l’immédiateté de l’information signifie corolairement une quasi absence de besoin énergétique) puis ensuite effectuer une demande d’indexation serveur pour enfin demander une ré-indexation (c’est de très loin le processus qui coûte le plus cher énergétiquement).

Ainsi toute technologie ou stratégie de découverte d’information qui réduit l’accès à un serveur est à privilégier. On oublie en effet que pour parvenir à ce serveur d’autres entités consommatrices d’énergie interviennent  tels routeurs, éléments 3G ou Wifi, serveurs de répartition de charge, etc. La chaîne de déperdition énergétique n’est pas uniquement basée sur le serveur cible.

Second exemple : pourquoi aller rechercher une information qui n’a pas été préalablement contextualisée ? En effet, si l’information n’a pas été suffisamment désambiguïsée, il faudra effectuer d’autres requêtes et donc augmenter les coûts énergétiques. Ainsi pour obtenir des « articles similaires » ou « des pareils », il faut compter quelques 2500 requêtes traditionnelles alors qu’une dizaine au grand maximum seraient normalement suffisantes.

« L’Indexation continue des données » 

Un coût caché énergétique réside dans le besoin d’indexation continue des données et en particulier aux mécanismes de « ré-indexation ».

Rares sont les technologies qui permettent de s’affranchir de ré-indexations couteuses. Ce point en lui-même pourrait faire l’objet d’un article écrit par un spécialiste des bases de données SQL utilisant des champs riches indexés.

Conclusion Générale

La généralisation de la dématérialisation des documents papiers, l’augmentation des procédures dématérialisées, la percée des réseaux sociaux et du « cloud » augmente le nombre des éléments qu’un utilisateur souhaite pouvoir retrouver et le coût énergétique pour les retrouver (stratégies d’indexation).

Ce qui a un coût insignifiant pour un seul utilisateur recherchant une seul information s’avère couteux pour un plus grand nombre d’utilisateurs recherchant régulièrement des informations et devient fortement énergivore à plus grande échelle encore. On peut même dire qu’il représente un danger dans une logique de développement durable si le sujet de l’indexation des données n’est pas traité sérieusement à tous les niveaux.

L’optimisation des coûts énergétiques d’une stratégie d’indexation n’intéresse pas que les grands moteurs du web ! En pratique toute société qui utilise de simples serveurs SQL peuvent générer de sérieuses économies directes (énergie) ou indirectes comme trouver plus rapidement l’information pertinente. Il suffit d’analyser les stratégies ou technologies d’indexation utilisées pour  progressivement les faire évoluer.

Dans certains cas, des changements radicaux peuvent apporter un ROI en quelques semaines. Nous faisons ici référence aux stratégies dites « contextuelles » qui permettent de retrouver plus rapidement et avec moins de requêtes une information données dans un « corpus vaste de données ». 

Nous espérons que cet article aura attiré votre attention sur les coûts énergétiques d’indexation tant au niveau de l’infrastructure qu’applicatif, et qu’il existe de nombreux moyens pour les réduire.

Technologie: 
Catégorie: 

Commentaires

Microsoft Research a mené une recherche sur Bing. Le résultat est proche d'une loi de Pareto : en affichant 20 % de résultats en moins on économise 80 % de l'énergie nécessaire à la requête. Une approche complémentaire des optimisations liées à l'indexation.

Ajouter un commentaire