Tech talk: zoeken in een groot tekstveld met opgeslagen velden in Elasticsearch (deel 1)
Elasticsearch is de voorbije jaren steeds populairder geworden. Het helpt klanten hun data via zoekopdrachten op een andere manier te verkennen en te analyseren. Onlangs werd het ook opgenomen in het Gartner-kwadrant. Met Elasticsearch is het verrassend eenvoudig om een cluster op te zetten en aan de slag te gaan. Maar als u die niet goed configureert, komt u vroeg of laat in de problemen.
In dit artikel passen we aan hoe Elasticsearch standaard oorspronkelijke velden opslaat. We bekijken ook de mogelijke voor- en nadelen voor de prestaties.
Wat we wilden doen
In een vorig artikel over Function App schreef ik over het extraheren en verwerken van tekst uit pdf-documenten. Nu deel ik hoe we alle berekeningsresultaten doorzoekbaar maakten en de prestaties optimaliseerden.
Onze dataset bestaat uit JSON-documenten met tekst en kenmerken uit pdf's. De tekst telt gemiddeld 200K tekens. De gebruikerservaring moet vergelijkbaar zijn met die van een bekende zoekmachine zoals Google. Wie een zoekopdracht ingeeft, moet bovendien snel antwoord krijgen. Een resultaat na 1 minuut heeft voor onze toepassingen geen zin.
Onze dataset zal 32 TB aan geïndexeerde data bevatten. We weten dat Elasticsearch veel beter horizontaal dan verticaal schaalt en de data en werklast gemakkelijk aankan. Het komt dus aan op de architectuur en het aantal nodes.
We vertrekken van een cluster met 21 nodes als eerste ruwe inschatting. Enkele optimalisaties en configuraties zijn het vermelden en testen waard, zoals opgeslagen velden en highlighting. In dit eerste deel richten we ons op de configuratie van opgeslagen velden.
Het opgeslagen veld in Elasticsearch
In Elasticsearch kunt u met een opgeslagen veld de oorspronkelijke waarde in een zoekresultaat ophalen. Het oorspronkelijke document wordt opgeslagen in een veld met de naam source_, dat wordt teruggegeven. In de meeste gevallen haalt u zo het oorspronkelijke document op bij een zoekopdracht. Standaard bevat de source_ alle velden, ook het grote, tenzij u expliciet velden uitsluit of opneemt.
Elasticsearch leest de _source bij elke zoekopdracht van de schijf, verwerkt die als JSON en geeft die terug. Zo'n opgeslagen veld met veel tekst lezen kan de prestaties belasten, zowel de CPU door het verwerken van een grote JSON-structuur als de schijf-I/O door de hoeveelheid data. Onnodig veel data van de schijf lezen verdringt bovendien de inhoud van de bestandssysteemcache, waardoor die minder doeltreffend wordt. Afhankelijk van de veldgrootte en de toepassingen kan het zinvol zijn het standaardgedrag aan te passen voor betere prestaties.
De _source in Elasticsearch aanpassen
Elasticsearch laat toe velden uit die _source uit te sluiten. U kunt een specifiek veld ook afzonderlijk opslaan, los van de _source. Zo geeft u nuttige informatie zoals 'title' en andere documentmetadata terug zonder veel tekst te moeten lezen en verwerken.
Om een veld afzonderlijk op te slaan, configureert u de indexmapping: - Sluit het uit van de _source. - Stel store: true in om het afzonderlijk op te slaan.
{
"mappings": {
"_source": {
"excludes": ["content"]
},
"properties": {
"content": {
"type": "text",
"store": true
},
"author": {
"type": "keyword"
},
"title": {
"type": "keyword"
}
}
}
}
Hoewel deze oplossing mogelijk een grote prestatiewinst oplevert, heeft ze ook belangrijke nadelen die u moet kennen.
Zoals de officiële documentatie uitlegt, schakelt het uitsluiten van een veld uit _source ook enkele nuttige functies uit:
Update, update_by_query, en reindex-API's.
Highlighting van niet-opgeslagen velden. Om zoekresultaten te markeren, moet het veld ergens opgeslagen zijn.
Een index upgraden naar een nieuwe hoofdversie. Op een bepaald moment kunt u niet verder upgraden.
Query's debuggen door het oorspronkelijke document te bekijken.
Mogelijke toekomstige functies die de oorspronkelijke _source met alle velden nodig hebben.
Onze aanbevelingen voor Elasticsearch
Het is duidelijk dat deze vorm van prestatieverbetering een hoge prijs heeft. We zien enkele scenario's:
Als u de grote tekst alleen gebruikt om een geïnverteerde index voor full-text search te bouwen, kan het zinvol zijn die uit te sluiten van de _source. Dat kan de I/O- en CPU-belasting én het schijfgebruik verlagen.
Als we de grote tekst maar in zeldzame uitzonderingsgevallen moeten ophalen, kan het zinvol zijn die afzonderlijk van het _source-veld op te slaan.
Voor onze toepassingen, met een groot veld van 200 KB, zagen we geen merkbare verbetering door het tekstveld afzonderlijk op te slaan die zulke nadelen zou rechtvaardigen. We denken dat de bestandssysteemcache het verschil maakte.
Zoals beschreven in dit artikel over de prestaties van Elasticsearch, kan het zinvol zijn een veld expliciet uit te sluiten van de _source wanneer het groot genoeg is (100 MB) om de prestatiewinst tegen de nadelen te laten opwegen. In dat zeer specifieke geval raden we sterk aan de data ook in een aparte opslag te bewaren om:
Documenten bij te werken door ze handmatig te verwijderen en opnieuw te indexeren.
Indices naar een nieuwe hoofdversie te upgraden.
Bij een upgrade moet u met een lege cluster herbeginnen en alle documenten handmatig opnieuw indexeren. Dat kan vanuit bedrijfsoogpunt onaanvaardbaar zijn. Dan moet u met twee aparte clusters werken om stilstand te beperken. Eén cluster kan ook, als die groot genoeg is om uw data dubbel te indexeren.
Conclusie
We dachten aanvankelijk dat onze dataset een groot tekstveld zou bevatten. Al snel bleek dat ons veld niet zo groot was en dat Elasticsearch veel grotere tekstvelden aankan dan we verwachtten. De grote tekst afzonderlijk opslaan lijkt op het eerste gezicht interessant, maar levert voor onze dataset geen relevante prestatiewinst op. We blijven ervan overtuigd dat het in specifieke uitzonderingsgevallen wel kan helpen.
Alles samen moet velden uitsluiten van de _source een weloverwogen beslissing zijn. In de meeste gevallen raden we af om de _source aan te passen, tenzij een veld groot genoeg is om de nadelen te rechtvaardigen. Meer weten? Lees dan deze discussie.