Découvrez les différentes stratégies de vérification de données requises lors de la synchronisation de donnés entre Elasticsearch et autres bases de données.

<html><head></head><body><p>Elasticsearch est parfois utilis&#xE9; en parall&#xE8;le d&apos;autres bases de donn&#xE9;es. Il est alors souvent compliqu&#xE9; de mettre en place des solutions de <a href="https://en.wikipedia.org/wiki/Two-phase_commit_protocol">validation en deux phases</a> en raison de l&apos;absence de prise en charge des transactions par tous les syst&#xE8;mes concern&#xE9;s. Selon votre utilisation, vous pourrez donc devoir v&#xE9;rifier que les donn&#xE9;es existent dans les deux entrep&#xF4;ts de donn&#xE9;es, dont l&apos;un joue le r&#xF4;le de r&#xE9;f&#xE9;rentiel d&apos;int&#xE9;grit&#xE9;.
</p><p>En tant qu&apos;ing&#xE9;nieurs charg&#xE9;s du support chez Elastic, on nous demande souvent quelle est la meilleure fa&#xE7;on de structurer les donn&#xE9;es pour en permettre la v&#xE9;rification ou tout simplement s&apos;il existe une m&#xE9;thode permettant une v&#xE9;rification efficace des donn&#xE9;es. Cet article pr&#xE9;sente&#xA0;quelques exemples de complexit&#xE9; variable que nous avons observ&#xE9;s ou sur lesquels nous avons travaill&#xE9;. Ils v&#xE9;rifient qu&apos;Elasticsearch contient les donn&#xE9;es n&#xE9;cessaires issues d&apos;une base de donn&#xE9;es comme PostgreSQL.
</p><h2>Mod&#xE9;lisation des donn&#xE9;es pour la v&#xE9;rification</h2><p>La fa&#xE7;on dont sont stock&#xE9;es vos donn&#xE9;es, que ce soit dans ou en dehors d&apos;Elasticsearch, influe consid&#xE9;rablement sur la difficult&#xE9; de la v&#xE9;rification. Le premier point &#xE0; d&#xE9;finir est la port&#xE9;e de la v&#xE9;rification :
</p><ul>
	<li>Suffit-il de v&#xE9;rifier l&apos;existence d&apos;un document ?</li>
	<li>Un processus interne vous impose-t-il de v&#xE9;rifier l&apos;int&#xE9;gralit&#xE9; du contenu des documents ?</li>
