Elastic Search: Wat ik denk dat het is en aanvullingen!

Pagina: 1
Acties:

Onderwerpen


Acties:
  • +1 Henk 'm!

  • Guido1982
  • Registratie: Juni 2014
  • Laatst online: 30-05-2023
OK, ik hoor dus regelmatig termen voorbij komen waar ik niets van begrijp. Dan ga ik op een verloren vrijdagmiddag op onderzoek uit. Deze keer was het ElasticSearch dat mijn aandacht trok. Dus ik heel youtube uitspelen en ik denk dat ik het nu begrijp, ongeveer dan:

Wat ik denk dat het is
Vond een video van een vrij onverstaanbare Tsjech die met een beetje inspanning toch stiekem wel redelijk te verstaan was.

Als ik het goed begrijp is ElasticSearch ontstaan uit de moeite die SQL databases hebben met het uitvoeren van zoek-query's. Dus stel: ik wil een zoekbalk op m'n site of app waar mensen hele brede zoekopdrachten in kunnen vullen die via een request aan mijn server doorgegeven worden. M'n server maakt dan een query met een hele berg %LIKE%'s om te zorgen dat de zoekopdracht zo breed mogelijk door de SQL engine uitgevoerd wordt. Die query's zijn zwaar en eigenlijk niet waar de database engines voor bedoeld zijn.

Dus hier komt dan elastic om de hoek kijken. In plaats van via je server software (PHP, Node, Python, whatever) alleen een CRUD operatie op je database uit te voeren, voer je diezelfde operatie uit op je Elastic Search server/service. Elastic gebruikt dat om 'bij te houden wat er in je database gebeurt' en hiermee een index op te bouwen die er puur op gericht is zoekopdrachten zo efficiënt uit te voeren. Elastic bouwt dus een soort schaduwkopie van je database op, maar dan gericht op zoekopdrachten.

Ga je nu een zoekopdracht uitvoeren (of diegene op je site of app), dan maak je niet meer die lange query met %LIKE%'s naar je SQL database, maar vraag je het je ElasticSearch server/service. Die weet veel sneller wat de mogelijke resultaten zijn.

Nu hoeft Elastic niet alles op te slaan, je kunt aangeven welke kolommen Elastic moet 'indexeren'. Als ik het goed begrijp kun je bijvoorbeeld je PHP code (of Node, of kanmijhetschelen) eerst aan Elastic laten vragen welke ID's bijvoorbeeld bij de zoekopdracht passen en dan alleen die ID's uit de database halen (wat veel minder rekenkracht kost, want je weet precies wat je moet hebben).

Waar zit ik er naast?
Ik ben er van overtuigd dat hier genoeg mensen rondhangen die er meer van weten dan ik. Dus maak ik hierboven een vreselijke fout? Of heb je een goede aanvulling voor mensen zoals ik, die helemaal bij 0 beginnen? Aanvullingen en aanmerkingen zijn altijd welkom!

Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Nu online
Voor de website waar ik aan werk gebruiken we Elasticsearch vrij intensief. De source of truth staat in een relationele database en die wordt inderdaad gesynchroniseerd met Elasticsearch.

Je kan overigens prima ook de data die je nodig hebt om te laten zien opslaan in Elasticsearch, dan hoef je niet nog weer een aparte query te maken om je SQL data uit te lezen.

Acties:
  • +1 Henk 'm!

  • rufio64
  • Registratie: Februari 2009
  • Laatst online: 08:41
Guido1982 schreef op vrijdag 15 maart 2019 @ 15:15:
Als ik het goed begrijp is ElasticSearch ontstaan uit de moeite die SQL databases hebben met het uitvoeren van zoek-query's.
Dat was vrijwel zeker niet de aanleiding voor het ontwikkelen van Elasticsearch. Elasticsearch is een laag om (Apache) Lucene die in eerste instantie is ontwikkeld om gedistribueerde functionaliteit toe te voegen. Dat wil zeggen: Lucene kun je op 1 machine draaien, maar als die machine niet goed genoeg resources heeft ofwel om de data die je wilt doorzoeken op te slaan (diskruimte) ofwel om zoekvragen snel genoeg te kunnen verwerken (cpu, memory, bandbreedte), dan heb je meerdere machines nodig (die kopieën van (delen van) de data bevatten die je wilt doorzoeken).

Elasticsearch was in eerste instantie een laag die die distributie van stukjes van een index (shards) verzorgde, en er ook een REST API aan toevoegde om zowel die distributie over machines te faciliteren, alsmede het indexeren van documenten, en het doorzoeken ervan.

