Une histoire d'optimisation d'un cluster Elasticsearch.

Le problème chez Netflix venait d'une mauvaise allocation des shards des indices, tous les indices avaient le même nombre de shards et donc certains noeuds se retrouvent à héberger des shards contenant des millions de documents.

Leur stratégie a été de distribuer les documents non pas par type mais par date de création (time buckets) en utilisant des index template pour la création automatique et des alias pour la recherche (comme pour l'ingestion des logs donc).

Un REX sur la gestion des pics d'affluence à L'Équipe pendant les coupes du monde.

Plusieurs conseils:

• code freeze: aucun déploiement avant la coupe de monde
• auto-scaling: entre 10 et 120 pods sur leur cluster Kubernetes
• observabilité: Application Performance Management (APM) et une suite Elasticsearch, Logstash, Kibana (ELK)

A certains moments, ils ont encaissé plus de 1 million de pages vues à la minutes!

Très bonne explication des différences entre Nested fields et Object fields pour stocker des tableaux d'objets avec Elasticsearch.

Si on souhaite faire des recherches sur plusieurs propriétés contenues dans ces tableaux, alors on devra utiliser le type nested car sinon ES "applatit" les champs.

{
  "authors": [
    { "name": "Gustavo Llermaly", "age": "32", "country": "Chile" },
    { "name": "John Doe", "age": "20", "country": "USA" }
  ]
}

Sans préciser le type nested, cela sera indexé de cette manière:

{
  "authors.name": ["Gustavo Llermaly", "John Doe"],
  "authors.age": [32, 20],
  "authors.country": ["Chile, USA"]
}

Un très bonne comparaison entre les performances de recherches d'Elasticsearch et MongoDB et le résultat est sans appels.

Sur la recherche, Elasticsearch est jusqu'à 20x plus rapide que MongoDB.

Sur les aggrégations, Elasticsearch est jusqu'à 38x plus rapide que MongoDB.

Sur l'insertion, MongoDB est 1.20x plus rapide que Elasticsearch.

Sur le parcours des données, Elasticsearch offre des performances stables quand MongoDB passe de 5 à 60 sec pour récupérer les derniers documents d'une collection.

Sur l'espace disque, MongoDB occupait 2x plus d'espace avec les mêmes données. (sans index!)

Ces benchmarks ont été effectués sur de grosses collections (dizaines de millions) mais les différences performances se font aussi sentir sur de plus petites collections.

Les performances seules ne doivent pas guider le choix mais aussi les features, par exemple les limitations d'Elasticsearch sont les suivantes:

• Near Realtime Search: les documents ne sont pas disponible immédiatement dans le search après écriture
• Pas de modification possible du type d'un champs d'une collection (int vers string par exemple)
• Pas de transactions
• Pas de pseudo-relationnel comme en MongoDB

Elastic propose des outils qui indexent les contenus des outils comme Slack, Gmail, Drive et autres pour pouvoir faire de la recherche dedans ensuite.

Ça me fait penser à SteamPipe mais plutôt pour des humains que des API (Steampipe permet des requêtes SQL quand Elastic supporte le langage naturel)

Une alternative à ES qui est un fork de Sphinx Search.

A priori ils proposent de meilleurs performances à la recherche et à l'indexation que Elasticsearch en plus de supporter une syntax SQL.

PRO:

• meilleurs perfs de recherche et d'insertion
• support SQL (syntax et clients existants)
• 100% open source (GPLv2 + Apache 2)
• recherche temps-réel (max 1sec avec ES)

CON:

• obligé de définir le schéma à l'avance
• moins de ressources dispo car moins populaire
• robustesse du scaling à prouver
• pas complètement intégré avec les autres outils de la suite Elastic

Si vous avez besoin d'ajouter un moteur de recherche et que vous n'avez ni besoin de fonctionnalités très avancé, ni de scale à plusieurs centaines de millions de documents alors c'est une alternative à creuser.

Une extension qui permet de visualiser et d'intéragir avec son cluster Elasticsearch depuis son navigateur.