Performance in Parent-Child Relationships in Elasticsearch

Qbox.io. u kunt zich hier aanmelden of uw cluster starten, of klik op “aan de slag” in de header navigatie. Als je hulp nodig hebt bij het instellen, refereer je naar ” Provisioning a Qbox Elasticsearch Cluster.”

de voordelen die ouder-kind heeft ten opzichte van geneste objecten zijn als volgt:

  • het ouderdocument kan worden bijgewerkt zonder de kinderen opnieuw uit te voeren.
  • Kinderdocumenten kunnen worden toegevoegd, gewijzigd of verwijderd zonder dat dit gevolgen heeft voor de ouder of andere kinderen. Dit is vooral handig wanneer dochterdocumenten groot in aantal zijn en vaak moeten worden toegevoegd of gewijzigd.
  • Dochterdocumenten kunnen worden geretourneerd als de resultaten van een zoekopdracht.

de ouder-kind relatie is vergelijkbaar van aard met het geneste model: beide stellen ons in staat om een entiteit met een andere te associëren. Het verschil is dat, met geneste objecten, alle entiteiten in hetzelfde document leven, terwijl, met ouder-kind, de ouder en kinderen volledig gescheiden documenten zijn. Het is echter ook gebonden aan enkele beperkingen:

ouder – kind beperkingen

  • de ouder en kind typen moeten verschillend zijn of ouder-kind relaties kunnen niet worden vastgesteld tussen documenten van hetzelfde type.
  • de instelling _parent.type kan alleen verwijzen naar een type dat nog niet bestaat. Dit betekent dat een type geen oudertype kan worden nadat het is gemaakt.
  • ouder – en kinddocumenten moeten op dezelfde scherf worden geïndexeerd. De ouder-ID wordt gebruikt als de routeringswaarde voor het kind, om ervoor te zorgen dat het kind wordt geïndexeerd op dezelfde scherf als de ouder. Dit betekent dat dezelfde bovenliggende waarde moet worden opgegeven bij het ophalen, verwijderen of bijwerken van een dochterdocument.

de belangrijkste verschillen tussen ouder-kind en geneste relaties kunnen als volgt worden samengevat::

Genest Object ouder-kind
1. Geneste objecten worden in hetzelfde document opgeslagen. ouder-en dochterobjecten worden afzonderlijk opgeslagen in verschillende documenten.
2. Een dochterobject kan meerdere ouderobjecten hebben. een dochterobject kan geen meerdere ouderobjecten hebben.
3. Bevragen gaat relatief snel. opvragen is traag omdat kind en ouder apart worden opgeslagen.
4. Kan gemakkelijk meerdere geneste niveaus te handhaven. moeilijk meerdere geneste niveaus te handhaven.
5. Geneste niveau querying is goed gedefinieerd en eenvoudig te gebruiken voor een aantal geneste objecten. Ook Query string kan worden gebruikt om de geneste objecten query. vragen wordt gecompliceerd wanneer er meerdere ouder-kind relaties aanwezig zijn.
6. Kan alle gegevens op te halen, omdat ze woonachtig zijn in hetzelfde object. kan niet zowel dochter-als ouderdocumenten ophalen in een enkele query.
7. Geneste object wordt gedupliceerd voor elk bovenliggende object. er is geen sprake van duplicatie van gegevens aangezien de relatie genormaliseerd is.
8. Als een genest object wordt gewijzigd, moeten alle bovenliggende objecten opnieuw worden geïndexeerd. het is niet nodig om de ouder opnieuw te indexeren omdat er alleen een verbinding tussen hen wordt onderhouden.

geneste objecten kunnen de voorkeur hebben boven ouder-kind om de associaties te behandelen vanwege de volgende redenen:

  • wanneer databasemodellen meerdere geneste associaties in meerdere niveaus bevatten. Daarom kunnen ze gemakkelijk worden behandeld met de geneste object benadering.
  • in de ouder-kind benadering kan een dochterobject niet meerdere ouderobjecten hebben.
  • geneste queries zijn gemakkelijker uit te voeren in de geneste objectbenadering.
  • niet in staat om zowel kinderen als ouder velden op te halen in een enkele query.

