NO327653B1 - Fremgangsmate for dynamisk oppdatering av en indeks og en sokemotor som implementerer samme - Google Patents

Abstract

I en fremgangsmåte for dynamisk oppdatering av en indeks i en søkemotor, hvor indeksen er en invertert indeks som omfatter en datakatalog, en posteringsfil med en posteringsliste for hvert stikkord i indeksen og en databaselogg, settes dokumentene inn i indeksen i små satser kalt oppdateringsgenerasjoner, en liste av alle forekomster av stikkord i dokumentene for hver oppdateringsgenerasjon genereres, forekomstlisten settes inn i databaseloggen, og for hvert stikkord innført i databasen genereres en henvisning til en tidligere innførsel av det samme stikkord. Denne tidligere innførsel har en referanse lagret i masselagerinnretningen som den sist tilføyde innførsel av alle de seneste stikkord. - En søkemotor som utfører fremgangsmåten, kan implementeres på én eller flere tjenere med en masselagerinnretning, og omfatter en kjernesøkemotor med et søkeundersystem og et indekseringsundersystem for å generere en stikkordsindeks lagret på masselagerinnretningen, og realisert som en dynamisk oppdaterbar indeks.

Description

Oppfinnelsen angår en fremgangsmåte for dynamisk oppdatering av en indeks i en søkemotor, hvor søkemotoren er implementert på én eller flere tjenere som omfatter en masselagerinnretning, og hvor indeksen er en invertert indeks som omfatter en datakatalog, en posteringsfil med posteringslister for hvert stikkord i indeksen og en databaselogg.

Den foreliggende oppfinnelse angir spesielt en ny dynamisk indeksstruktur for fritekstsøking og dynamiske oppdatering av denne. Målet er å opprettholde den samme søkespørsmålseffektivitet så vel som dagens fremste tekniske løsninger, samtidig som det sikres en kort og predikerbar oppdateringslatens og maksimal konsistens.

Den typiske datastruktur benyttet til fritekstsøking i store tekstvolumer er inverterte indekser. En invertert indeks lagres på og aksesseres fra et masselager, og for nærværende benyttes det for inverterte indekser en platelagerbasert aksessmetode. Indeksen består primært av et leksikon og en posteringsfil. Leksikonet gjengir alle ord som står til rådighet i indeksen, og for hvert ord lagrer den stedet for og størrelsen av ordet i posteringsfilen. I posteringsfilen has det en sortert liste for alle steder (dokumentidentifikasjon og posisjon i dokumentet) hvor ordet forekommer.

Uheldigvis er i utgangspunktet en invertert indeks grunnleggende statisk og kan ikke oppdateres skrittvis etter hvert som dokumenter tilføres, slettes eller modifiseres. For å håndtere denne dynamiske oppførsel benytter en typisk implementering partisjonering og fletting, men med en rekke ulemper. I det verste tilfelle vil det kreves 100 % administrasjon av platelagerplassen for å håndtere ombyggingen av den største partisjonen. Et annet problem er den sterkt varierende belastning på platelageret. Under fletting av den største partisjonen vil platelageret måtte lese og skrive hele volumet av indeksen, slik at oppslag i indeksen vil rammes av overbelastning av platelageret. På andre tidspunkter vil oppdateringsbelastningen for indeksen være mindre. Et tredje problem er kostnaden ved å skifte partisjoner. Når en ny partisjon innføres, vil hele hurtiglagerinnholdet fjernes og hurtiglagrene må lades på ny, noe som forårsaker et temporært, dypt fall i ytelse. Et siste problem er behovet for oppslag i mange partisjoner, noe som forårsaker potensielt en rekke platelageroperasjoner, hvor det bare hadde vært nødvendig med én.

En rekke prosjekter har tatt sikte på å overvinne disse problemer, og det kan f.eks. vises til de nedennevnte publikasjoner som omhandler kjent teknikk:

Doug Cutting og Jan Pedersen, "Optimizations for dynamic inverted index maintenance", "Proceedings of the 13th International ACM SIGIR conference on Research and Development in Informatin Retrieval", sidene 405-411, 1990; Anthony Tomasic, Hector Garcia-Molina og Kurt A Shoens, "Incremental Updates of Inverted Lists for Text Document Retrieval", SIGMOND Conference 1994, sidene 289-300; Marc Overmars og Jan van Leeuwen, "Some principles for dynamizing decomposable searching problems", Report RUU-CS-80-1, Rijksuniversiteit Utrecht, 1980; Nicholas Lester, Justin Zobel og Hugh E. Williams, "In-place versus re-build versus re-merge: index maintenance strategies for text retrieval systems", CRPIT '26: Proceedings of the 27th conference on Australasian computer science, 2004, sidene 15-23; Brown, E.W., Callan, J.P. og Croft, W.B., "Fast incremental indexing for full-text information retrieval", Proceedings of the 20th International Conference on Very Large Databases (VLDB)", september 1994, Santiago, Chile; C. Clarke og G. Cormack, Dynamic Inverted Indexes for a Distributed Full-Text Retrieval System, Technical Report MT-95-01, Department of Computer Science, University of Waterloo, februar 1995; L. Lim, M. Wang, S. Padmanabhan, J. Vitter og R. Agarwal, "Dynamic maintenance of web indexes using landmarks", Proceedings of the Twelfth International World Wide Web Conference, Budapest, Ungarn, mai 2003. Dessuten er det i US patent nr. 6,349,308 (Whang & al.) vist en invertert lagringsstruktur i form av en invertert indeks som indekserer inngitte stikkord i lagringsområdet for tilsvarende posteringslister. Spesielt angis det her en indeks struktur som muliggjør hurtig gjenfinning av posteringen av et spesifikt dokument fra posteringslisten og som også muliggjør vedlikehold av posteringslisten i en orden gitt av dokumentidentifikatorene, slik at hurtig modifikasjon av databasen med sletting eller tilføyelse av dokumenter er mulig hvor databaseforvaltningen er tett koblet til informasjonsgjenfinning. Spesifikt angis en løsning hvor posteringslister lagres i et stort objekt definert som et databaseobjekt hvis størrelse overstiger en plateside og som dynamisk justerer lagringsområdet ved tilføyelse og sletting. Hver posteringsliste avbildes til et underindeks som indekserer dokumentidentifikasjonene i posteringer som inneholder dokumentidentifikasj onene.

Mindre relevant for den foreliggende problemstilling, som danner utgangspunkt for den foreliggende oppfinnelse, er US patentsøknad nr. 2002/0194151 (Fenton & al.) som viser dynamisk oppdaterbar grafisk indeks som muliggjør hurtig avsøking gjennom innhold som finnes på et vevsted. Indeksen omfatter brukervalgbare nivåer innenfor grener av en hierarkisk trestruktur som representerer forskjellige kategorier og underkategorier av innhold som er tilgjengelig på vevstedet. Alt innhold på vevstedet er forbundet med metadata og kategorien og underkategoriene svarer til disse metadata. Etterhvert som innhold tilføyes vevstedet blir innholdets forbundne metadata dynamisk innbefattet i indeksen og kan søkes innenfor den hererkiske trestruktur som vises for brukeren.

Imidlertid henvender ingen av disse publikasjoner seg til tre viktige saker.

For det første beskjeftiger de seg ikke med tilfeller som oppretting av sammenbrudd og konsistens. Det er trivielt å rette opp et sammenbrudd ved å benytte prinsippet for partisjonering og fletting (kast bare vekk partisjonen som er under bygging og start på ny). På den annen side, når skrittvise oppdateringer i indeksstrukturen utføres, er det viktig at et sammenbrudd ikke ødelegger datastrukturen.

Et annet forhold er tilfellet med hurtig sanntidsindeksering og aksess. De fleste av de foreslåtte strukturer har ikke en kort og predikterbar latens fra det øyeblikk et dokument mottas for indeksering inntil det er søkbart.

Et tredje enestående forhold er multiversjonering som er evnen til å kjøre et søkespørsmål på en spesifisert versjon av indeksen samtidig med at andre søkespørsmål kjøres mot andre versjoner. Dette brukes for å sikre et konsistent søkespørsmål over flere fordelte indekspartisjoner eller en konsistent sekvens av søkespørsmål mot den samme indeks (f.eks. forfining av et søkeresultat).

Følgelig er det en hensikt med den foreliggende oppfinnelse å skaffe en fremgangsmåte for dynamisk å oppdatere en indeks for en søkemotor slik at indekseringen kan finne sted i tilnærmet sanntid med høyfrekvent, trinnvis eller semikontinuerlig oppdatering.

En annen hensikt med den foreliggende oppfinnelse er å opprettholde en høy prosesseringseffektivitet for søkespørsmål kombinert med kort oppdateringslatens og maksimal konsistens.

