Au cœur d'[ElasticSearch](http://www.elasticsearch.org/) il y a le moteur d'indexation [Lucene](http://lucene.apache.org/), et autours de Lucene il y a plusieurs mécanismes afin de rendre le système scalable et tolèrent aux pannes. Commençons par comprendre comment Lucene fonctionne, et nous finirons par les mécanismes de distributions et de tolérances aux pannes mis en place dans ElasticSearch:

Pour comprendre Lucene, il faut comprendre ce qui se passe lorsque l'on index un texte.

Avant d'indexer cette phrase nous allons lui faire subir quelques modifications

Ce type d'analyse est très basique mais nous pourrions imaginer des choses plus complexe :

* [remplacer les mots par leur racine](http://www.elasticsearch.org/guide/reference/index-modules/analysis/stemmer-tokenfilter.html)

Une fois le texte analysé et transformé, il faut maintenant le stocker dans une structure de donnée: l'index inversé.

Si nous souhaitons que se soit le document et non l'ID qui soit retourné, il faut stocker le document à côté.

Lors de l'indexation du premier document : 'Road to a Distributed Search Engine', seulement les mots suivant avait été indexé 'road distributed search engine'.

Les mots avaient été indexé en minuscule.

Lucene est un moteur d'indexation écrit en Java qui supporte l'ensemble des fonctionnalités vu précédemment et bien plus encore.

Lucene permet d'indexer du texte mais pas que; il permet aussi d'indexer des nombres, des tableaux, des objets de géo-distances, ...

Voici la liste des [types primitifs](http://lucene.apache.org/core/3_6_1/fileformats.html#Primitive Types) indexable dans Lucene.

Si le nombre de fichier ouvert devient trop important (supérieur à la limite indiquée par 'ulimit -n' ) il est possible de grouper la plupart de ces fichiers: [compound_format avec ElasticSearch](http://www.elasticsearch.org/guide/reference/index-modules/index.html).

* Prendre en compte le nombre d'occurrence d'un mot dans un texte

Ces fichiers qui constituent [un segment](http://lucene.apache.org/core/3_6_0/fileformats.html#Segments) sont immuables, c'est à dire, il n'est pas possible de les modifier.

Dans cet exemple je liste les différents segments trouvé dans un index Lucene (en n'affichant que les .tis)

Ainsi, si une coupure de courant à lieu lorsque des données sont en RAM, au redémarrage, ElasticSearch charge en RAM le contenu du Translog. Ainsi, le nœud se retrouve dans le même état qu'avant.

Lorsque l'on index une nouvelle donnée dans ElasticSearch, on lui [spécifie un index, un type, et un ID](http://www.elasticsearch.org/guide/reference/api/index_.html).

Lorsque l'on ajoute un nœud, ElasticSearch va répartir ses shards de manière équilibrés sur l'ensemble des machines disponibles. C'est ce qu'ElasticSearch appelle du rebalancing.

Pendant la phase de rebalancing, lorsque l'on veut déplacer un shard d'un nœud A à un nœud B, ElasticSearch ne va pas supprimer les segments, il va désactiver les flushs et ainsi empêcher les commits Lucene de se faire. Le shard en cours de rebalancing n'est pas bloqué, les opérations sur ce shard sont simplement écrites dans le Translog, indexé en RAM mais pas persisté. Lorsque le transfert du shard est terminé (tous les segments Lucene ont été copié) le Translog est rejoué sur le nouveau nœud, puis ensuite est effectué le changement.

Pendant tout le temps de rebalancing, on peut continuer à indexer et rechercher de la donnée, il y a seulement une courte période de temps ou l'on bloque Lucene pour finaliser le changement.

Par contre, lors de l'indexation d'une nouvelle données, c'est le shard primaire qui récupère la requête d'indexation, index la donnée en locale et transfert la requête d'indexation aux réplicas. Chaque shards (primaire et réplicas) index la donnée.

C'est le rôle du [timeout](http://www.elasticsearch.org/guide/reference/api/index_.html#Timeout) de faire patienter la requête pendant 1 minute le temps qu'un shard primaire soit accessible, et que les autres replicas soit présent ([réglable](http://www.elasticsearch.org/guide/reference/api/admin-indices-update-settings.html)).

Chaque système distribué est régie par [le théorème du CAP](http://en.wikipedia.org/wiki/CAP_theorem).

Par défaut ElasticSearch attend avant de répondre à une requête d'indexation que [un certain nombre de réplicas](http://www.elasticsearch.org/guide/reference/api/index_.html#Write Consistency) aient indexé la donnée. C'est ce que l'on appelle une réplication synchrone.

Mais sachez que la réplication peut être [configurée en asynchrone afin de favoriser la latence](http://www.elasticsearch.org/guide/reference/api/index_.html#Asynchronous réplication)