Prestatieoverwegingen: globale Ordinalen

globale ordinalen zijn een gegevensstructuur bovenop fielddata en doc values, die een incrementele nummering voor elke unieke term in een lexicografische volgorde handhaaft. Elke term heeft een uniek nummer en het aantal term A is lager dan het aantal term B. Globale ordinalen worden alleen ondersteund op tekst-en trefwoordvelden.

velddata en doc-waarden hebben ook ordinalen, wat een unieke nummering is voor alle termen in een bepaald segment en veld. Globale ordinalen bouwen hier gewoon op voort, door een afbeelding te geven tussen de segment ordinalen en de Globale ordinalen, waarbij de laatste uniek is over de gehele scherf.

globale ordinalen worden gebruikt voor functies die gesegmenteerde ordinalen gebruiken, zoals sorteren en de termen aggregatie, om de uitvoeringstijd te verbeteren. Een term aggregatie is puur gebaseerd op globale ordinalen om de aggregatie uit te voeren op het scherf niveau, zet dan globale ordinalen om naar de reële term alleen voor de laatste reductiefase, die resultaten van verschillende scherven combineert.

geïnteresseerd in Kubernetes? Bekijk onze Enterprise Kubernetes Support

ouder-kind gebruikt globale ordinalen om joins te versnellen. Globale ordinalen moeten worden herbouwd na elke verandering in een scherf. Hoe meer bovenliggende id-waarden in een scherf worden opgeslagen, hoe langer het duurt om de Globale ordinalen voor het _parent – veld opnieuw op te bouwen.

globale ordinalen worden standaard gretig gebouwd: als de index is gewijzigd, zullen globale ordinalen voor het _parent veld opnieuw worden opgebouwd als onderdeel van het refresh. Dit kan aanzienlijke tijd toe te voegen het vernieuwen. Maar meestal is dit de juiste afweging, anders worden globale ordinalen herbouwd wanneer de eerste ouder-kind query of aggregatie wordt gebruikt. Dit kan een significante vertraging piek voor uw gebruikers en meestal is dit erger als meerdere globale ordinalen voor het _parent veld kan worden geprobeerd herbouwd binnen een enkele verversingsinterval wanneer veel schrijft zich voordoen.

wanneer de ouder/kind niet vaak wordt gebruikt en schrijft vaak voorkomt, kan het zinvol zijn om eager loading uit te schakelen:

de hoeveelheid heap die door globale ordinalen wordt gebruikt, kan als volgt worden gecontroleerd:

conclusie

de mogelijkheid om meerdere generaties samen te voegen (zoals Grandparents and Grandchildren) klinkt aantrekkelijk totdat u denkt aan de kosten:

  • hoe meer joins je hebt, hoe slechter de prestaties zullen zijn.
  • elke generatie ouders moet hun string _id velden opgeslagen hebben in het geheugen, wat veel RAM kan verbruiken.

als u van mening bent dat uw relatie schema ‘ s en of ouder-kind is goed voor u, overweeg dan dit advies over ouder-kind relaties:

  • gebruik ouder-kind relaties spaarzaam, en alleen als er veel meer kinderen dan ouders.
  • vermijd het gebruik van meerdere ouder-kind joins in een enkele query.
  • vermijd scoren met het has_child – filter, of de has_child – query met score_mode ingesteld op geen.
  • Houd de bovenliggende ID ‘ s kort, zodat ze beter comprimeren in doc-waarden en minder geheugen gebruiken wanneer ze tijdelijk worden geladen.

draai het eens!

het is gemakkelijk om een standaard hosted Elasticsearch cluster op een van onze 47 Rackspace, Softlayer, of Amazon datacenters. En u kunt nu uw eigen AWS Credits op Qbox Private Hosted Elasticsearch.

vragen? Stuur ons een bericht, en we zorgen voor een snelle reactie.

geniet u nog niet van de voordelen van een hosted elk-stack enterprise search op Qbox? Wij nodigen u uit om vandaag nog een account aan te maken en te ontdekken hoe eenvoudig het is om uw Elasticsearch omgeving te beheren en te schalen in onze cloud hosting service.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.