De ovennevnte hensikter så vel som andre trekk og fordeler realiseres med en fremgangsmåte i henhold til den foreliggende oppfinnelse som er kjennetegnet ved trinn for å innsette dokumenter i indeksen i små satser, idet hver sats utgjør en oppdateringsgenerasjon av indeksen; å generere en liste over alle forekomster av stikkord i dokumentene i hver oppdateringsgenerasjon, å sette forekomstlisten inn i databaseloggen, og å danne for hvert stikkord innført i databasen en henvisning til en tidligere innførsel av samme stikkord i databaseloggen, idet den tidligere innførsel har en referanse lagret i masselagerinnretningen som den sist tilføyde innførsel av alle senest tilføyde stikkord.

Noen ytterligere trekk og fordeler er nevnt nedenfor.

Oppfinnelsen holder leksikon og posteringsfilen vekk fra det inverterte listeindeks, men innfører fire nye begreper: loggfil, generasjoner, deltalister og "sjekkpunkter" (eller kontrollpunkter; engelsk: "checkpoints") hvor det foretas en kontroll kalt "sjekkpunkting" (engelsk: "checkpointing"). Loggfilen er en fil som skrives sekvensielt, men som kan leses slumpmessig. Etter en stund kan begynnelsen av filen trunkeres. Dette tilsvarer en databaseloggfil. En generasjon er en sats av oppdateringer til indeksen (innsetting/sletting/oppdatering av dokumentet). Generasjoner er sekvensielle og ikke-overlappende, dvs. det er en strikt orden av generasjoner. En deltaliste er de inkrementale posteringer i posteringsfilen av et ord for en gitt generasjon. En sjekkpunkting ("checkpointing") er prosessen for å samle deltalister fra loggen og skrive dem til posteringsfilen.

Fordelaktig støttes de følgende operasjoner ved fremgangsmåten i henhold til den foreliggende oppfinnelse.

Tilføyelse av generasjon

Når en generasjon tilføyes, genereres sorterte deltalister for alle ordene i generasjonen med adressen til den tidligere deltaliste for disse ordene i loggen og de skrives sekvensielt på slutten av loggen. Straks det er sikret at loggen er blitt skrevet i platelageret, kan man begynne å betjene søk på denne generasjonen. Adressen til alle ord som ennå ikke er kontrollert ("checkpointed"), holdes i hovedminnet.

O ppslag på ord for en gitt generasjon

Først leses ordet fra leksikonet. I leksikonet finnes adressen til hovedposteringen pluss adressen til kontrollerte deltalister. Med pekeren til adressen i hovedminnet leses også deltalister som ennå ikke er kontrollert (de følger kjeden av henvisninger som peker bakover). Deltalister som er nyere enn generasjonen som kjøres for oppslag, fjernes. Deretter flettes de sorterte deltalister sammen med hovedposteringene, og det genereres en forekomstliste som sorteres på dokumentidentifikasj on.