</ul><p>Cette d&#xE9;cision n&apos;est pas sans cons&#xE9;quence sur la complexit&#xE9; de l&apos;op&#xE9;ration.<br>
</p><h2>V&#xE9;rification de l&apos;existence</h2><p>Rassurez-vous, il ne s&apos;agit pas l&#xE0; d&apos;analyser un grand principe philosophique, mais simplement de se poser la question suivante : &#xAB; Tous les documents existent-ils dans Elasticsearch ? &#xBB;
</p><p>Elasticsearch permet de v&#xE9;rifier l&apos;existence d&apos;un document de nombreuses fa&#xE7;os, mais vous devez parfaitement comprendre le processus utilis&#xE9;. En effet,&#xA0;<a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/near-real-time.html" target="_blank">Elasticsearch effectue des recherches en quasi-temps r&#xE9;el</a>, mais la r&#xE9;cup&#xE9;ration des documents se fait, elle, bien en temps r&#xE9;el. Cela signifie qu&apos;apr&#xE8;s avoir &#xE9;t&#xE9; index&#xE9;, un document peut ne pas &#xEA;tre visible dans les recherches, tout en &#xE9;tant accessible par des requ&#xEA;tes directes de type GET.
</p><h3>Un par un</h3><p>Dans les d&#xE9;ploiements de taille r&#xE9;duite, l&apos;approche la plus simple consiste &#xE0; &#xE9;mettre des requ&#xEA;tes <code>HEAD</code> sur chaque document, puis &#xE0; v&#xE9;rifier que le code de r&#xE9;ponse HTTP n&apos;est pas 404 (page ou document introuvable).
</p><pre class="prettyprint">HEAD /my_index/my_type/my_id1
</pre><p>En cas de r&#xE9;ussite, la requ&#xEA;te renverrait des en-t&#xEA;tes similaires &#xE0; ceux-ci :
</p><pre class="prettyprint">HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
</pre><p>En cas d&apos;absence, la r&#xE9;ponse est presque identique, au code de r&#xE9;ponse pr&#xE8;s :
</p><pre class="prettyprint">HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
</pre><p>Cette m&#xE9;thode impose d&apos;&#xE9;mettre <code>N</code> requ&#xEA;tes sur un index dont vous pensez qu&apos;il contient&#xA0;<code>N</code> documents. Comme vous vous en doutez, elle n&apos;est pas adapt&#xE9;e lorsque N est un nombre trop important.
</p><h3>Traitement par lots</h3><p>Vous pouvez &#xE9;galement &#xE9;mettre ces requ&#xEA;tes par lot &#xE0; l&apos;aide de l&apos;API Multi GET : <code>_mget</code>.
</p><pre class="prettyprint">GET /my_index/my_type/_mget
{
  &quot;ids&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
}
</pre><p>Une autre approche &#xE9;quivalente consiste &#xE0; rechercher les ID et &#xE0; renvoyer le nombre attendu.
</p><pre class="prettyprint">GET /my_index/_refresh
GET /my_index/my_type/_search
{
  &quot;size&quot;: 2,
  &quot;query&quot;: {
    &quot;ids&quot;: {
      &quot;values&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
    }
  }
}
</pre><p>Tout d&apos;abord, nous appelons l&apos;API <code>_refresh</code> pour nous assurer que l&apos;ensemble de l&apos;index peut faire l&apos;objet de recherches. Cette action permet de r&#xE9;soudre le probl&#xE8;me du &#xAB; quasi-temps r&#xE9;el &#xBB;. Dans le cadre d&apos;une recherche classique, vous ne devez pas proc&#xE9;der ainsi, mais cette m&#xE9;thode s&apos;av&#xE8;re tout &#xE0; fait logique ici ! Il est probable que le traitement de v&#xE9;rification ait lieu en une seule fois. L&apos;appel de <code>_refresh</code>&#xA0;<i>une fois</i> au d&#xE9;but de la t&#xE2;che est donc suffisant tant que vous ne v&#xE9;rifiez pas la pr&#xE9;sence de donn&#xE9;es ajout&#xE9;es apr&#xE8;s le d&#xE9;marrage du processus.
</p><p>La gestion des requ&#xEA;tes est ainsi am&#xE9;lior&#xE9;e, mais n&#xE9;cessite encore de la pr&#xE9;paration. De plus, chaque document sera renvoy&#xE9;, ce qui signifie du temps de traitement suppl&#xE9;mentaire.
</p><h3>Recherche, puis traitement par lots</h3><p>Une fois arriv&#xE9; au traitement par lots, il est fr&#xE9;quent d&apos;essayer de contourner le probl&#xE8;me en le divisant. Par exemple, en d&#xE9;terminant quels documents sont absents, puis en recherchant ces documents :
</p><pre class="prettyprint">GET /my_index/_refresh
GET /my_index/my_type/_search
{
  &quot;size&quot;: 0,
  &quot;query&quot;: {
    &quot;ids&quot;: {
      &quot;values&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
    }
  }
}
</pre><p>Le nombre renvoy&#xE9; par la valeur <code>hits.total</code> devrait correspondre au nombre que vous attendez. Dans cet exemple simple, cette valeur devrait &#xEA;tre <code>2</code>. Si ce n&apos;est pas le cas, deux possibilit&#xE9;s s&apos;offrent &#xE0; vous :
</p><ol>
	<li>Rechercher tous les ID et les renvoyer en sp&#xE9;cifiant la taille appropri&#xE9;e, puis rechercher l&apos;aiguille manquante dans la botte de foin.</li>
	<li>Revenir &#xE0; l&apos;exemple <code>_mget</code> ci-dessus et faire la m&#xEA;me chose, &#xE0; savoir d&#xE9;terminer quel ID est manquant.</li>
