🔍 OpenSearch – Le Guide Ultime

OpenSearch est un moteur de recherche et d'analyse de données distribué, open-source, et basé sur JSON. Il permet de stocker, rechercher, et analyser d'énormes volumes de données en quasi-temps réel.

C'est un fork (une copie) d'Elasticsearch (version 7.10.2), créé par Amazon (AWS) en 2021 suite à un changement de licence d'Elasticsearch (voir 1.2). Il est publié sous la licence Apache 2.0 (totalement open-source).

Sous le capot : Apache Lucene

Au cœur d'OpenSearch (et d'Elasticsearch, et de Solr) se trouve Apache Lucene : une bibliothèque Java de recherche d'information. Lucene est le "moteur" (il gère l'index inversé, voir 1.4), et OpenSearch est la "voiture" (une API REST JSON distribuée autour du moteur).

Cas d'Usage Principaux

On ne peut pas parler d'OpenSearch sans comprendre "la Fork" (la scission).

L'Histoire (Simplifiée)

1. Avant 2021 : Elasticsearch était le roi. Il était (principalement) sous licence Apache 2.0 (open-source). AWS (Amazon) proposait un service "Amazon Elasticsearch Service" basé sur cet open-source.
2. Le Conflit : Elastic (l'entreprise) n'aimait pas qu'AWS "profite" de leur travail sans contribuer (selon eux).
3. Jan 2021 (Le Changement) : Elastic change la licence d'Elasticsearch (v7.11+) pour la SSPL (Server Side Public License). Cette licence n'est *pas* open-source (selon l'OSI) et interdit aux fournisseurs cloud de le proposer en service géré.
4. Jan 2021 (La Réponse) : AWS (et d'autres) annoncent la création d'OpenSearch : un fork (une copie) de la dernière version Apache 2.0 d'Elasticsearch (7.10.2).

La Différence Clé (Licence = Plugins)

Aujourd'hui, ce sont deux projets parallèles. La différence *majeure* pour les développeurs est l'écosystème des "plugins" (addons).

OpenSearch est conçu pour être distribué (scalable horizontalement) et haute-disponibilité (tolérant aux pannes).

Les 5 Concepts d'Architecture

Exemple de Cluster (3 Nœuds, 1 Index, 3 Shards, 1 Replica)

CLUSTER (my-cluster)
+----------------------+ +----------------------+ +----------------------+
| NŒUD 1 (Serveur 1)   | | NŒUD 2 (Serveur 2)   | | NŒUD 3 (Serveur 3)   |
|                      | |                      | |                      |
|  [ Shard P1 ]        | |  [ Shard P2 ]        | |  [ Shard P3 ]        |
|  (Primaire 1)        | |  (Primaire 2)        | |  (Primaire 3)        |
|                      | |                      | |                      |
|  [ Shard R2 ]        | |  [ Shard R3 ]        | |  [ Shard R1 ]        |
|  (Réplique de P2)    | |  (Réplique de P3)    | |  (Réplique de P1)    |
|                      | |                      | |                      |
+----------------------+ +----------------------+ +----------------------+

(Si le NŒUD 3 tombe en panne...)
1. Le Cluster passe en statut "JAUNE" (il manque un Nœud).
2. Le Shard P3 (Primaire) est perdu.
3. OpenSearch "promeut" le Shard R3 (sur NŒUD 2) en P3.
4. L'application continue de fonctionner sans interruption.

Pour comprendre *comment* OpenSearch recherche, il faut comprendre l'Index Inversé.

L'Index Inversé (La "Magie" de Lucene)

Une base de données SQL stocke par "Document" (Ligne). C'est lent pour la recherche (il faut scanner toute la table).

Un moteur de recherche (Lucene) stocke par "Terme" (Mot). Il crée un "index" (comme à la fin d'un livre) qui mappe les Mots aux Documents.

Exemple de construction d'Index Inversé

Documents (Données entrantes) :

• Doc 1 : { "titre": "OpenSearch est rapide" }
• Doc 2 : { "titre": "OpenSearch et Kafka" }

Index Inversé (Ce que Lucene stocke, après analyse) :

Terme (Mot) | Documents
------------|-------------------
"opensearch"| [ Doc 1, Doc 2 ]
"est"       | [ Doc 1 ]
"rapide"    | [ Doc 1 ]
"et"        | [ Doc 2 ]
"kafka"     | [ Doc 2 ]

La Requête : Quand vous cherchez "OpenSearch", il n'a pas besoin de scanner les documents. Il va direct au terme "opensearch" et renvoie [Doc 1, Doc 2]. C'est *instantané*.

On ne parle pas SQL à OpenSearch. On lui parle via une API RESTful (JSON sur HTTP). Les verbes (GET, POST, PUT) sont utilisés pour manipuler les données.

Le "Bulk" (_bulk) - L'API d'Ingestion

Ne *jamais* indexer des documents un par un (POST /_doc) en production (c'est trop lent). On utilise l'API _bulk.

# POST /_bulk
# (Le format est "Action" (meta), "Donnée" (optionnel), "Action", "Donnée"...)
# (Ce n'est PAS du JSON valide, c'est du "newline-delimited JSON")

{ "index" : { "_index" : "logs", "_id" : "1" } }
{ "message" : "Log A", "status": 200 }
{ "index" : { "_index" : "logs", "_id" : "2" } }
{ "message" : "Log B", "status": 500 }
{ "delete" : { "_index" : "logs", "_id" : "3" } }

Problème : Si un utilisateur cherche "renard", doit-il trouver "Renards" ? Si je cherche "saute", doit-il trouver "sauter" ?
Réponse : Oui. C'est l'Analyse (Analysis). C'est le processus qui transforme le texte (riche) en "termes" (simples) pour l'index inversé.

Le Processus d'Analyse

Un Analyzer (Analyseur) est une chaîne de 3 étapes :

1. Character Filters (Filtres de Caractères) : Nettoyage brut (ex: "enlever le HTML").
2. Tokenizer (Découpeur) : Découpe le string en "tokens" (mots). (Ex: standard découpe sur l'espace/ponctuation).
3. Token Filters (Filtres de Jetons) : Nettoie les tokens (ex: lowercase, stop (enlève "le", "la"), stemming ("sauter" -> "saut")).

Exemple (standard analyzer)

Texte d'entrée: "Le Quick Brown-Fox saute."

1. Character Filters: (Aucun)
2. Tokenizer (Standard): [ Le, Quick, Brown-Fox, saute ]
3. Token Filters (Lowercase): [ le, quick, brown-fox, saute ]
4. Token Filters (Stop words): [ quick, brown-fox, saute ]
5. Token Filters (Stemming): [ quick, brown-fox, saut ]

Termes stockés dans l'Index Inversé: [ "quick", "brown-fox", "saut" ]

text vs keyword (Mapping)

C'est la base du "Mapping". Quand vous définissez un champ de type "string" :

Le Query DSL (Domain Specific Language) est le "langage" (en JSON) que vous envoyez dans le *body* d'une requête _search pour trouver des données.

Contexte query vs filter (Performance)

C'est la distinction la plus importante :

• Contexte query : "Est-ce que ça *matche* bien ?". Calcule un score de pertinence (_score). (Recherche Full-Text, floue).
• Contexte filter : "Est-ce que ça *matche* (Oui/Non) ?". Ne calcule pas de score. (Recherche exacte). C'est beaucoup plus rapide et *cacheable*.

La Structure : bool (Booléen)

Pour combiner des requêtes, on utilise la clause bool.

Exemple (POST /products/_search)

Objectif : Trouver des "chaussures rouges", qui sont en stock, et qui coûtent moins de 50.

{
  "query": {
    "bool": {
      
      "must": [
        // Contexte Query (calcul de score)
        // (Recherche "chaussure" OU "rouge" dans la description)
        { "match": { "description": "chaussures rouges" } } 
      ],
      
      "filter": [
        // Contexte Filter (rapide, pas de score)
        { "term": { "en_stock": true } },
        { "range": { "prix": { "lt": 50 } } } // lt = Less Than
      ]
      
    }
  }
}

Il existe des dizaines de types de requêtes. Voici les 4 plus importantes.

.keyword : C'est quoi ?
Par défaut, OpenSearch crée 2 versions d'un champ string ("nom": "Mon Article") :
1. nom (Type text) -> (Analyzé : [mon, article]) -> Pour la recherche match.
2. nom.keyword (Type keyword) -> (Non-Analyzé : "Mon Article") -> Pour la recherche term et les agrégations.

Les agrégations (aggs) sont la *deuxième* "killer feature" d'OpenSearch. Elles permettent de faire de l'analytique complexe (similaire à GROUP BY en SQL, mais en beaucoup plus puissant).

Il y a 2 types d'agrégations :

Exemple : Ventes moyennes par catégorie

Objectif : "Donne-moi le prix moyen (avg) par catégorie (terms) ?"

POST /ventes/_search
{
  "size": 0, // (On ne veut pas les "hits" (documents), juste l'agrégation)
  
  "aggs": {
    
    "par_categorie": {  // (Nom de notre 1ère agrégation)
      
      "terms": { // (Type 2: Bucket)
        "field": "categorie.keyword" // (GROUP BY categorie)
      },
      
      "aggs": { // (Sous-agrégation, imbriquée)
        "prix_moyen": { // (Nom de la 2e agrégation)
          "avg": { // (Type 1: Metric)
            "field": "prix"
          }
        }
      }
      
    }
  }
}

OpenSearch Dashboards est l'interface web (UI) officielle pour OpenSearch. C'est un fork de Kibana 7.10.2 (sous licence Apache 2.0).

C'est l'outil de visualisation de la stack O-LK (OpenSearch-Logstash-Kibana).

Les 3 Écrans Principaux

KQL (Kibana Query Language)

Dans la barre de recherche "Discover", on n'utilise pas le Query DSL (JSON). On utilise KQL, une syntaxe simplifiée :

# Syntaxe KQL (simple)
status: 500 AND (response_time > 1000 OR user.name: "alice")

# (Est converti en Query DSL 'bool' en arrière-plan)

Les données (logs, métriques) doivent être *envoyées* à OpenSearch. C'est le "pipeline d'ingestion". On utilise des "shippers" (agents) et des "processors" (ETL).

La Stack O-LK (ex-ELK)

Data Prepper (Le "plugin" natif)

Data Prepper est le "plugin" (projet) natif d'OpenSearch pour le traitement de données (l'équivalent de Logstash). Il est conçu pour être scalable (ex: sur Kubernetes).

Exemple de Pipeline (data-prepper.yml)

log-pipeline:
  # 1. INPUT (Source)
  source:
    http:
      path: "/logs"
      
  # 2. PROCESSORS (Transformation)
  processor:
    - grok: # (Parse un log Apache)
        match:
          log: [ '%{COMMONAPACHELOG}' ]
    - geo_ip: # (Enrichit l'IP)
        source: "clientip"

  # 3. SINK (Destination)
  sink:
    - opensearch:
        hosts: [ "https://localhost:9200" ]
        index: "apache-logs-%{yyyy-MM-dd}"

Le plus gros avantage de la licence Apache 2.0 d'OpenSearch est que les "plugins" critiques (qui étaient payants ou "open-core" chez Elastic) sont 100% open-source et inclus.