Sjekkpunktkiøring (" Running checkpoint"

En sjekkpunkting dekker alle generasjoner etter at den foregående kontroll ble kjørt, inntil den selv starter. For å optimere oppslaget blir deltalistene for et ord enten lagret sammen med hovedposteringene eller sekvensielt på et annet sted i posteringsfilen.

Kjøring av datasanering

Av ytelsesårsaker ønskes det ikke å beholde alle generasjoner etter genereringen av indeksen. Et stort antall deltalister innebærer en betydelig kostnad for hvert oppslag. Først er det nødvendig å definere en generasjon som setter grense for alderen på generasjoner som spesifikt kan være gjenstand for søkespørsmål. Deretter flettes deltalister eldre enn denne generasjonen sammen til en enkelt postering i posteringsfilen, mens de nyere deltalister beholdes. Alternativt kan generasjoner basert på grovere tidsgranulariteter grupperes sammen, f.eks. gruppert på dag, måned eller år. I tillegg må det tas hånd om fri plass i posteringsfilen for gjenbruk av plassen til posteringer og deltalister som er flyttet. Datasanering utføres som en del av sjekkpunktingen. Det er ikke nødvendig å utsette alle ord for datasanering som en del av sjekkpunktingen, da denne kan være fordelt over tid.

Gjenoppretting

Etter et sammenbrudd (programvare eller maskinvare) er det nødvendig å bringe datastrukturen i leksikonet og posteringsfilen til en konsistent tilstand uten å miste noen dokumentoppdateringer. Dette gjøres ved å lese loggfilen fra starten av den sist fullførte sjekkpunkting, og på ny utføre oppdateringene til filene og hovedminnestrukturene.

Innlysende og foretrukket kan både hovedposteringen og deltalistene komprimeres for å spare platelagerplass og båndbredde.

I tillegg til ovennevnte operasjoner vil ytterligere trekk og fordeler i henhold til den foreliggende oppfinnelse fremgå av de vedføyde, uselvstendige krav.

Den foreliggende oppfinnelse vil forstås bedre ved å lese den etterfølgende detaljerte drøftelse i samband med den vedføyde tegning, på hvilken fig. 1 skjematisk viser arkitekturen til søkemotor hvor fremgangsmåten i henhold til den foreliggende oppfinnelse kan implementeres,

fig. 2 et eksempel på begrepet oppdateringsgenerasjon eller mer kortfattet bare generasjon,

fig. 3 en invertert listefilstruktur,

fig. 4 administrasjon av ledig plass for forekomstfilen, og fig. 5 hovedminnet og platelagerbaserte strukturer.

Den spesielle del av beskrivelsen som følger nedenfor er blitt delt i avsnitt 1-8 av hvilke avsnitt 1 angir den generelle bakgrunn for oppfinnelsen i kontekst, avsnitt 2 er en generell oversikt, avsnittene 3 og 4 er detaljerte drøftelser av trekk, aspekter og utførelser av fremgangsmåten i henhold til den foreliggende oppfinnelse så vel som indeksstrukturer implementert på en søkemotor lik den vist på fig. 1, avsnittene 5 og 6 angir i detalj ytterligere aspekter av oppfinnelsen innbefattet dens fordeler, muligheten av en generisk oppdaterbar indeks og visse omstendigheter og trekk som det må tas hensyn til når fremgangsmåten i henhold til oppfinnelsen implementeres, mens avsnitt 7 skisserer noen mulige forbedringer av fremgangsmåten i henhold til den foreliggende oppfinnelse, selv om de kan anses å ligge utenfor rammen av oppfinnelsen som her vist. - Endelig rommer avsnitt 8 noen få avsluttende bemerkninger.

1 Søkemotorarkitektur

1.1 Søkemotoren 100 i henhold til den foreliggende oppfinnelse omfatter som kjent i teknikken forskjellige undersystemer 101-107. Søkemotoren kan aksessere dokumenter eller innholdsmagasiner som befinner seg i et innholdsdomene eller -rom fra hvilket innhold enten aktivt kan skyves inn i søkemotoren, eller via en datakobling trekkes inn i søkemotoren. Typiske

magasiner innbefatter databaser, kilder tilgjengelige via ETL-(Extract-Transform-Load)verktøy så som Informatica, ethvert XML-formatert magasin, filer fra filtjenere, filer fra vevtjenere, dokumenthåndteringssystemer, innholdshåndteringssystemer, e-postsystemer, kommunikasjonssystemer, samarbeidssystemer og rike media så som audio, bilder og video. De gjenfunne dokumenter leveres til søkemotoren 100 via et innholds-API (Application Programming Interface) 102. Deretter blir dokumenter analysert i et innholdsanalysetrinn 103, også kalt et undersystem for forbehandling, for å klargjøre innholdet for forbedrede søke- og oppdagelsesoperasjoner. Typisk er utdata fra dette trinn en XML-representasjon av inndokumentet. Utdataene fra innholdsanalysen benyttes til å mate kjernesøkemotoren 101. Kjernesøkemotoren 101 kan typisk anbringes spredt over en tjenerfarm på en desentralisert måte for å tillate behandling av store dokumentmengder og høye

søkespørsmålsbelastninger. Kjernesøkemotoren 101 kan akseptere brukeranmodninger og frembringe lister over tilsvarende dokumenter. Dokumentrekkefølgen blir vanligvis bestemt i henhold til en relevansmodell som måler den sannsynlige betydning av et gitt dokument i forhold til spørsmålet. I tillegg kan kjernesøkemotoren 101 frembringe ytterligere metadata om resultatmengden slik som sammendragsinformasjon for dokumentattributter. Kjernesøkemotoren 101 kan i seg selv omfatte ytterligere undersystemer, nemlig et indekseringsundersystem 101a for nedsamling ("crawling") og indeksering av innholdets dokumenter, og et søkeundersystem 101b for den egentlige utførelse av søk og gjenfinning. Alternativt kan utdata fra innholdsanalysetrinnet 103 mates inn i en valgfri varslingsmotor 104. Varslingsmotoren 104 vil ha lagret en mengde av spørsmål og kan bestemme hvilke søkespørsmål som ville akseptert den gitte dokumentinnmating. En søkemotor kan aksesseres fra mange forskjellig klienter eller applikasjoner, som typisk kan være mobile og datamaskinbaserte klientapplikasjoner. Andre klienter innbefatter PDAer og spillinnretninger. Disse klientene, som befinner seg i et klientrom eller -domene, vil levere anmodninger til søkespørsmåls- eller klient-API 107 i søkemotoren. Søkemotoren 100 vil typisk ha et ytterligere undersystem i form av et søkespørsmålsanalysetrinn 105 for å analysere og forfine søkespørsmålet med tanke på å konstruere et avledet søkespørsmål som kan fremskaffe mer meningsfull informasjon. Endelig blir utdataene fra kjernesøkemotoren 101 typisk ytterligere analysert i et annet undersystem,

nemlig et resultatanalysetrinn 106 for å skaffe informasjon eller visualiseringer som benyttes av klienter. - Begge trinnene 105 og 106 er forbundet mellom kjernesøkemotoren 101 og klient-API 107, og i tilfelle varslingsmotoren 104 foreligger, er den forbundet i parallell med kjernesøkemotoren 101 og mellom innholdsanalysetrinnet 103 og søkespørsmålsanalyse- og resultatanalysetrinnene 105;106.

1.2 Indekseringsundersystemet 101a til en søkemotor indekserer i dokumenter fra dokument- eller innholdsmagasinet og generer indeksen til søkemotoren med stikkord essensielt i form av ord fra de indekserte dokumenter, med unntak av stoppord. Når et søkespørsmål prosesseres, blir spørsmålstermer eller søketermer benyttet til å søke indeksen, finne stikkordene i indeksen som svarer til søketermene og på dette grunnlag gjenfinne dokumentene som danner resultatmengden til søkespørsmålet. Dokumentene i resultatmengden gjenfinnes fra innholdsmagasinet, og som innlysende behøver de ikke å være lagret i søkemotorens minne, men befinner seg i stedet på tjenere, personlige datamaskiner osv. som enten befinner seg innenfor en bedriftsstruktur eller er knyttet til WWW. Søkemotorindeksen selv er lagret på en masselagerinnretning i tjeneren eller tjenerne hvor søkemotoren selv er implementert, og for tiden kan en slik masselagerinnretning settes lik magnetiske platelagre, selv om masselagring i fremtiden kan foregå på andre minnetyper. Imidlertid vil i det følgende referansen vanligvis være til masselagerinnretninger i form av plateminner, selv om det skal forstås at fremgangsmåten i henhold til den foreliggende oppfinnelse ikke på noen måte er begrenset til indekser lagret på plateminner, selv om begrepet platebasert hyppig benyttes, men da i en eksemplifiserende og ikke-begrensende forstand.

2 Oversikt

2. 1 Terminologi

I denne fremstillingen anses dokumenter for å være enhetene som skal indekseres. De blir entydig identifisert med Document IDentiflers (DID). Et dokument er en sekvens av ord eller symboler entydig identifisert med Word IDentiflers (WID). Hvert ord har en posisjon i dokumentet. Flere ord kan ha samme posisjon.

2. 2 Generasjoner

Alle forandringer av de indekserte data er forbundet med en Generation

IDentifier (GID). En generasjon er en konsistent logisk betraktning av dataene på et bestemt tidspunkt. Et søkespørsmål vil bli eksekvert i den konsistente betraktning av en enkelt generasjon, og således vil resultatet være konsistent. Generasjonsbegrepet er definert over den helt fordelte plattform.

På ethvert tidspunkt kan flere generasjoner være synlige. En åpen generasjon er en generasjon som ennå ikke er helt ferdigbygget og ikke kan benyttes for søkespørsmål. Samtidig kan det foreligge mer enn en åpen generasjon.

En aktiv generasjon er komplett og konsistent. Nye søkespørsmål bør rettes til den nyeste, aktive generasjon. Når en ny generasjon blir aktiv, kan eldre generasjoner fjernes når det ikke er noe søkespørsmål som kjøres mot disse generasjoner.

Fig. 2 viser et eksempel på bruken av generasjoner. Generasjon 21 er for øyeblikket under bygging, med dokumenter som mates inn og er innlysende

åpen. Generasjonene 19 og 20 er også åpne, men fullstendige og prosesseres i parallell for mating og indeksering. Generasjonene 16, 17 og 18 er aktive ved søkenoden og kan benyttes til søkespørsmål. Generasjon 19 er for øyeblikket under installasjon fra indekseringslinjen, men ikke aktiv.

QR-tjeneren rommer GID for den nyeste generasjon og nye søkespørsmål merkes med denne GID. På figuren er det vist to aktive søkespørsmål, Query 1 og Query 2. Query 1 er gammelt og kjøres mot en gammel generasjon 16. Det andre søkespørsmålet er nytt og nettopp inngitt og merket med GID 18. Ingen søkespørsmål utstedes for generasjon 19 før den er helt installert og aktiv.

GID-ene blir nummerert med et 64-bit lineært økende heltall (noe som praktisk talt vil være uuttømmelig). Operasjoner på dokumentene som forandrer indeksen (innsetting, oppdatering eller sletting), mottar GID-en til den foreliggende ufullstendige åpne generasjon når de mates inn.

En ny generasjon startes basert på enten når den foreliggende generasjon har et maksimalt antall dokumenter, en maksimal, aggregert dokumentstørrelse eller et visst tidsintervall. Den gunstigste metode er sannsynligvis en kombinasjon av disse. Disse parametrene må avstemmes med hensyn til to ytelsesparametre, nemlig indekseringslatens og indekseringshastighet. Mange små generasjoner betyr kortere latens, men sannsynligvis også mer administrasjon i indekseringsprosessen. Store generasjoner gir høyere hastighet, men tiden det tar å mate en generasjon gir en tidsforsinkelse før generasjonen blir aktiv og dokumentene synlige for søking.

3. Inverterte listeindeksstrukturer

Dette avsnittet skisserer indeksstrukturene for en oppdaterbar, invertert listeindeks med full posisjonsinformasjon ( posocc). Denne indeks kan også benyttes på en boolocc- og en phraseocc- indeks uten vesentlige forandringer. En tilsvarende metode kan benyttes for andre indeksformater, og dette vil bli beskrevet nedenfor i dette dokumentet.

Den inverterte listeindeks avbilder fra et ord (eller symbol; engelsk: "token") til en posisjonsliste. Posisjonslisten inneholder en liste av dokumenter hvor ordet forekommer og alle posisjoner i dokumentet hvor ordet forekommer.

Nå skal de følgende viktige trekk og aspekter forbundet med indeksoppdateringen drøftes, nemlig platelagerstrukturene, hovedminnestrukturene og den dynamiske oppførsel.

3. 1 Platelagerstrukturer

En indeks på et platelager består av en mengde filer. Alle disse filene bør ha en felles topptekst som angir filtypen og et versjonsnummer. Versjonsnummeret sikrer muligheten til å foreta en direktekoblet oppgradering. Fig. 3 viser et forenklet bilde av tre filer som utgjør en indeks. Indeksen har en invertert listefilstruktur.

3. 1. 1 Datakatalog

Datakatalogen avbilder fra et ord (tekst) til en ordidentifikator WID og posisjonslisten og deltalisten for den siste kontrollerte generasjon CG. For små ord (to eller færre innførsler i listen) kan informasjonen være innleiret i selve datakatalogdokumentet. For samlinger med zipf-fordelte ord, vil dette dekke mer enn 50% av ordene (i henhold til teorien 65%).

Større posisjonslister er plassert i en forekomst/ il (engelsk: occurrence file, se avsnitt 3.1.3). CG-innførselen inneholder

• GID for generasjonen når listen ble skrevet (CGID)

• Peker til starten av posisjonslisten i forekomstfilen

• Antall dokumenter som ordet forekommer i

• Totalt antall forekomster

• Størrelsen av innførselen i byter (innførselen i filen er komprimert og kan ikke beregnes fra antallet dokumenter og innførsler)

• Peker til deltalisten i forekomstfilen

• Maksimal størrelse for deltalisten

• Nåværende størrelse av deltalisten

Opplegget av dataene i datakatalogen er skissert i den følgende pseudokode. Datakatalogen inneholder et sett av DictionaryEntry-poster. Innleiret i en post av denne art kan det være poster av typen PositinListRef. DeltaPositionListRef, Position og EmbeddedPositionList. Klammeparentesene {, } om utsagn markerer "Begin" og "End". Kommentarer til kodene følger etter skråstrekene i kolonnen til høyre. Informasjonen i denne filen må være direkte aksesserbar med maksimalt en platelageraksess. For å oppnå dette, kan ett av de følgende tiltak utføres. • Organisere filen som et B+-tre med ordet som nøkkel. Posteringene på bladnivåsider vil være forholdsvis små, og det bør derfor være mulig å oppnå en høy utspredning av resten av sidene. Alle nivåer, bortsett fra bladnivåsidene, bør derfor passe inn i hovedminnet, selv med forholdsvis store samlinger. B+-treet vil støtte samtidige oppdateringer, poster med variabel størrelse og sortert sekvensiell aksess (støtter postfiks jokersymboler). Plassutnyttelsen vil uheldigvis bare være på 60-70%. Hvis de interne noder i B+-treet annoteres med en forekomsttelling ( pccurrénce couni), vil det være mulig effektivt å beregne antallet forekomster for verdimengdene. Denne muligheten krever oppdateringer av hele veien nedad treet, selv når bare en bladnivåinnførsel modifiseres og vil være betydelig mer kostbar. Oppdatering av B+-treet krever en viss logging til platelager for å sikre konsistens og øker derfor kompleksiteten. • Organisere filen med lineær nøkkeltransformering. Den vil da vokse dynamisk og gjenfinne data med en enkelt platelageraksess, men uten noen sortert sekvensiell aksess. Det skulle være mulig å oppnå en plassutnyttelse på 90 %.

I den etterfølgende drøftelse av oppfinnelsen antas det et B+-tre. Som her beskrevet, er WID sannsynligvis ikke i det hele tatt nødvendig. På den annen side kan bruken av ord noen steder erstattes med WID, spesielt hvis datakatalogen kan passes inn i minnet.

3. 1. 2 Loggfil( er)

Formålet med loggfilen (det kan være flere) er å registrere alle forandringer som gjøres i datakatalogen og forekomstlistene etter hvert som de finner sted. Ideen er å skrive forandringer her når disse forandringene utføres og senere foreta satsvise oppdateringer til andre filer og utføre oppdateringene i store satser som er mer optimale med hensyn til platelagerutnyttelse. Alle poster har følgende felter: LSN (Loggsekvensnummer): Et lineært økende sekvensnummer som nummererer loggposten.

GID (GenerasjonsID): Angir hvilken generasjon denne loggpost tilhører. TYPE (Loggposttype): Viser hvilken type loggpost dette er.

De følgende posttyper er nødvendige (flere kan tilføyes senere).

MO (Modifisert forekomstfil): Denne logginnførsel modifiserer en posisjonsliste i forekomstfilen. Hvis ordet ikke allerede eksisterer i datakatalogen, settes det inn i den. Det antas at MO-loggposter er idempotente. Loggposten består av:

Word: Ordet modifisert av denne loggpost.

LPL (Loggpostposisjonsliste; engelsk: "Log record Position List"): Denne har samme format som i forekomstfilen (OPL - Occurence File Position List) og er også ordnet på DID. LPL-innførslene overkjører OPL-innførslene. Dersom dokumentet forekommer i begge lister, vil for et gitt ord posisjonslisten i LPL erstatte posisjonslistedelen for dette dokument i OPL. Hvis LPL inneholder dokumentet, men det er tomt, blir LPL fjernet fra OPL. Hvis det foreligger i LPL, men ikke i OPL, settes det inn i OPL.

Prev: Peker til den tidligere MO-loggpost for ordet ved dette sjekkpunkt.

MD (Modifiser katalog; engelsk: "Modify Dictionary"): Denne logginnførselen modifiserer en datakataloginnførsel. Hvis innførselen ikke eksisterer i datakatalogen, settes den inn. Posten består av:

Word: Ordet som identifiserer datakataloginnførselen.

MOptr: Den inneholder også en peker til den siste MO-loggpost for dette ordet i dette sjekkpunkt.

GC (Generasjon fullført; engelsk: "Generation Completed"): En generasjon er blitt fullført og kan motta søkespørsmål. Posten inneholder ikke noen ytterligere felter.

CP (Sjekkpunktpost; engelsk: "Checkpoint record"): En sjekkpunkting er fullført, og alle forandringer som tilhører denne generasjonen, er skrevet til platelageret. Posten består av:

Prev: peker til tidligere sjekkpunktpost og dens GID.

Noen regler kan anføres:

• Loggposter skrives med økende LSN-nummer.

• Loggposter blir aldri modifisert og skrevet til platelagre bare en gang.

Når loggen flyttes til platelageret, skal plassen etter den siste post opp til den neste platesidegrense være ubrukt. Den neste loggpost bør adderes til den neste plateside. (Dette vil imidlertid være vanskelig hvis det benyttes minneavbildede filer). • En sjekkpunktpost vil ikke skrives til platelageret før alle oppdateringer med en GID mindre eller lik sjekkpunktets er blitt skrevet til platelageret. • Når en sjekkpunktloggpost er blitt skrevet, vil det ikke skrives noen andre loggposter med en GID mindre eller lik sjekkloggpostens GID. • Loggpostene vil bare benyttes til å gjøre operasjoner om igjen og ikke oppheve operasjoner. • Loggposten for en operasjon blir alltid skrevet til platelageret før de modifiserte data skrives til noen av de andre platelagerstrukturer. • Loggposten for en operasjon blir alltid skrevet til platelageret før de modifiserte data benyttes til søkespørsmålsprosessering.

Loggfilen kan organiseres som en mengde av minneavbildede filer. De skrives sekvensielt, én etter én. Når den siste er blitt fylt opp, starter den på ny fra den eldste. Den aggregerte størrelse av loggfiler begrenser størrelsen på et kontrollpunkt (loggfilene må inneholde minst to sjekkpunkter) Loggstørrelsen kan forandres direktekoblet ved å tilføye eller slette loggfiler.

I begynnelsen av hver loggfil bør det være en topptekst som angir den nyeste sjekkpunktloggpost. Alle kontroller kan finnes ved å følge den tidligere peker. Sjekkpunktinnførselen i toppteksten bør identifiseres med en GID og inneholde forskyvningen i filen. Toppteksten bør også inneholde en nivåmarkør som viser hvor langt loggen er blitt skrevet, LSN for den første loggpost i filen, og en henvisning til den foregående loggfil.

En felles loggfilindeks bør liste loggfilene som for tiden er i bruk, deres størrelser, deres individuelle sekvens og den senest benyttede loggfil.

3. 1. 3 Forekomstfil

Forekomstfilen består av en mengde av posisjons- og deltalister. En posisjonsliste gir alle steder for et gitt ord. Posisjonslisten er en sortert liste av dokumenter (sortert på DID). For hvert dokument finnes det en liste av posisjoner hvor ordet forekommer. Med hver posisjon has det også et spesifikt forekomstdatafelt med fast størrelse (f.eks. informasjon om definisjonsområde).

En deltaliste inneholder forandringene i posisjonslisten etter at den ble skrevet. Den inneholder en seksjon for hver generasjon hvor det har vært forandringer i posisjonslistene. Hver seksjon består av GID og LPL fra MO-loggposten.

Både posisjonslisten og en deltaliste kan komprimeres.

Opplegget av posisjonslisten og deltalisten er angitt i den følgende pseudokode. PositionList er posteringsopplegget for posisjonslisten. Documentlnfo inneholder informasjon om et dokument. Occurrencelnfo er informasjon om hver forekost av ordet. DeltaList er postopplegget for deltalisten. Hver innførsel i deltalisten har postformatet DeltaEntry.

Klammeparentesene {, } om utsagn markerer "Begin" og "End". Kommentarer til kodene følger etter skråstrekene i kolonnen til høyre. Bemerk at det ikke er noen GID i posisjonslistene, da de bare er kodet i datakatalogen. Det kan være mange posisjonslister for det samme ord i forekomstfilen, da de vil representere forskjellige kontrollpunkter. En gammel posisjonsliste kan ikke fjernes fra forekomstfilen så lenge den er søkbar. Filen må være en viss brøkdel større enn de data den indekserer, og dette kan sannsynligvis være selvavstembart.

For store fprekomstinnførsler kan filen splittes den i mindre avsnitt som hver komprimeres separat (f.eks. for hvert dokument eller for hvert n'te dokument). Én overhoppliste gjør det mulig å hoppe over avsnitt som ikke tilsvarer noen andre uttrykk, for å øke hastigheten for sammensatte søkespørsmål.

3. 1. 3. 1 Håndterting av ledig plass

Forekomstfilen vil vokse over tid, med mindre plassen til gamle forekomstinnførsler brukes på ny. For å gjøre dette kan det benyttes en sirkulær buffer strategi. Dette er vist på fig. 4.

Forekomstfilen bør starte med en spesifisert, fast størrelse. Slutten av filen snor seg rundt tilbake til begynnelsen (med unntagelse av filtittelen). Den ikke-ledige del av filen befinner seg mellom to pekere i filen, halen og hodet. Alle nye og oppdaterte innførsler skrives ved hodet, hvor den ledige plass krymper. På halen kopieres benyttede områder til hodet og vil være en del av den foreliggende åpne generasjon. Ubenyttet plass vil frigjøres og arealet av den ledige plass øke. For å frigjøre plass, er det nødvendig å kjenne den eldste generasjon OG som skal være søkbar.

Forekomstfilen alene har ikke noen informasjon om hvilke områder som er ubenyttet eller ikke. Dette må hentes fra datakatalogen og loggen. Hver gang det ønskes å frigjøre plass, er det nødvendig å utføre en sekvensiell avsøking av loggen og datakatalogen. Hver slik avsøking kalles en datasaneringsavsøking (GC-avsøking). Dette kan gjøres ved følgende tiltak:

1. Avvente starten på et kontrollpunkt.

2. Avsøke datakatalogfilen. Registrer n ord med en posisjonsliste nærmest halen og tilføy datakataloginnførselen til datakatalogminnet (hvis den ikke allerede er der), n bør være satt for å begrense hovedminnefprbruket, men samtidig frigjøre så mye plass som mulig i en avsøking. Hvilke som helst av disse ordene som sjekkpunktes ved dette sjekkpunkt, håndteres spesielt. 3. Området fra halen ( X) til den seneste av de n ordene ( Y) er en kandidat for frigjøring. Beregn plassen som er nødvendig for å flytte posisjons-og deltalistene for disse ordene til hodet. Alloker plassen, og flytt hodet. 4. Start fra X og kopier n ord til plassen allokert under punkt 3. Kombiner generasjoner som ikke lenger er søkbare fra deltalisten og loggpostene som er kontrollert og flett dem sammen i posisjonslisten. Generer nye deltalister med oppdateringer fra de søkbare generasjoner. For alle ord bør deltalisten skrives umiddelbart etter posisjonslisten. For større ord skal det allokeres noe ekstra plass for vekst. 5. Oppdater i forbifarten innførslene i datakatalogminnet med nye steder for posisjons- og deltalister. Skriv nye MD-loggposter. Dette kan gjøres i store satser og bør være meget effektivt.

6. Skriv nye datakataloginnførsler til datakatalogfilen.

7. Avvent fullføring av sjekkpunktingen.

8. Flytt halen og frigjør plassen mellom X og Y.

Den ovennevnte algoritme sikrer at en GC-avsøking kan vare mer enn en generasjon.

Det er mulig å ha to eller flere forekomstfiler. En fil kan inneholde ord som forandrer seg hyppig, mens det andre inneholder ord som er mer statiske. Dette gjør det mulig å foreta en mer effektiv datasanering av posisjonslistene.

3. 1. 3. 2 Endre størrelsen av forekomstfilen

Det er mulig å endre størrelsen av forekomstfilen ved utelukkende å tilføye plass ved slutten av filen neste gang halepekeren kommer til slutten av filen. Hvis man behøver plassen umiddelbart, er det mulig å tilføye den ved slutten, og deretter sette hodet og halen henholdsvis vendt mot starten av den nye, ledige plass og starten på filen.

Det er også mulig å krympe forekomstfilen når halen kommer til slutten av filen Og omslutter den hele veien rundt. Filen kan deretter trunkeres et sted mellom hodepekeren og slutten.

Den ledige plass kan automatisk justeres hver gang halen når slutten av filen. Innstill to terskelverdier (nedre og øvre), gitt enten i byter eller som prosent av filstørrelsen. Hvis plassen mellom hodet og halen overskrider den øvre verdi, trunkeres filen slik at ledig plass befinner seg et sted mellom tersklene (f.eks. midten). Hvis den faller under den nedre verdi, blir filen utvidet til en verdi mellom den øvre og nedre. For eksempel er den nedre terskel 20% og den øvre 30%.

3. 1. 4 Generasjonsavbildning

Da generasjonsidentifikatoren GID er en alltid økende variabel og kan forandre seg hyppig (f.eks. en gang i sekundet), må den være stor (minst 32 bit) og dette fører til en betydelig plasskostnad i indeksen. Det er mulig å spare noe av denne plassen ved å benytte en indirekte mekanisme. Et generasjonskart kan avbilde fra en kort mellomliggende generasjonsidentifikator IGID, f.eks. 16 bit) til en større GID (f.eks. 64 bit). Når alle forekomster av en IGID er blitt fjernet fra indeksen, kan den benyttes om igjen ved bare å modifisere generasjonsavbildningen. For å gjøre dette må loggen ha rotert en gang (alle loggposter med den gamle IGID er overskrevet) og datakatalogen være avsøkt og alle ord med gamle IGID oppfrisket med de nye.

3. 2. Hovedminnestrukturer

Relasjonen mellom platelager eller masselager og hovedminnestrukturer er vist på fig. 5. Boksene med dobbeltramme er platelagerbaserte. Tallene i boksene er GID. Tallene i parentes er implisitte. De to tall i MD-loggpostene angir henholdsvis generasjonen til posisjonslisten og generasjonen når datakataloginnførselen ble endret.

3. 2. 1 Loggbuffer

Loggbufferen består av alle loggfiler avbildet til i hovedminnet. Loggpostene kan aksesseres av logiske pekere som peker inn i loggfilene. En slik logisk peker består av et filnummer og en forskyvning til filen som kan benyttes til å beregne den fysiske adresse.

3. 2. 2 Datakataloghurtigminne

Datakataloghurtigminnet lagrer innførslene fra datakatalogfilen. Den vil befinne seg i den regulære klynge og ha et maksimal størrelsesparameter (antall innførsler). De fleste systemer vil være i stand til å hurtiglagre hele datakatalogen. Bare systemer med små hovedminner eller et ekstremt høyt antall ord vil behøve å aksessere platelagre som en del av et datakatalogoppslag.

All aksess til innførsler i datakataloghurtigminnet må gå gjennom ordhurtigminnet. Det må derfor alltid foreligge en ordminneinnførsel så lenge datakatalogminneinnførselen foreligger.

Utskiftningsstrategien kan være LRU ("Least Recently Used"). Hver gang en innførsel aksesseres, plasseres den på slutten av en LRU-kjede.

3. 2. 3 Ordhurtigminne

Ordhurtigminnet er en minnestruktur med variabel størrelse som hurtiglagrer informasjon om ord i indeksen. Innførslene slås opp med bruk av ordet selv som nøkkel. Hurtigminneinnførselen inneholder to deler:

MOptr: En peker til en siste MO-loggpost for ordet og dets GID.

• CkptMOptr: En peker til den siste MO-loggpost for ordet og dets

GID.

• CkptMDptr: En peker to den siste MD-loggpost for ordet og dets GID for det foreliggende ufullstendige sjekkpunkt. • DCptr: En henvisning til innførselen i datakataloghurtigminnet (om noen).

Hurtigminnet er organisert som en LRU-struktur med evne til å låse innførsler i hurtigminnet (f.eks. ved å benytte henvisningstellere). Innførslene blir låst så lenge ordet utgjør en del av en ufullstendig kontrollpunktkjøring (den har en peker til en MO-loggpost), eller hvis det foreligger en innførsel i datakataloghurtigminnet for ordet. Hurtigminnet må ha en innførsel for hvert ord i det foreliggende, ufullstendige sjekkpunkt. Derfor kan det ikke være en øvre grense av størrelsen til ordhurtigminnet. I stedet bør det være en foretrukket størrelse. Hurtigminnet må være i stand til å vokse utover denne om nødvendig, men krympe igjen straks det ikke lenger behøves.

3. 3 Dynamisk oppførsel.

3. 3. 1 Indeksoppdatering

Indeksoppdateringene kommer inn som loggfilinnførsler fra indekseringsprosesseringen (MO- og GC-loggposter). De blir tilordnet et LSN-nummer og kopieres til minneavbildede filloggbuffere. Når en GC-loggpost er blitt kopiert, blir loggfilen flyttet til platelageret. Når loggposten er blitt skrevet, blir loggfiltittelen oppdatert med et nytt nivåmerke og skrives til platelageret. Når flyttingen er fullført, er generasjonen søkbar.

Når en MO-loggpost er blitt mottatt og kopiert til loggen, blir ordet innført i MOptr-feltet i ordhurtigminnet og låses der. Hvis den allerede foreligger der, sjekkes det om den peker til en annen logginnførsel for det samme ord. Hvis den nye logginnførsel tilhører det samme sjekkpunkt som den foregående logginnførsel, kjedes den i den foregående liste.

3. 3. 2 Loggsporing

Hvis det foreligger mer enn en søkenode som fremsetter søkespørsmål med bruk av de samme indeksfiler (f.eks. deler filene over et nettverkstilknyttet lager (NAS)), vil bare en av dem måtte oppdatere indeksen. De andre behøver bare å spore forandringene. Oppdatereren vil åpne indeksfilen som les/skriv, sporerne behøver bare å åpne dem for lesing. En ekstern størrelse avgjør hvilken node som er oppdatereren.

En sporende søkenode sporer de nye MO- og MD-innførsler i loggen og etter hvert som de tilføyes, oppdateres MOptr- og CkptMDptr-feltene i samme ordhurtigminne. CkptrMOptr blir ikke benyttet. Hvis den leser en CP-logginnførsel, tilbakestiller den MOptr- og CkptMDptr-feltene og frigjør alle innførsler i ordhurtigminnet og fjerner innførslene i datakataloghurtigminnet for dette ord for å ugyldiggjøre innførselen.

3. 3. 3 Sjekkpunktin<g> (" Checkpointing")

Bare oppdateringsnodene behøver å oppdatere indeksfilene basert på loggpostene for indeksoppdateringen. Denne prosessen kalles en sjekkpunkting ("checkpointing"). En sjekkpunkting starter etter at det har medgått et bestemt tidsintervall etter siste sjekkpunkting, eller når volumet av MO-loggpostene i loggen etter den siste sjekkpunkting overskrider en viss grense. En sjekkpunkting utføres som følger:

- avvent fullstendig generasjon

- kopier alle MOptr-verdier til CkptMOptr for alle verdier i ordhurtigminnet. Tilbakestill MOptr.

- for hvert ord i datakataloghurtigminnet (muligvis i parallell)

o les alle MO-loggposter for ordet

o les datakataloginnførselen for ordet

o les deltalisten for ordet fra forekomstfilen (om den finnes)

o tilføy loggposter til slutten av deltalisten

o om det er plass

skriv den nye deltalisten til det opprinnelige sted

o om det ikke er plass

alloker plass ved hodet til forekomstfilen og oppdater hodepekeren

skriv den nye deltaliste til det allokerte sted

o generer én MD-loggpost og skriv den til platelageret o sett CkptMDptr til å peke på den nye MD-loggpost o oppdater datakataloginnførselen

- skriv kontrollpunktloggposten til loggen og flytt loggen til platelageret

- frigjør innførselen i ordhurtigminnet

Hvis posisjonslisten passer i datakataloginnførselen, behøver ikke posisjonslisten å skrives til forekomstfilen. Datakataloginnførselen skal ikke slettes hvis posisjonslisten tømmes. (Den kan bli gjenstand for en datasanering senere etter én syklus gjennom loggfilene.)

For systemer med store hovedminner vil hele datakatalogen og loggen få plass i minnet. For de øvrige må platelageraksessmønsteret optimeres. Følgende tiltak foreslås: ordne ordene behandlet under en sjekkpunkting i økende ordorden (det antas et B+-tre) - prosesser et gitt antall ord i satser (f.eks. 1000). På grunn av ordningen vil de befinne seg nær hverandre i datakatalog-B+-treet - benytt en prioritetskø for å avsøke gjennom loggen i omvendt orden inntil alle MO-loggpostkjeder for satsen er uttømt. Dette vil gi en tilnærmet sekvensiell avsøking gjennom loggen - skriv deltalistene som må fjernes, sekvensielt til et område med stor ledig plass i forekomstfilen. Dette vil resultere i bare noen få skrivinger, kanskje bare én eneste én

- skriv MD-loggpostene i satser

- skriv oppdaterte datakataloginnførsler til B+-treet. På grunn av nærheten vil det være færre skrivinger.

3. 3. 4 Søkespørsmålsprosessering

Et søkespørsmål kommer med et ord og generasjonsidentifikator QGID som søkespørsmålet kjøres i. Den følgende prosedyre gjelder:

- Hvis QGID er nyere enn den siste GC-loggpost skrevet til platelageret, skal søkespørsmålet vente inntil loggposten er blitt skrevet. - Hvis den allerede foreligger, genereres en hurtigminneinnførsel i ordhurtigminnet. - Hvis den ikke allerede er lagret i hurtigminnet, les

datakataloginnførselen for ordet. Det behøver ikke å eksistere.

- Les posisjons- og deltalisten fra forekomstfilen (om noen) med bruk av adressene i datakataloginnførselen. Les MO-loggpostene om nødvendig (gitt at de finnes). Flett sammen posisjonslisten med alle oppdateringer fra generasjonen mindre eller lik QGID. De kan befinne seg i deltalistene og/eller MO-loggpostene. Avhengig av QGID, behøver det ikke å være nødvendig å lese deltalistene eller loggpostene.

3. 3. 5 Start og gjenoppretting

Når en node starter, leser den topptekstene til alle loggfiler og finner stedet for den siste kontroll. Fra kontrollstedet leser den loggen sekvensielt og gjenbefolker ordhurtigminnet med bruk av MO-loggpostene. Eventuelle MD-loggposter i loggen blir rett og slett ignorert. Generasjoner registreres etter hvert som loggen leses. Nå kan noden åpnes for nye søkespørsmål.

En oppdaterer starter en ny sjekkpunkting basert på de siste GC-loggpost (om den ikke allerede eksisterer). Den vil deretter informere indekseringsprosessen (indeksereren) at den ikke er klar til å motta loggpostinnførsler. Den skaffer GID for den siste GC-loggpost som et startpunkt. Indeksereren vil potensielt videresende loggpostene til en ufullstendig generasjon, men dette spiller ingen rolle da loggpostene er idempotente.

3. 3. 6 Kontrollert stans

Oppdaterernoden vil vente til en GC-loggpost er mottatt. Den vil deretter stanse alle nye søkespørsmål og starte en sjekkpunkting. Når denne kjøringen er fullført, vil den avslutte noden.

Sporing av søkenoder kan avsluttes øyeblikkelig.

4. Ytelsesevaluering

I dette avsnittet skal den potensielle ytelse til den nye indeks evalueres. Det antas en zipf-fordeling av ordene i dokumentene og identisk fordeling for ord i søkespørsmålet. Den viktige parameteren er det totale antall ordforekomster, ikke antall dokumenter eller ord pr. dokument.

Antall forskjellig ord V i en samling av n ord, er gitt av Heaps lov:

V = KnB med konstanter K, 0 < 0 <<> 1

Typiske konstanter er K~ 10-100 og/? ~ 0,4-0,6. Her antas

K = 50 and = 0,5 (kvadratrot).

Tabell 1 - Antall av ent<y>dige ord i en samling av gitt størrelse

For et stort antall ord utgjør de 5000 mest frekvente ord omtrent 90 % av det totale antall ordforekomster. Dette er omtrent uavhengig av det totale antall dokumenter. (Se tabell 2.) Tabell 2 - Andelen av det totale antall forekomster for de mest frekvente ord

For den resterende del av dette avsnitt antas en stabil indeks med 10 000 000 000 ord og en oppdateringsrate på 10 000 000 ord pr. kontrollkjøring. Med gjennomsnittlig 1 000 ord pr. dokument vil det henholdsvis has 10 000 000 og 10 000 dokumenter.

Det antas at det ikke foreligger noen kompresjon.

4. 1 Størrelsen av indeksstrukturen

Det vil befinne seg 5 000 000 forskjellige ord i datakatalogen og hver innførsel vil være på omtrent 50 byter. Antas en plasskostnad på 100 % i B+-treet vil størrelsen på datakatalogen være 500 MB.

Loggen må være stor nok til å romme alle loggposter etter den aller siste sjekkpunkting. Ved beregning av tilnærmede størrelser for loggpostene blir resultatet mindre enn 200 MB pr. sjekksum, dvs. 400 MB. Dette må få plass i hovedminnet.

Bruk en vekstmargin på 5 % for plassering av de 5000 største innførslene i forekomstfilen. Dette vil gi en statisk kostnad på 4.5 %. Dette vil kreve gjennomsnittlig 50 sjekkpunktinger før den ekstra plassen flyter over og hele innførselen må skrives til et nytt sted. Det antas at datasaneringen i de fleste tilfeller allerede har skrevet den på ny før dette skjer. De siste 10 % av ordene vil bli skrevet sekvensielt ved hodet. Noen av disse ordene vil bli oppdatert i flere generasjoner og må skrives flere ganger. Det antas en kostnad på 1 % på grunn av disse oppdateringer.

I henhold til zipf-fordelingen vil det hyppigst forekommende ord utgjøre

10 % av det total volum i forekomstfilen. Filen må være i stand til å lagre dette ord to ganger, noe som fører til en kostnad på 10 %. Tilføyes ytterligere 10 % som sikkerhetsmargin og plass for datasanering får man til slutt en total kostnad på 30 %. Denne marginen kan reduseres hvis stoppord fjernes.

4. 2 Hovedminnets fotavtrvkk

For optimal ytelse må datakatalogen og delen av loggfilen etter den siste sjekkpunkt foreligge i hovedminnet.

Det skal være en logg for en sjekkpunkting i minnet, dvs. 200 MB.

Ordhurtigminnet må sannsynligvis være i stand til å håndtere 200 000 innførsler, dvs. 10 MB.

Datakatalogen vil utgjøre 500 MB, men en hurtigversjon av hovedminnet kan gjøres mye mer kompakt, eksempelvis 300 MB.

Det er nødvendig med arbeidsplass for datasaneringsprosessen og spørsmålsprosesseringen. Det mest frekvente ord vil utgjøre 10 % av totalvolumet i forekomstfilen. Dette kan kopieres/prosesseres i mindre deler, slik at mellomlageret med buffere med moderat størrelse vil være tilstrekkelig (f.eks. 10-100 MB pr. tråd).

4. 3 Antall platelageraksesser for indeksoppdatering

En hel generasjon kan skrives med en enkelt sekvensiell skriving.

4. 4 Antall platelageraksesser for en kontrollpunkt

Hvis den ikke får plass i minnet, leses loggen etter den siste sjekkpunkting sekvensielt (200 MB).

Hvis den ikke får plass i minnet, leses datakatalogen sekvensielt (500MB).

Les 158 000 deltalister slumpmessig (tallet er sannsynligvis mye lavere; dette er antallet i verste tilfelle). Om aksessene kan ordnes ved å øke platelagerposisjonene, vil denne lesningen halvt på vei skje sekvensielt. De hyppigst forekommende ord vil sannsynligvis hurtiglagres (de vil sannsynligvis også ha de største deltalister).

Skriv 5 000 deltalister slumpmessig og 153 000 sekvensielt.

Skriv 158 000 MD-loggposter sekvensielt (5 MB).

Skriv datakatalogen sekvensielt (500 MB).

4. 5 Antall platelageraksesser for datasaneringsavsøking Hvis datakatalogen ikke får plass i minnet, må datakatalogen leses sekvensielt.

Les sekvensielt det areal av platelageret som er under avfallssanering og plukk opp posisjons- og deltalistene som flyttes. Les slumpmessig deltalistene som ikke er samplassert med sine posisjonslister. I verste tilfelle foreta en sekvensiell lesning av den fullstendige forekomstfil. Skriv sekvensielt den nye posisjons- og deltalistene ved hodet.

Skriv sekvensielt nye MD-loggposter. Oppdater datakatalogen (i verste tilfelle skriv om hele datakatalogen sekvensielt).

I tillegg vil det være I/O (Input/Output) fra den forbundne sjekkpunkting.

4. 6 Antall platelageraksesser for stikkordoppslag

I de fleste tilfeller skal det være mulig å gjenfinne et stikkord med bare én sekvensiell platelageraksess. Bare i tilfellet hvor ordet er blitt forandret etter siste datasanering og posisjonslisten og deltalisten ikke er samplasserte, vil det være nødvendig med to platelageraksesser. For tallene gitt ovenfor, er det tale om mindre enn 10 % av tilfellene. De to platelageraksesser kan gjøres i parallell.

Hvis datakatalogen ikke får plass i minnet, vil det være nødvendig med en ytterligere platelageraksess for å lese datakataloginnførselen.

Hvis loggen ikke får plass i minnet, kan det i verste tilfelle foreligge en ekstra platelageraksess for hver MO-loggpost. Aksessene vil være slumpmessige, men vil befinne seg innenfor en mindre begrenset område på platelageret (delen av loggfilen etter start av siste sjekkpunkting).

4. 7 Friskhet

Et dokument vil være søkbart straks:

• Generasjonen den utgjør en del av, er fullstendig. Mindre sjekkpunkting betyr kortere latens, men mer arbeid mens sjekkpunktingen foregår. • Alle dokumenter i generasjonen må være prosessert ved eksekveringen av dokumentprosesseringen og i indekseringstrinnene som frembringer MO-loggpostene. • Alle ordene i generasjonen må ha vært tilføyd til ordhurtigminnet.

Dette avhenger av størrelsen på generasjonen, men vil i de fleste tilfeller utgjøre millisekunder i CPU-tid. • Alle loggposter i generasjonen må være skrevet til loggen. Da dette kan gjøres med enkelt sekvensiell skriving, dreier det seg om mindre enn ett sekund. • Informasjonen om tilgjengeligheten av den nye, søkbare generasjon må transporteres til QR-tjeneren.

5. Generisk oppdaterbar indeks

Den oppdaterbare inverterte listeindeks beskrevet ovenfor kan generaliseres for de fleste indekstyper. I de generiske tilfeller er det nødvendig med

følgende filer

- loggfil(er)

- adressekatalog

- datafil

For den inverterte liste er datakatalogen i adressekatalogen og forekomstfilen datafilen. Adressekatalogene representerer et indireksjonstrinn ("indirection step") som gjør det mulig å opprettholde flere versjoner av de samme data. For hvert indeksert element må det foreligge en peker til datafilen og en generasjonsidentifikator. Loggfilen vil inneholde identiske loggposter, og sjekkpunktingen være den samme.

Anta en attributtvektor som et eksempel. For nærværende blir attributtvektoren aksessert med bruk av dokumentidentifikatoren som nøkkel. Alle elementer har samme størrelse, og posisjonen i filen kan beregnes direkte for en oppdaterbar attributt. For en oppdaterbar attributtvektor kan posisjonen i katalogen i stedet beregnes direkte (alle innførsler i katalogen har samme størrelse). Ved å lese innførselen i katalogen vil det finnes en peker til attributtverdien i datafilen og dens GID. Hver gang attributtverdien forandres, skrives en loggpost til loggen. Ved tidspunktet for sjekkpunkting skrives den nye verdi til et nytt sted i datafilen.

Utvilsomt har denne tilnærming en rekke svakheter sammenlignet med en enkel direkte implementering av aksess, da den - ikke vil skaffe sekvensiell aksess når dokumenter skannes i stigende orden

- alltid vil måtte gjennomgå et nivå av indireksjon ("indirection")

- består av flere filer

- har høy plassredundans

- har en kompleks strategi for forvaltning av ledig plass

På den annen side muliggjør den evnen til dynamisk oppdatering og krever ikke at vektorelementene skal ha en fast størrelse.

Hvis det er en rekke attributtvektorer, kan de dele den samme katalog og redusere plassadministrasjonen.

6. Spesielle forhold

6. 1 Dokument- og forekomsttelling

Datakatalogen inneholder dokument- og forekomsttellingen av et ord bare for innførsler i posisjonslistene. For å få eksakte tall for en gitt generasjon er det nødvendig å kombinere den med informasjon i deltalisten. Uheldigvis vil dette være vanskelig hvis et dokument er slettet eller oppdatert (det vil være nødvendig å subtrahere den tidligere forekomsten).

6. 2 Flere samtidige indekser

Kjente søkesystemer benytter mange inverterte listeindekser samtidig. For den nye, oppdaterbare indeks i henhold til oppfinnelsen kunne det også benyttes separate datakatalog- og forekomstfiler. For å oppnå best ytelse ville det på den annen side sannsynligvis foreligge en enkelt felles logg for hver partisjon. Oppdateringene som kommer inn til disse mange indekser kan da skrives inn i loggen med en enkelt skriving, noe som sparer en mengde forflytninger av platelagerhodet.

6. 3 Sammendbrudd av oppdaterernode

Hvis en oppdaterernode bryter sammen, må dette detekteres og en annen node (f.eks. en sporingsnode) forvandles til en oppdaterernode. Den må foreta normal gjenoppretting og vente på at indekseringsstrømmen skal rettes mot seg.

6. 4 Inderkseringspipeline

Det kan være mange in^ekseringslinjer ("pipelines") som fører oppdateringer til samme oppdaterernode. Hvis det er flere oppdateringer til samme dokument, bør de fremsendes i samme linje.

Indekseringsprosessen er også ansvarlig for å mate ufullstendige generasjoner på ny etter et sammenbrudd.

En oppdaterernode må avvente generation complete fra alle indekseringsprosesslinjer før den kan skrive generation complete til sin egen logg-

6. 5 Direktekoblede forandringer av indeksen

6. 5. 1 Tilføy loggfil

En loggfil kan tilføyes ved rett og slett å sette den inn i listen av loggfiler. Den bør settes inn i sekvensen etter loggfilen som det for nærværende skrives til. Før den er tilføyd, bør loggfilen ha en gyldig loggfiltopptekst. Filen må også avbildes i minnet.

6. 5. 2 Fjerning av loggfil

En loggfil kan fjernes når den er den neste i sekvensen som det skal skrives til. Først må alle sjekkpunkter i filen fjernes fra sjekkpunktindeksen. Deretter kan filen fjernes fra listen av loggfiler og avbildningen av filen fjernes og lukkes.

Hvis en bruker ønsker å fjerne en spesifikk loggfil, må brukeren plassere den i kø for fjerning, og vente inntil den blir den neste fil. Dette kan ta lang tid hvis det er få eller ingen pågående indeksoppdateringer.

Det skal aldri være mindre enn to loggfiler.

6. 5. 3 Forandre størrelse på loggfilen

Dette gjøres ved å slette loggfilen, redimensjonere den og modifisere toppteksten og deretter tilføye den.

6. 5. 4 Forandre datakatalogens størrelse

Om det velges å lagre datakatalogen i B+-treet, vil den automatisk vokse når data settes inn i den. Å krympe den er vanskeligere, men behøver ikke å være nødvendig.

6. 6 Ufullstendig platelagerskrivinger

Den nåværende indekseringsstrategi med flere generasjoner håndterer sammenbrudd under indeksering godt. Hvis det forekommer et sammenbrudd før indeksen er fullstendig, startes den bare på ny.

Det er nødvendig å være omhyggelig for å beholde denne oppførselen med den nye oppdaterbare indeks. Loggfilen gjør det mulig å utføre en operasjon på ny om den svikter. Det største problemet er når det på stedet foretas oppdatering av data på platelagre. Det følgende scenario kan da forekomme.

1. Les to påfølgende sektorer fra platelageret.

2. Oppdater dataene og generer en loggpost som skrives til platelageret. 3. De oppdaterte data forsøkes skrevet til de samme sektorer som ble lest i trinn 1. 4. Datamaskinen bryter sammen slik at bare den første sektor skrives;

ikke den annen.

Hvis det has en avansert lagringsgruppe, vil trinn 4 ikke forekomme. Men den kan forekomme med billigere lagringsløsninger. Problemet er at det ikke lenger er mulig å gjenskape de nye data ved å lese de to sektorer og benytte loggposten, da dataene er korrumpert. Løsningen er enten 1. Å beholde dataene i loggposten slik at det ikke er nødvendig å lese de opprinnelige data for å rekonstruere de nye data,

eller

2. Bare å tilføye data til det oppdaterte område og benytte noen signaturfelter for å se hva som er fullstendig eller ikke.

For den oppdaterbare indeks oppstår dette problemet for en deltaliste som umiddelbart følger etter forekomstlisten. Den kan oppdateres på stedet flere ganger.

7. Mulige forbedringer

7. 1 Samtidig oppdaterere

Det kan være mulig å tillate flere datamaskiner å utføre sjekkpunktingen og datasanering samtidig på den samme indeksstruktur ved å partisjonere ordene (områdepartisjonering vil sannsynligvis være best). Start og stopp av en sjekkpunkting, allokering av plass ved hodet ved forekomstfilen og oppdatering av datakatalog må koordineres. Loggfilen kan partisjoneres.

7. 2 Stoppord og støtte av frasesøk

Forekomstlister for stoppord vil være meget store og vil være kostbare å lese fra platelageret, og kjøre en sammenligning mot og oppdatere. Oftest vil stoppord bare ha verdi for frasesøk. En posocc-fil støtter frasesøk, men er mer kostbar når stoppord foreligger i søkespørsmålet enn ved bruk av en dedikert frasesøkfil.

Det er mulig å dele forekomstlistene for stoppord i mindre forekomstlister. I stedet for å indeksere stoppord alene, indekseres det med det følgende ord. I stedet for å indeksere "the", bør det for eksempel indekseres "the camel", "the car", og "the eat" etc.

7. 3. Kompresjon

Kompresjon er ikke blitt drøftet her. Kompresjon bør tas i betraktning både i forekomstfilen (posisjons- og deltalister), datakatalogen og loggfilen. Det kan være vel så viktig å komprimere dataene når de befinner seg i minnet som på platelageret. Hurtiglagring av dataene på komprimert form vil øke CPU-forbruket for aksess til disse, men vil øke hurtigminnets treffandeler og redusere platelager-I/O.

7. 4 Flere forekomstfiler

Flere forekomstfiler kan foreligge avhengig av ordstørrelse og oppdateringsfrekvens. Dette kan gjøre det mulig å optimere filsystemparametre i store lagringsmatriser og datasaneringsstrategier. Ikke samplasserte deltalister kan også plasseres i sine egne forekomstfiler.

8. Avsluttende bemerkninger

Fremgangsmåten i henhold til den foreliggende oppfinnelse virker effektivt for indeksstrukturer med en oppdaterbar, invertert listeindeks med full posisjonsinformasjon (posocc). Den kan også benyttes til en bolocc-indeks uten store forandringer. Et tilsvarende opplegg kan benyttes for andre indeksformater.

Alt i alt beskjeftiger den foreliggende oppfinnelse seg med et hittil uutforsket område med hensyn til indekser og indeksoppdatering, slik at for eksempel de statistiske aspekter ved dokumentegenskapene kan føre til uventede effekter. Fremgangsmåten i henhold til den foreliggende oppfinnelsen vil forekomme mer komplisert enn tidligere indekseringsmetoder og gir en mer kompleks indeksstruktur. For å oppnå hensikten er det nødvendig at det has tilstrekkelig minne for databaseloggen og datakatalogen. Imidlertid kan kompleksiteten til fremgangsmåten i henhold til oppfinnelsen og indeks- og kapasitetskravene for implementering av den på et masselager så som et platelagerminne, i det lange løp ses som marginale faktorer. De mer enn oppveies av de mange fordeler ved fremgangsmåten i henhold til foreliggende oppfinnelse. En indeks generert og oppdatert med fremgangsmåten i henhold til oppfinnelsen vil alltid gi en meget god friskhet og være helt konsistent, samtidig som det har en mye lavere lagringskostnad enn nåværende indekser. I tillegg vil det bare være en partisjon og dette innebærer færre minneaksesser under oppslag av en søketerm. Dessuten

. støtter den foreliggende oppfinnelse multitrådprosesser under datasanering

og sjekkpunkting, felles filsystemer (NAS; engelsk: "Network Attached Storage") med én oppdaterer og en rekke søkeklienter. Endelig vil den dynamiske, oppdaterbare indeks realisert ved fremgangsmåten i henhold til den foreliggende oppfinnelse muliggjøre søk som foregår over lang tid uten å avbryte indekseringen og skade indeksens friskhet.

Claims (11)

1. Fremgangsmåte for dynamisk oppdatering av en indeks i en søkemotor, hvor søkemotoren er implementert på én eller flere tjenere som omfatter en masselagringsinnretning og hvor indeksen er en invertert indeks som omfatter en datakatalog, en posteringsfil med posteringslister for hvert stikkord i indeksen og en databaselogg, og hvor fremgangsmåten er karakterisert ved trinn for å innsette dokumenter i indeksen i små satser, idet hver sats utgjør en oppdateringsgenerasjon av indeksen; å generere en liste over alle forekomster av stikkord i dokumentene i hver oppdateringsgenerasjon, å sette forekomstlisten inn i databaseloggen, og å danne for hvert stikkord innført i databasen en henvisning til en tidligere innførsel av samme stikkord i databaseloggen, idet den tidligere innførsel har en referanse lagret i masselagerinnretningen som den sist tilføyde innførsel av alle senest tilføyde stikkord.

2. Fremgangsmåte i henhold til krav 1, karakterisert ved å gruppere alle oppdateringer av databaseloggen sammen med spesifiserte intervaller, å flytte de grupperte oppdateringer til posteringsfiler, og å lagre hvert stikkord henholdsvis i en forekomstliste i form av forekomstene av alle stikkord som er eldre enn en bestemt oppdateringsgenerasjon, og en deltaliste i form av en mengde av mindre oppdateringer senere enn den nevnte oppdateringsgenerasjon, slik at datakatalogen inneholder en innførsel for hvert stikkord i posteringsfilen og en referanse til forekomstlisten og deltalisten.

3. Fremgangsmåte i henhold til krav 2, karakterisert ved å lagre forekomstlisten og deltalisten i posteringsfilen.

4. Fremgangsmåte i henhold til krav 2, karakterisert ved å implementere datakatalogen som et B-tre.

5. Fremgangsmåte i henhold til krav 4, karakterisert ved å lagre forekomstliste og deltaliste som er mindre enn en spesifikk størrelse i B-treet.

6. Fremgangsmåte i henhold til krav 2, karakterisert ved å skyve databaseloggen til masselagringsinnretningen ved slutten av hver oppdateringsgenerasjon, slik at indeksen kan innhentes i tilfelle av en brå svikt eller stopp av søkemotoren ved å avspille databaseloggen og gjenskape stikkordinnførslene i hovedminnet inntil den siste oppdatering i databaseloggen for hvert stikkord.

7. Fremgangsmåte i henhold til krav 2, karakterisert ved å organisere posteringsfilen som en sirkulær fil slik at ubrukt plass gjenvinnes som halen til denne5 og eksisterende stikkordinnførsler flyttes til dens hode.

8. Fremgangsmåte i henhold til krav 7, karakterisert ved å tilføye en stikkordinnførsel ved slutten av posteringsfilen hvis det ikke finnes plass til å flytte en eksisterende innførsel eller til å tilføye et nytt stikkordinnførsel.

9. Fremgangsmåte i henhold til krav 2, karakterisert ved å behandle responsen på et søkespørsmål som et stikkordoppslag ved å gjenfinne datakataloginnførselen, å lese hovedforekomstlisten og deltalisten fra posteringsfilen ved hjelp av datakataloginnførselen, og å slå sammen forekomstlisten og deltalisten sammen med eventuelle innførsler av stikkordet i databaseloggen til en eneste forekomstliste, slik at denne ene forekomstliste kan benyttes til videre behandling av et søkespørsmål.

10. Fremgangsmåte i henhold til krav 9, karakterisert ved å utføre sammenslåingen av forekomstlisten og deltalisten uten å innbefatte en oppdateringsgenerasjon senere enn spesifisert generasjon, slik at søkespørsmålet kan behandles for forekomster av stikkord som forekommer ved slutten av den spesifiserte generasjon.

11. Søkemotor (100) som implementerer en fremgangsmåte for dynamisk oppdatering av en indeks til en'søkemotor, hvor søkemotoren er implementert på én eller flere tjenere som omfatter en masselagringsinnretning, hvor søkemotoren omfatter en kjernesøkemotor (101) med et søkeundersystem (101b) og et indekseringsundersystem (101a) for å generere en stikkordindeks lagret på masselagringsinnretningen, og hvor indeksen er en invertert indeks som omfatter en datakatalog, en posteringsfil med posteringslister for hvert stikkord i indeksen og en databaselogg, karakterisert ved at indeksen er en dynamisk oppdaterbar indeks.