</ol><h3>Il doit y avoir une meilleure m&#xE9;thode</h3><p>Ce traitement long ou en deux &#xE9;tapes peut ne pas &#xEA;tre tr&#xE8;s efficace avec les grands volumes. Vous posez ainsi une question co&#xFB;teuse en ressources, qui n&apos;est peut-&#xEA;tre pas la bonne.
</p><p>Et si vous renversiez la question pour ne pas rechercher tout ce qui existe, mais uniquement ce qui est manquant&#xA0;? Il est difficile de rechercher ce qui est absent. C&apos;est m&#xEA;me impossible, car les donn&#xE9;es n&apos;existent pas. Pour autant, nous pouvons utiliser les agr&#xE9;gations pour r&#xE9;pondre &#xE0; cette question si vous structurez vos donn&#xE9;es de la mani&#xE8;re appropri&#xE9;e.
</p><p><span style="line-height: 1.6em; background-color: initial;">Dans la plupart des cas, la v&#xE9;rification est li&#xE9;e au SQL, car les cl&#xE9;s primaires et &#xE9;trang&#xE8;res bas&#xE9;es sur des entiers sont tr&#xE8;s utilis&#xE9;es dans ce langage. M&#xEA;me si vous n&apos;utilisez pas ces ID num&#xE9;riques pour la valeur _id d&apos;Elasticsearch, indexez-les sous forme d&apos;entiers&#xA0;</span><a href="/blog/support-in-the-wild-my-biggest-elasticsearch-problem-at-scale">en activant les Doc values</a><span style="line-height: 1.6em; background-color: initial;"> (elles sont activ&#xE9;es par d&#xE9;faut dans les versions 2.x et sup&#xE9;rieures d&apos;ES). Par exemple :</span><br>
</p><pre class="prettyprint">POST /my_index/my_type/my_id1
{
  &quot;id&quot;: 1,
  &#x2026;
}
</pre><p>Le nom du champ n&apos;a aucune importance, mais notez toutefois qu&apos;il ne s&apos;agit pas de <code>_id</code>, qui est un champ de m&#xE9;tadonn&#xE9;es r&#xE9;serv&#xE9; dans Elasticsearch. Une fois l&apos;indexation de cette valeur commenc&#xE9;e, il devient tr&#xE8;s simple de trouver les donn&#xE9;es manquantes avec des histogrammes :
</p><pre class="prettyprint">GET /my_index/my_type/_search
{
  &quot;size&quot;: 0,
  &quot;aggs&quot;: {
    &quot;find_missing_ids&quot;: {
      &quot;histogram&quot;: {
        &quot;field&quot;: &quot;id&quot;,
        &quot;interval&quot;: 1,
        &quot;min_doc_count&quot;: 0
      },
      &quot;aggs&quot;: {
        &quot;remove_existing_bucket_selector&quot;: {
          &quot;bucket_selector&quot;: {
            &quot;buckets_path&quot;: {
              &quot;count&quot;: &quot;_count&quot;
            },
            &quot;script&quot;: {
              &quot;inline&quot;: &quot;count == 0&quot;,
              &quot;lang&quot;: &quot;expression&quot;
            }
          }
        }
      }
    }
  }
}
</pre><p>Cette action a deux cons&#xE9;quences :
</p><ol>
	<li>Elle r&#xE9;alise un histogramme &#xE0; partir du champ num&#xE9;rique <code>id</code> avec un pas de <code>1</code> entre chaque valeur. Vous allez ainsi d&#xE9;terminer tous les entiers compris entre chaque <code>id</code> (par ex., 1 - 5 donnerait un histogramme de 1, 2, 3, 4, 5).</li>
	<li>Elle supprime toute cat&#xE9;gorie d&apos;histogramme qui contient des donn&#xE9;es &#xE0; l&apos;aide d&apos;un s&#xE9;lecteur de cat&#xE9;gorie (bucket selector), disponible uniquement dans Elasticsearch 2.0 et versions ult&#xE9;rieures.</li>
