Analyse: Undersøke mulighet for fuzzy/stemmed fulltekst-søk

[MagnusSandgren]

Det er behov for å kunne søke i alt av fritekst-felter i dialog-aggregatet, herunder

• Tittel
• Content-felter (se Endre dialog-modell mht innholdsfelter (body, title etc) og innfør "summary" #215)
• Description i aktivitetslogg
• Search tags

I tillegg er det nyttig å kunne søke på metadata knyttet til selve ressursen (title, description, tjenesteeiers navn)

Søket må kunne være fuzzy, f.eks. at søk på "sykemelding" gir treff på "sykmelding" og fortrinnsvis også stamming (altså behandle "løper", "løpere", og "løping" som det samme ordet ("løp").

Enkel col LIKE '%searchterm%' er ikke fuzzy og dessuten treigt (støttes ikke av B-tree indexer).

Mulige løsningskonsept

Løsningen må skalere til >1 milliard dialoger. Her er noen ulike approaches:

Løsning	Pros	Cons
1. Vertikalt skalere den samme Postgre-instansen til å håndere søk-workloads i tillegg til alt annet	Minst komplisert	Uklart om vi klarer å skalere
2. Sette opp block level read-replicas som kan benyttes ved fritekst-søk (egne Postgre-instanser)	Relativt ukomplisert i kode (trenger bare å sjonglere ulike connection strings). Read replicas gir god horisontal skalering	Kostbart, delay
3. Sette opp logical replication via CDC/RabbitMQ/DialogportenService som populerer en PostgreSQL-instans med custom data	Kan optimalisere tabell for fritekstsøk. Har allerede infra for å håndtere logisk replikering.	Kostbart, mer kode, uklar skalering
4. Sette opp logical replication via CDC/RabbitMQ/DialogportenService som populerer ElasticSearch	ES er optimalisert for søk, god funksjonalitet, og kan skalere vertikalt mer eller mindre automatisk, gjenbruk av rabitmq/service	Kostbart, mer (ukjent) infra, uklart om service skalerer godt nok
5. Sette opp logical replication via CDC/RabbitMQ/Logstash som populerer ElasticSearch	Som over, men uten gjenbruk av service. Logstash er optimalisert for dette.	Kostbart, enda mer infra

For alle alternativer foruten 2 må de custom tabellene/ES schemaene også inneholder dialogId, partyId og serviceidentifier samt alle felter som er relevante for liste-visningene slik at parametre hentet fra autorisasjonskall også kan benyttes der.

Se også

• https://www.crunchydata.com/blog/postgres-full-text-search-a-search-engine-in-a-database
• https://www.postgresql.org/docs/15/pgtrgm.html
• https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-extensions