Vanuit dat startpunt is het wel uitgegroeid tot meer, dat wil zeggen: er is een hoop functionaliteit aan toegevoegd (aggregaties, etc ...), maar de kern blijft: je hebt een set documenten die je wilt doorzoeken met een zoekvraag, en voor die zoekvraag levert Elasticsearch een relevantie ranking van die set documenten (gebruikmakend 'onder water' van Lucene).

De manier waarop een conventionele SQL database velden doorzoekt is zoals je aangeeft wezenlijk anders. Die zijn immers veel meer gemaakt om een set records op te leveren die aan een veld = waarde (of andere operator) criterium voldoen, en niet voor: zoek binnen dit veld dit woord of deze woorden en orden dan de records naar relevantie. Het gaat dus wel wezenlijk om een ander doel.

Als je dat begrip relevantie wat beter wilt begrijpen lees op kijk dan eens iets over TF.IDF, BM25, of zelf Learning to Rank. Feitelijk is dat de kern van zoeken, het vakgebied dat zich bezighoud met zoeken heet "Information Retrieval" (en daar zitten wat subvelden onder zoals Distributed / Federated Information Retrieval, Peer to Peer Information Retrieval, etc ...). Als je dat conceptueel beter wilt begrijpen kun je er beter een middagje een introductie hoofdstuk over lezen dan YouTube filmpjes kijken, maar het hangt er natuurlijk helemaal van af wat je wilt :)

De vakgebieden Information Retrieval en Databases hebben zeker wel enige overlap, maar ze gaan feitelijk wel over iets anders. Een grove benadering is dat Information Retrieval over het algemeen over het doorzoeken van minder gestructureerde data gaat (vrije tekst), en Databases over goed gestructureerdere (relationele) data.

Elasticsearch is dus feitelijk een gedistribueerde zoekmachine, die primair bedoeld is voor het beantwoorden van zoekvragen die bestaan uit vrije tekst door middel van het indexeren van ongestructureerde (vrije tekst) documenten.

Acties:
  • 0 Henk 'm!

  • Guido1982
  • Registratie: Juni 2014
  • Laatst online: 30-05-2023
@rutgerw Met source of truth bedoel je je echte echte echte databron?

@rufio64 Damn jij weet er iets meer vanaf dan ik! Interessante materie. Lucene ken ik niet. Weer een nieuw ding voor de vrijdagmiddag. Lezen is uiteraard geen probleem, op luie momenten vind ik het echter prettig om even achterover te hangen en via video kennis te absorberen.

[ Voor 25% gewijzigd door Guido1982 op 15-03-2019 16:48 ]


Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Nu online
Guido1982 schreef op vrijdag 15 maart 2019 @ 16:47:
@rutgerw Met source of truth bedoel je je echte echte echte databron?
Ja: bij ons is de SQL database leidend en we pushen dus wijzigingen naar het Elasticsearch cluster.

Acties:
  • 0 Henk 'm!

  • Guido1982
  • Registratie: Juni 2014
  • Laatst online: 30-05-2023
rutgerw schreef op vrijdag 15 maart 2019 @ 16:49:
[...]


Ja: bij ons is de SQL database leidend en we pushen dus wijzigingen naar het Elasticsearch cluster.
En daarbij is je elastic server dus je search indexer en je databron voor 'uitgifte'?

Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Nu online
Ja: searches vinden daar plaats en de result sets worden getoond vanuit Elasticsearch.

Acties:
  • +1 Henk 'm!

  • GooDy88
  • Registratie: Augustus 2014
  • Laatst online: 12-08 09:53
Binnen ons bedrijf werken wij met Elasticsearch met dezelfde opzet als @rutgerw , de relationele dabatase is de bron en vervolgens wordt wat wij doorzocht willen hebben in Elasticsearch gezet. De kracht van Elasticsearch ligt hier bij het bepalen van de relevantie maar ook snelheid. Ook kan je bepaalde velden boosten zodat die meer gewicht hebben bij het uitvoeren van een search request. Ook kan je de data als een bepaald type in Elasticsearch zetten. Elasticsearch bepaald dan of er op de complete term gezocht moet worden (keyword) of gewoon als tekst moet worden geanalyseerd. Door bijvoorbeeld te filteren waardes op te nemen als keywords kan er heel snel door middel van aggregations selecteerbare filters opgezet. Denk hierbij aan webshops waar je dmv een vrij simpele query de hele filter structuur kan opzetten en berekenen welke filters en hoeveel producten daarbij binnen die filter passen.

Naast 'direct' zoeken zijn er nog meer mogelijkheden om relevante resultaten te vinden. Door functionaliteiten als 'more like this 'https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html. Een functionaliteit waar ik erg over te spreken ben is https://www.elastic.co/gu...antterms-aggregation.html hiermee maak je aggregations met een foreground en background zoekresultaat waardoor je relevante relaties tussen geindexeerde waardes kan vinden.
Pagina: 1