</ol><p>En supprimant ce qui existe, vous gardez uniquement ce qui n&apos;existe pas. Ce r&#xE9;sultat peut se pr&#xE9;senter sous la forme suivante :
</p><pre class="prettyprint">{
  &quot;took&quot;: 4,
  &quot;timed_out&quot;: false,
  &quot;_shards&quot;: {
    &quot;total&quot;: 5,
    &quot;successful&quot;: 5,
    &quot;failed&quot;: 0
  },
  &quot;hits&quot;: {
    &quot;total&quot;: 5,
    &quot;max_score&quot;: 0,
    &quot;hits&quot;: []
  },
  &quot;aggregations&quot;: {
    &quot;find_missing_ids&quot;: {
      &quot;buckets&quot;: [
        {
          &quot;key&quot;: 4,
          &quot;doc_count&quot;: 0
        }
      ]
    }
  }
}
</pre><p>Pour un petit index de 5 documents, dont nous connaissons la taille gr&#xE2;ce &#xE0; <code>hits.total</code>, nous voyons que le document dont la valeur <code>id</code> est 4 est manquant.
</p><p>Et c&apos;est tout : si vous pouvez cr&#xE9;er un histogramme &#xE0; partir de la cl&#xE9; unique du document, vous pouvez en cr&#xE9;er un qui ne pr&#xE9;sente que les donn&#xE9;es manquantes. Cette m&#xE9;thode ne fonctionne pas avec les cha&#xEE;nes, ce qui signifie que les valeurs comme <code>&quot;my_id&quot;</code> et les UUID (par ex. un GUID) ne sont pas compatibles avec cette approche via des agr&#xE9;gations. Vous devez donc structurer vos donn&#xE9;es en fonction de ce type de v&#xE9;rification.
</p><h4>Mind the gap!</h4><p>Pour ceux d&apos;entre vous qui ne connaissent pas bien les identifiants s&#xE9;quentiels, sachez qu&apos;il n&apos;est pas rare que les syst&#xE8;mes (bases de donn&#xE9;es SQL par exemple) r&#xE9;cup&#xE8;rent en amont des lots d&apos;identifiants. Au sein de ces lots, il est possible que certaines valeurs soient ignor&#xE9;es pour diverses raisons : &#xE9;chec d&apos;une transaction ou suppression explicite de l&apos;enregistrement par la suite.
</p><p>Dans ce type de situation, vous devez garder &#xE0; l&apos;esprit que ces valeurs appara&#xEE;tront comme &#xE9;tant des documents manquants dans l&apos;histogramme. Pour les &#xE9;viter, en tant que client, vous pouvez demander &#xE0; Elasticsearch de les ignorer explicitement en ajoutant un s&#xE9;lecteur de cat&#xE9;gorie secondaire qui &#xE9;limine explicitement ces <code>id</code> ou les ignorer c&#xF4;t&#xE9; client.
</p><h2>V&#xE9;rification de documents entiers</h2><p>La v&#xE9;rification de documents entiers est bien diff&#xE9;rente de la simple v&#xE9;rification de l&apos;existence d&apos;un document. Dans ce type de sc&#xE9;nario, vous devez v&#xE9;rifier des documents entiers pour vous assurer que les donn&#xE9;es qu&apos;ils contiennent sont bien celles attendues. Si pour Elasticsearch, cette t&#xE2;che est en fait plus simple, elle demande davantage de travail de votre c&#xF4;t&#xE9;.
</p><h3>Parcours des donn&#xE9;es</h3><p>La mani&#xE8;re la plus simple d&apos;effectuer cette v&#xE9;rification consiste &#xE0; parcourir les donn&#xE9;es. Heureusement, cela ne signifie pas que vous devez placer toutes vos donn&#xE9;es dans un tableau HTML et v&#xE9;rifier tout &#xE0; la souris, mais que vous devez utiliser l&apos;API <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html"><code>_scroll</code> pour parcourir les donn&#xE9;es</a> (<code>_doc</code>, utilis&#xE9; ci-dessous, est d&#xE9;crit dans le lien pr&#xE9;c&#xE9;dent). Comme toute API de recherche, cette API suit les principes du quasi-temps r&#xE9;el &#xE9;voqu&#xE9;s pr&#xE9;c&#xE9;demment.
</p><pre class="prettyprint">GET /my_index/my_type/_search?scroll=1m
{
  &quot;sort&quot;: [
    &quot;_doc&quot;
  ]
}
</pre><p>La dur&#xE9;e de d&#xE9;filement est le temps dont vous, le logiciel client, avez besoin pour traiter ce lot avant de demander le suivant. Assurez-vous que cette dur&#xE9;e est suffisamment longue pour vous permettre d&apos;analyser la r&#xE9;ponse obtenue et prenez le temps de lire le lien de documentation ci-dessus !
</p><p>En parcourant les donn&#xE9;es, vous pouvez passer d&apos;un document &#xE0; l&apos;autre et v&#xE9;rifier que toutes les donn&#xE9;es r&#xE9;pondent &#xE0; vos exigences.
</p><h3>Contr&#xF4;le de la gestion de versions</h3><p>Elasticsearch prend en charge le <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html">contr&#xF4;le de concurrence optimiste</a>, autrement dit la gestion de versions.
</p><p>Pour contr&#xF4;ler la gestion de versions de bout en bout, fournissez votre propre num&#xE9;ro de version. Ainsi, vous pouvez contourner la v&#xE9;rification des documents complets en v&#xE9;rifiant simplement les num&#xE9;ros de version. Pour activer les num&#xE9;ros de version dans les r&#xE9;ponses aux recherches, vous devez sp&#xE9;cifier l&apos;indicateur de version :
</p><pre class="prettyprint">GET /my_index/my_type/_search
{
  &quot;version&quot;: true
}
</pre><h2>Contournement de la v&#xE9;rification</h2><p>Il est possible de contourner enti&#xE8;rement la v&#xE9;rification, si vous savez que les donn&#xE9;es ont &#xE9;t&#xE9; fournies par un utilisateur de confiance et que tout &#xE9;chec d&apos;ingestion a &#xE9;t&#xE9; g&#xE9;r&#xE9; comme il se doit (par ex. si Elasticsearch &#xE9;tait indisponible au moment de l&apos;indexation du document 15123, un autre syst&#xE8;me a d&#xFB; l&apos;ajouter). Dans ce cas, la v&#xE9;rification peut &#xEA;tre redondante.
</p><p><a href="https://www.elastic.co/guide/en/x-pack/current/index.html">X-Pack Security</a> dans la version 5.0 et <a href="https://www.elastic.co/guide/en/shield/current/index.html">Shield</a> dans les versions pr&#xE9;c&#xE9;dentes peuvent offrir le contexte de s&#xE9;curit&#xE9; permettant d&apos;accorder un acc&#xE8;s aux utilisateurs de confiance et de bloquer les utilisateurs non fiables. La gestion appropri&#xE9;e des &#xE9;checs d&apos;ingestion reste pour autant de votre ressort, car elle d&#xE9;pend enti&#xE8;rement du syst&#xE8;me charg&#xE9; de l&apos;ingestion.
</p><h2>The end</h2><p>Et voil&#xE0; ! Vous &#xEA;tes arriv&#xE9;s au bout de cet interminable billet.
</p><p>J&apos;esp&#xE8;re que vous avez appr&#xE9;ci&#xE9; ces pr&#xE9;cisions sur la v&#xE9;rification des donn&#xE9;es et sur la mani&#xE8;re dont la structure de vos donn&#xE9;es peut consid&#xE9;rablement simplifier leur v&#xE9;rification. Vous r&#xE9;alisez probablement que d&apos;autres probl&#xE8;mes peuvent &#xEA;tre r&#xE9;solus en approchant la requ&#xEA;te ou les donn&#xE9;es selon un autre angle et en s&apos;appuyant sur des fonctions riches comme les agr&#xE9;gations ou X-Pack Security.
</p><p>Nous &#xE9;tudions sans rel&#xE2;che des mani&#xE8;res cr&#xE9;atives de r&#xE9;soudre des probl&#xE8;mes int&#xE9;ressants comme celui-ci. Nous vous encourageons &#xE0; d&#xE9;battre de ces sujets sur notre <a href="https://discuss.elastic.co/c/logstash">forum</a> et &#xE0; ouvrir des tickets sur GitHub lorsque vous rencontrez un probl&#xE8;me. Sachez que nous sommes &#xE9;galement disponibles sur  <a href="https://twitter.com/elastic">Twitter</a> (<a href="https://twitter.com/pickypg">@pickypg</a> en ce qui me concerne) et sur <a href="https://webchat.freenode.net/#elasticsearch">IRC</a> pour vous donner un coup de main !
</p></body></html>

Articles By Chris Earle

Elasticsearch : vérification de l'intégrité des données lors de l'utilisation d'entrepôts de données externes

Produits

Enterprise

Resources

SaaS

Orchestration

Articles By Chris Earle

Elasticsearch : vérification de l'intégrité des données lors de l'utilisation d'entrepôts de données externes