NO327318B1 - Fremgangsmåte for å forbedre effektiviteten til en søkemotor - Google Patents

Abstract

I en fremgangsmåte for å forbedre effektiviteten til en søkemotor ved aksessering, søking og gjenfinning av informasjon i form av dokumenter lagret i dokument- eller innholdsmagasiner omfatter søkemotoren en gruppe av søkenoder anbrakt på en eller flere tjenere. En indeks for de lagrede dokumenter dannes. Søkemotoren behandler et søkespørsmål fra en bruker og returnerer en resultatmengde av dokumenter som tilsvarer søkespørsmålet. Søkemotorens indeks konfigureres på basis av én eller flere dokumentegenskaper og partisjoneres, reproduseres og fordeles over gruppen av søkenoder. Søkespørsmålene behandles på basis av den fordelte indeks. Fremgangsmåten realiserer en struktur for å fordele indeksen til en søkemotor over en rekke verter i en datamaskinklynge og er basert på tre ortogonale mekanismer for indeksfordeling, nemlig indekspartisjonering, indeksreproduksjon og tilordning av replikkene til vertene. På denne måte fås det forskjellige måter for å konfigurere indeksen til en søkemotor, og det skaffes en sterkt forbedret ressursutnyttelse kombinert med hvilken som helst ønsket grad av feiltoleranse.

Description

Oppfinnelsen angår en fremgangsmåte for å forbedre effektiviteten til en søkemotor ved aksessering, søking og gjenfinning av informasjon i form av dokumenter lagret i dokument- eller innholdsmagasiner, hvor et indekseringssystem i søkemotoren nedsamler de lagrede dokumenter og genererer en indeks for disse, hvor anvendelsen av en brukers søkespørsmål på indeksen vil returnere til brukeren en resultatmengde med i det minste noen dokumenter som tilsvarer søkespørsmålet, og hvor søkemotoren omfatter en gruppe av søkenoder plassert på én eller flere tjenere.

Spesielt viser oppfinnelsen hvordan en ny struktur for indeksfordeling på en søkemotor, og enda mer spesielt på en bedriftssøkemotor, kan dannes.

Å bygge en søkemotor byr på utfordringer av flere grunner:

• Ytelse. Latensen for å beregne et søkespørsmålsrespons må være meget lav og bedriftssøkemotoren må støtte en høy spørsmålsrate. • Skalerbarhet. Ytelsen må skalere med antallet dokumenter og ankomstraten for søkespørsmål. • Feiltoleranse. Søkemotoren må opprettholde høy tilgjengelighet og høy ytelse selv under maskinvarefeil.

For å tilfredsstille de ovennevnte tre krav, benytter søkemotorer sofistikerte metoder for å fordele sine indekser over en muligvis stor klynge av verter.

Kjent teknikk

En oversikt og drøftelse av kjent teknikk relevant for den foreliggende oppfinnelse skal nå gis. Alle litteraturreferanser identifiseres ved forkortelser i parentes på det passende sted i det følgende. En fullstendig bibliografi er gitt i et vedlegg ved slutten av beskrivelsen.

For å forbedre effektiviteten til søkesystemer er det nylig utført mye forskning på fordelingen av søkemotorindekser. Tidligere arbeider beskjeftiget seg med hvordan posteringslister skulle fordeles og undersøkte avveiningen mellom fordeling av posteringslister basert på indekstermer (her også kalt stikkord) og dokumenter [BadOl, MMROO, RNB98, TGM93, CKE<+>90, MWZ06]. Den foreliggende oppfinnelse tar utgangspunkt i den innsikt at et globalt valg mellom disse to alternativer er suboptimalt fordi de statistiske egenskaper til stikkord og dokumenter varierer i et typisk søkemiljø. Dette kan belyses av frasen "one size does not fit all" for to eksempler: • For et stikkord k hvis posteringsliste kan rommes på en enkelt minneside, vil fordelingen av k' s posteringslister over flere verter i realiteten øke responstiden for søkespørsmål som involverer k fordi mange verter vil være involvert i å gjenfinne posteringslisten selv om en enkelt vert ville være i stand til å gjenfinne posteringslisten med en enkelt minneaksess. For et stikkord k<1> hvis posteringsliste ikke får plass på en enkelt minneside, vil imidlertid fordelingen av k' posteringslister over mengden av verter redusere responstiden og forskjellige deler av posteringslisten kan gjenfinnes i parallell. • For et upopulært stikkord k som bare forekommer i noen få søkespørsmål, utgjør reproduksjonen av dets posteringsliste et spill av ressurser, da det er små muligheter for parallellisme ved eksekvering av søkespørsmålene og således vil ikke mange søkespørsmål noensinne lese k' s posteringslister i parallell fra forskjellige verter. Posteringslisten for et forekommende populært stikkord k' vil imidlertid aksesseres av mange søkespørsmål og bør således reproduseres for å muliggjøre parallellisme.

For å bedre forstå kjent teknikk, skal det gis en kort drøftelse av en søkemotorarkitektur som kjent i teknikken og for tiden benyttet, med henvisning til fig. 1 som viser et blokkdiagram av en søkemotor slik den vil være kjent for fagfolk, dens viktigste undersystemer og dens grensesnitt respektive til et innholdsdomene, dvs. dokumentmagasinet som kan underkastes et søk, og et klientdomene som omfatter alle brukere som fremsetter søkespørsmål til søkemotoren for gjenfinning av spørsmåls-tilsvarende dokumenter fra innholdsdomenet.

Søkemotoren 100 i henhold til den foreliggende oppfinnelse og som kjent i teknikken, omfatter forskjellige undersystemer 101-107. Søkemotoren kan aksessere dokument- eller innholdsmagasiner som befinner seg i et innholdsdomene eller -rom, hvorfra innholdet enten kan aktivt skyves inn i søkemotoren eller med bruk av en datakobler trekkes inn i søkemotoren. Typiske magasiner innbefatter databaser, kilder som står til rådighet via ETL- (Extract-Transform-Load)verktøy slik 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 dokumentene analysert i et innholdsanalysetrinn 103, som også betegnes et undersystem for forhåndsprosessering av innhold for å forberede innholdet for forbedrede søke- og oppdagelsesoperasjoner. Typisk kan utdata fra dette innholdsanalysetrinn 103 være en XML-representasjon av inndokumentet. Utdata fra innholdsanalysen benyttes til å mate kjernesøkemotoren 101. Kjernesøkemotoren 101 kan typisk være anbrakt på en tjenerfarm på en desentralisert måte for å tillate prosessering av store dokumentmengder og høye spørsmålsbelastninger. Kjernesøkemotoren 101 aksepterer brukeranmodninger og frembringer lister av tilsvarende dokumenter. Dokumentordningen blir vanligvis bestemt i henhold til en relevansmodell som måler den sannsynlige betydning av et gitt dokument relativt til søkespørsmålet. I tillegg kan kjernesøkemotoren 101 frembringe ytterligere metadata om resultatmengden så som sammendragsinformasjon på dokumentattributter. Kjernesøkemotoren 101 i seg selv omfatter ytterligere undersystemer, nemlig et indekseringsundersystem 101a for nedsamling ("crawling") og indeksering av innholdsdokumenter og et søkeundersystem 101b for å utføre det egentlige søk og gjenfinning. Alternativt kan utdataene fra innholdsanalysetrinnet 103 mates inn i en valgfri varselmotor 104. Varselmotoren 104 vil ha lagret et sett av søkespørsmål og kan bestemme hvilke søkespørsmål som ville ha blitt tilfredsstilt av den gitte dokumentinngang. En søkemotor kan aksesseres fra en rekke forskjellige klienter og applikasjoner som typisk kan være mobile eller datamaskinbaserte klientapplikasjoner. Andre klienter innbefatter PDAer og spillinnretninger. Disse klientene, som befinner seg i et klientrom eller -domene, leverer anmodninger til et søkespørsmål 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 utvinne mer meningsfylt informasjon. Endelig blir utdata fra kjernesøkemotoren 101 typisk ytterligere analysert i et annet undersystem, nemlig et resultatanalysetrinn 106 for å frembringe informasjon eller visualiseringer som benyttes av klientene. - Begge trinn 105 og 106 er forbundet mellom kjernesøkemotoren 101 og klient-API 107, og i tilfelle varselmotoren 104 er til stede, er den forbundet i parallell med kjernesøkemotoren 101 og mellom innholdsanalysetrinnet 103 og søkespørsmåls- og resultatanalysetrinnet 105;106.

For å forbedre søkehastigheten til en søkemotor foreslår internasjonal publisert patentsøknad WO00/68834 en søkemotor med en todimensjonal, lineært skalerbar parallellarkitektur for søking i en samling av tekstdokumenter D, hvor dokumentene kan deles i et antall partisjoner di, d2,... d„, hvor samlingen av dokumenter D er forhåndsbehandlet i et tekstfiltreringssystem, slik at det fås en forhåndsbehandlet dokumentsamling Dp og tilsvarende forhåndsbehandlede partisjoner dp], dp2, ..., dpn, hvor en indeks / kan genereres fra dokumentsamlingen D slik at for hver tidligere forhåndsbehandlet partisjon dp], dp2, ..., dpn fås en tilsvarende indeks i}, i2,..., i„, hvor søking i en partisjon d av dokumentsamlingen D finner sted med et partisjonsavhengig datasett dp k, hvor 1< k < n, og hvor søkemotoren omfatter databehandlingsenheter som danner sett av noder forbundet i et nettverk. Et første nodesett omfatter sendenoder Na, et annet sett av noder omfatter søkenoder Np, et tredje sett av noder omfatter indekseringsnoder NY. Søkenodene Np er gruppert i søyler som via nettverk er forbundet i parallell mellom sendenodene Na og en indekseringsnode Nr Sendenodene Na er innrettet til å prosessere søkespørsmål og søkesvar, søkenodene Np er innrettet til å romme søkeprogramvare, og indekseringsnodene er innrettet til å generere indekser / for søkeprogramvaren. Valgfritt kan innsamlingsnoder Ng være anordnet i et fjerde nodesett og innrettet til å prosessere søkespørsmål slik at sendenodene kan frigjøres fra denne oppgave. Den todimensjonale skalering finner sted henholdsvis med en skalering av datavolum og skalering av søkemotorytelsen med en respektiv tilpasning av arkitekturen.

Det skjematiske opplegg av denne skalerbare søkemotorarkitektur er vist på fig. 2 som illustrerer prinsippet av todimensjonal skalering. En viktig fordel ved denne arkitekturen er at spørsmålsresponstiden hovedsakelig blir uavhengig av katalogstørrelse, da hvert søkespørsmål eksekveres i parallell på alle søkenoder Np. Videre er arkitekturen iboende feiltolerant slik at feil i de individuelle noder ikke vil resultere i et systemsammenbrudd, bare en temporær reduksjon av ytelsen.

Selv om arkitekturen vist på fig. 2 skaffer en flernivås data- og funksjonsparallellisme slik at store datavolum kan søkes effektivt og meget hurtig av et stort antall brukere samtidig, er den beheftet med visse ulemper og derfor langt fra optimal. Det skyldes det faktum at rad- og søylearkitekturen er basert på mekanisk og rigid partisjonsskjema som ikke tar hensyn til modaliteter i stikkordfordelingen og brukeradferd, så som uttrykt ved frekvensfordelinger av søketermer eller stikkord, og aksessmønstre.

Videre er det fra US patent nr. 7293016 Bl (Shakib & al., overdratt til Microsoft Corporation) kjent å anordne indekserte dokumenter i en indeks i henhold til en statisk rangering og partisjonert i henhold til denne rangeringen. Indekspartisjonen avsøkes progressivt fra og med en partisjon som inneholder disse dokumenter med høyeste statisk rang for å lokalisere dokumenter som inneholder et søkeord, og en skåre beregnes på basis av et foreliggende sett av dokumenter så langt funnet i søket og på basis av området for statiske rangeringer i neste partisjon som skal avsøkes. Den neste partisjon avsøkes for å lokalisere dokumenter som inneholder et søkeord når den beregnede skåre ligger over en målskåre. Et søk kan stoppes når det ikke vil finnes flere relevante resultater i den neste partisjon.

US publisert patentsøknad nr. 2008/033943 Al (Richards & al., overdratt til BEA Systems, Inc.) angår et desentralisert søkesystem med en sentral kø av dokumentbaserte dataposter, hvor en gruppe noder tilordnes forskjellige partisjoner, indekser for en gruppe dokumenter lagres i hver partisjon, og nodene i de samme partisjon prosesserer uavhengig dokumentbaserte dataposter fra den sentrale kø for å danne indeksene.

Foreliggende kjent teknikk skaffer ikke en konstruksjonsstruktur basert på generelle oppfatninger av fordelingsegenskapene til stikkord og søkespørsmål og oppnår således ikke fleksibiliteten til en utførelse som gjør det, med resulterende ytelsesforbedringer og reduksjon i ressurskravene.

Spesielt har veksten i indeksene vært bekymringsfull, og en rekke spesifikke metoder som elegant håndterer direktekoblet indekskonstruksjon er blitt utviklet [BCL06]. Disse teknikker er ortogonale til strukturen som fremkommer ved å benytte fremgangsmåten i henhold til den foreliggende oppfinnelse, slik det vil fremgå av en detaljert beskrivelse av denne.

Den foreliggende oppfinnelse tar ikke hensyn til spesifikke rangeringsalgoritmer, da det er antatt at brukeren alltid ønsker alle svar på søkespørsmålet. Imidlertid kan disse utvides på en likefrem måte til noen av de nylig utviklet rangeringsalgoritmer [RPB06, AM06, LLQ<+>07] og algoritmer for nye søkespørsmålsmodeller [CPD06, LT1T07, ZS07, DEFS06, TKT06, JRMG06, YJ06, KCMK06]. Algoritmer for å finne det best tilsvarende svar på søkespørsmålet når tilsvarsfunksjoner kombineres, har også vært i fokus for mye av forskningen [PZSD96, Fag99, MYL02]. Disse metodene er imidlertid ortogonale for en indeksfordelingsstruktur som realisert ved fremgangsmåten ved den foreliggende oppfinnelse, og de kan også lett innbefattes.

Teknikkene benyttet av den foreliggende oppfinnelse for prosessering av søkespørsmål med partisjonerte posteringslister er basert på grunnleggende ideer hentet fra parallelle databasesystemer [DGG<+>86]; imidlertid ble parallelle databasesystemer utviklet for databaseforvaltningssystemer som lager strukturerte data, mens fokus for den foreliggende oppfinnelse er bedrifts- og Internettsøking, hvor søkespørsmålet eksekveres over samlinger av ofte ustrukturerte eller semistrukturerte dokumenter.

Det foreligger også kjent teknikk vedrørende tekstspørsmålsprosessering i likemannssystemer, hvor målet er å koordinere løst koblede verter med vekt på å finne søkeresultater uten å kringkaste et søkespørsmål til alle verter i nettverket [RV03, LLH<+>03, ODODg02, SMwW<+>03,CAN02, KRo02, SL02, TXM03, TXD03, BJR03, TD04]. Hovedantakelsen i disse kjente publikasjoner angår graden av kobling mellom vertene og er forskjellig fra det initiale grunnlag for den foreliggende oppfinnelse som antar at alle verter er tett koblet og under styring av en enkelt størrelse, f.eks. i en klynge i et bedriftsdatasenter som er den dominerende arkitektur i dag. Den begrepsmessige struktur på hvilken den foreliggende oppfinnelse er bygget, avbildes direkte på denne arkitekturen ved å anta en tett koblet mengde av verter.

I lys av manglene og ulempene ved den ovennevnte kjente teknikk, er det en hovedhensikt med den foreliggende oppfinnelse å skaffe en fremgangsmåte som i vesentlig grad forbedrer ytelsen til en søkemotor.

En annen hensikt med den foreliggende oppfinnelse er å konfigurere indeksen til en søkemotor og spesielt en bedriftssøkemotor på det grunnlag å innse at stikkord og dokumenter vil være forskjellige med hensyn til iboende så vel som ytre egenskaper, f.eks. så som gitt av modaliteter i søke- og aksessmønstre.

Endelig er det en hensikt med den foreliggende oppfinnelse å optimere en indekskonfigurasjon med hensyn til iboende trekk ved søkesystemet selv så vel som dets driftsmiljø.

De ovennevnte hensikter så vel som ytterligere trekk og fordeler realiseres i henhold til den foreliggende oppfinnelse med en fremgangsmåte som er kjennetegnet ved å konfigurere søkemotorens indeks på basis av én eller flere dokumentegenskaper og minst én blant et feiltoleransenivå, en ønsket søkeytelse, dokument-metaegenskaper og en optimal ressursutnyttelse; å partisjonere indeksen, å reprodusere indeksen, å fordele den således partisjonerte og reproduserte indeks over gruppen av søkenoder, slik at indekspartisjonene av og replikkene av disse tilordnes nevnte én eller flere tjenere hvorpå gruppen av søkenoder er plassert, og å prosessere søkespørsmål på basis av den fordelte indeks.

Ytterligere trekk og fordeler ved den foreliggende oppfinnelse vil fremgå av de vedføyde, uselvstendige krav.

Den foreliggende oppfinnelse vil forstås bedre med henvisning til den etterfølgende detaljerte drøftelse av den generelle bakgrunn og aktuelle utførelser lest i samband med den vedføyde tegning, på hvilken fig. 1 viser et forenklet blokkdiagram av en søkemotor som kjent i teknikken og drøftet i det ovenstående;

fig. 2 et diagram og en skalerbar søkemotorarkitektur som benyttet i den kjente søketjeneste AllTheWeb og drøftet i det ovenstående,

fig. 3 begrepet avbildningsfunksjon,

fig. 4 begrepet vertstilordning,

fig. 5 begrepet avbildningsfunksjoner for rader og søyler, og fig. 6 begrepet klassifikasjon av stikkord.

For å beskrive den foreliggende oppfinnelse i sin helhet skal nå noen antakelser og innledende betraktninger drøftes. Deretter vil den nye struktur for indeksfordeling muliggjort ved fremgangsmåten i henhold til den foreliggende oppfinnelse beskrives.

For den foreliggende oppfinnelse introduseres en forenklet modell av en søkemotor. Notasjonen som benyttes er oppsummert i tabell 1.

Tabell 1: Notasjon benyttet i denne patentsøknad

Det has en mengde av stikkord K = { kj, ..., k„} og en mengde av dokumenter D = { di, ..., dm}. Hvert dokument d er en liste av stikkord og identifiseres av en entydig identifikator kalt en URL. En forekomst er en tuppel ( k, u) som angir at dokumentet forbundet med URL u inneholder stikkordet k. En dokumentpost er en tuppel ( u, dato) som angir at dokumentet forbundet med URL u ble frembrakt på en gitt dato.

I praksis inneholder en forekomst andre data, for eksempel posisjonen av stikkordet i dokumentet eller data som er anvendelige til å bestemme rangeringen av dokumentet som fås på grunnlag av et søkespørsmål. I tillegg har et dokument også andre forbundne metadata ved siden av dokumentposten, f.eks. en aksesskontrolliste. Ingen av disse forhold er viktige for trekk ved indeksen som er gjenstand for den følgende drøftelse.

Indeksen til en søkemotor består av mengder av forekomster og en mengde av dokumentposter. Det er en mengde av forekomster for hvert stikkord k, heretter betegnet som posteringsmengden for stikkordet k. Posteringsmengden for stikkordet k inneholder alle forekomster av stikkordet k, og den inneholder bare forekomster av stikkordet k. For å være konsistent med kjent teknikk antas posteringsmengder å være ordnet i en fast orden (for eksempel leksikografisk ved URL), og den ordnede posteringsmengden av et stikkord x-vil bli betegnet som posteringslisten PL(k) av stikkordet k\ ' den følgende fremstilling. Mengden av dokumentposter inneholder bare en dokumentpost for hvert dokument, og den inneholder bare dokumenter.

Nå skal søkespørsmål og spørsmålsprosessering drøftes i noe detalj. Brukere utsteder søkespørsmål, og et søkespørsmål q består av en mengde av stikkord q = { k})..., ki} c K. Den foreliggende oppfinnelse antar en modell for et søkespørsmål i hvilken bruker vil foretrekke å finne ethvert dokument som inneholder alle stikkord i søkespørsmålet. Det kan antas at ankomsttiden for hvert søkespørsmål q følger en eksponensiell fordeling og således kan karakteriseres av en enkelt parameter Xq, mellomankomstraten for søkespørsmålet q. Bemerk at denne probabilistiske modell for søkespørsmål impliserer at søkespørsmålene er uavhengige. En spørsmålsbelastning co er en funksjon som forbinder hvert søkespørsmål q e 2 med en ankomstrate X-ojfø). Fra en spørsmålsbelastning kan ankomstraten \ m( K) beregnes for hvert stikkord Arved å summere over alle søkespørsmål som inneholder k, formelt

Den følgende forenklede måte for logisk å prosessere et søkespørsmål q =

{/Ci,..., Ki} skal antas. For hvert stikkord k, - gjenfinnes dets posteringsliste PL(K-j) for / e {1,...,^}, og deres snitt i URL-feltene beregnes. Formelt beregner følgende rasjonelle algebraiske uttrykk spørsmålsresultater QueryResultfø) for hvert søkespørsmål q = {*•/,..., Ki) :

QueryResultfa) = 7IurlPL(ki) fl...fl 7IurlPL(k/)

Dét finnes mer sofistikerte måter for å definere QueryResultfø); for eksempel kan brukeren ønske å se bare undermengde av QueryResultfø), og kan også ønske å se denne undermengde i rangert orden.

Fysisk utførelse

Den foreliggende oppfinnelse antar at en klynge arbeidsstasjoner modelleres som en mengde av verter H= { hh0} [ACPtNt95]. Videre antas hver vert h å ha et enkelt plateminne med en fast mengde lagringsplass på DiskSize enheter. Bemerk at for å underlette fremstillingen er oversettelsen av den abstrakte enhet for lagring til en konkret enhet som bytes utelatt i denne modellen. Hver forekomst antas å ha en fast størrelse på 1 enhet. For et stikkord k og dets posteringsliste PL(k) blir størrelsen av posteringslisten |PL(k)|, definert som tallet på forekomster i PL(k).

Hver vert h er antatt å være i stand til å levere forbundet total ytelse som tillater den å gjenfinne buc(/z) enheter av lagring innenfor latencyBound millisekunder; dette tallet er en aggregert enhet som innbefatter CPU-hastighet, mengden av hovedminne som står til rådighet og latensen og overføringsraten fra vertens plateminne. Videre er i det følgende alle verter antatt å ha identisk ytelse, og således kan avhengigheten buc(/z) eller h utelates og henvisning bare gjøres til bue som antallet enheter som enhver vert kan gjenfinne innenfor latencyBound millisekunder.

En struktur for indeksfordeling skal nå drøftes. Spesifikt innbefatter strukturen eller arkitekturen som realisert ved fremgangsmåten i henhold til den foreliggende oppfinnelse tre aspekter, nemlig partisjonering, reproduksjon (replikasjon) og vertstilordning, slik det er angitt nedenfor.

Partisjonering

For hvert stikkord blir dens posteringsliste partisjonert i én eller flere komponenter. Denne partisjonering av posteringslister i komponenter utføres for å være i stand til å foredele posteringslisten over flere verter, slik at alle komponenter kan gjenfinnes i parallell.

Reproduksjon ( replikasjon)

For hvert stikkord blir hver av dets komponenter reprodusert et visst antall ganger i flere komponentreplikker for hver komponent. Komponentreplikker dannes av flere grunner. Den første grunn for reproduksjonen er feiltoleranse; i tilfelle en vert som lagrer en komponent svikter, kan komponenten leses fra en annen vert. Den annen grunn til reproduksjonen er forbedret ytelse fordi søkespørsmål kan gjenfinne en komponent fra hvilken som helst av vertene på hvilke komponenten er reprodusert, og således kan lasten balanseres.

Vertstilordning

Etter partisjonering og reproduksjon blir hver komponentreplikk av en posteringsliste tilordnet en vert, men ved tilordningen underlagt den restriksjon at to komponentreplikker av samme komponent og samme partisjon ikke skal tilordnes samme vert. Vertstilordningen muliggjør at plasseringen av komponentene optimeres globalt over stikkordene. Komponenter av stikkord som vanlig forekommer sammen i spørsmål, kunne for eksempel plasseres sammen for å redusere kostnaden ved spørsmålsprosessering.

Nå skal de tilsvarende tre deler av indeksfordelingens struktur i henhold til fremgangsmåten ved den foreliggende oppfinnelse innføres.

1. Partisjonering av posteringslistene i komponenter.

2. Reproduksjon av komponentene.

3. Avbildning av komponentene til verter.

For den første del velges en funksjon numPartitions(-) som benytter et stikkord k som inndata og returnerer antallet komponenter som posteringslisten PL(k) er partisjonert i; de resulterende komponenter er C01(k-),C02(x-),..., COnum<p>artmons()C)(>). I tillegg velges en funksjon occLoc(-) som benytter en forekomst som inndata og gir ut antall komponenter i hvilke denne forekomsten befinner seg. Hvis således occLoc((ac, w)) = U så has { k, u) € C0i(K"). Bemerk at hvis ( k u) e PL(k), så gjelder 1 < occLoc((ac w)) < numPartitions(Ac).

For den annen del velges en funksjon numReplicas(-) som benytter et stikkord k som inndata og returnerer antallet komponentreplikker av partisjonene til posteringslisten for k. Den opprinnelige komponenten er innbefattet i antallet komponentreplikker. For et stikkord k foreligger det således numReplicas(x) • numPartitions(jr) komponentreplikker. Hvis de riktige numPartitions(x)-komponenter kombineres, da vil de sammen omfatte PL(k-); og for enhver komponent CO^k) kan det finnes numReplicas(jt) identiske komponentreplikker. Hvis stikkordet k i en arbeidsbelastning co har en ankomstrate ÅJ^ k), og last jevnt balanseres mellom

numReplicas(K-)-komponentreplikker, vil spesielt ankomstraten for dette stikkord for hver av komponentreplikkene være

For den tredje del, velges en funksjon hostAssign ( k, i, j) som tar som inndata et stikkord k, et replikktall i og komponenttall j og returnerer verten som lagrer komponentreplikk / av komponent j av posteringslisten PL(k). Bemerk at to identiske komponentreplikker (det vil si replikker av hverandre) må avbildes til forskjellige verter. Formelt må hostAssign ( K, i\, j) hostAssign ( K> h, j) holde for je {l,...numPartitions(/c)} og i\,

ii e {l,...numPartitions(/r)} med iyt i2.

Figurene 3 og 4 viser en eksemplarisk forekomst av strukturen i henhold til den foreliggende oppfinnelse for et stikkord k med en posteringsliste med åtte forekomster: A, B, C, D, E, F, G og H. I eksempelet has numPartitions(K) = 4, (dvs. posteringslisten for a:blir partisjonert i fire komponenter) og en numReplicas(x-) = 3 (dvs. det er tre komponentreplikker). Fem verter h\, h2, h3, h4, og h5 er gitt. Funksjonen hostAssign(x, 1, 2) = h\, hostAssign(/c, 2, 2) = h2, hostAssign(x, 3, 1) = ^5.

En instansiering av de tre funksjoner numPartitions(-) numReplicas(-) og hostAssign(x, i, j) skal kalles en indekskonfigurasjon for en søkemotor.

Gitt strukturen som er vist ovenfor, kan den fysiske modell for å prosessere et søkespørsmål q nå innføres. Prosessering av et søkespørsmål q involverer tre trinn. 1. For hvert stikkord k e q identifiseres en mengde av verter slik at hvis unionen av komponentreplikkene er lagret på vertene som omfatter PL(k) . numRepIicas(/r) > 1, da er det mer enn en slik mengde, og det kan velges mellom forskjellige mengder basert på andre karakteristikker, f.eks. lasten på en vert. 2. For hvert stikkord k e q må den valgte komponentreplikk gjenfinnes for alle valgte verter. 3. Det er nødvendig å beregne Query Resultfø), som krever at det dannes snitt mellom de forskjellige posteringslistene.

Nå skal disse tre trinn behandles etter tur.

I det første trinn bemerkes at funksjonen hostAssign(/c, i, j) for hvert stikkord k koder mengden av verter hvor alle komponentreplikker til posteringslisten for k er lagret.

I det annet trinn gjenfinner hver vert involvert i prosesseringen av søkespørsmålet q (som valgt i det første trinn) alle dets lokale komponentreplikker for alle stikkord involvert i søkespørsmålet.

I det tredje trinn vil hver vert først danne snitt med den lokale komponentreplikk av alle stikkord. Deretter prosesseres resultatene av de lokale snitt ytterligere for å fullføre beregning av Query Resultfø).

Nå kan problemet med indekskonstruksjonen defineres som følger: En mengde av verter som har forbundet lagringsrom DiskSize og ytelse bue er gitt. Også gitt er en mengde av stikkord med posteringslister PL(x-i),...PL(xrOT) som har størrelser I PL(k-() PL(xrm) |, så vel som en spørsmålsbelastning co.

For indekskonstruksjonsproblemet må det nå finnes funksjoner numPartitions(-), numReplicas(-), og hostAssign slik at den forventede latens for å besvare et søkespørsmål q ligger under latencyBound, hvor forventningen er over mengden av alle mulige søkespørsmålssekvenser.

I det følgende skal en drøftelse av noen utførelser gis ved hjelp av spesifikke og eksemplariske instanseringer av disse.

1. AllTheWeb Rader og Søyler

AllTheWeb-arkitekturen Rader og Søyler (som tributt til søkesystemet AllTheWeb som beskrevet i den ovenstående innledning) er en triviell instansiering av strukturen, jf. fig. 5 som gjengir avbildningsfunksjonene for vertstilordning. I denne arkitekturen er det en matrise av verter bestående av r rader og c søyler. Matrisen kan visualiseres som følger:

Ved å benytte en spredefunksjon på URLer som er uavhengige av stikkordet, blir posteringene av ethvert stikkord omtrent tilnærmet jevnt partisjonert til c komponenter. Hver komponent blir deretter reprodusert innenfor søylen; en komponentreplikk for hver rad, noe som resulterer i r komponentreplikker. For å rekonstruere posteringslisten til et stikkord, må en vert fra hver søyle aksesseres, men det er ikke nødvendig å velge alle disse verter fra den samme rad, og denne fleksibiliteten forenkler spørsmålslastbalansering mellom verter og forbedrer feiltoleranse.

For å danne forbindelsen til notasjonen for strukturen som realisert ved fremgangsmåten i henhold til den foreliggende oppfinnelse, må de tre ovennevnte funksjoner instansieres. På grunn av rad- og søyleskjemaet has det at for alle stikkord k e K, at numPartitions(v) = c, og numRepIicas(Ar) = r holder, og for alle URLer u og kx, k2 e K må følgende holde:

occLoc((k"i, «)) = occLoc((k"2, u)),

dvs. for alle URL u, er funksjonen occLoc((/c, u)) uavhengig av stikkordet k. Funksjonen hostAssign er også meget enkel. La hostAssign(*:, i,j) = (i,j), hvor i er raden til verten, ogy angir søylen til verten i r x c -matrisen. Bemerk at hvis antallet søyler c velges passende, så vil alle komponentreplikker av ethvert enkelt stikkord k leses i parallell innenfor latencyBound. Det minste antall c er følgende:

Når søkespørsmålsprosesseringen utføres i AllTheWebs rad- og søylearkitektur som vist på fig. 2, behøver bare en vert i hver søyle å involveres, selv for søkespørsmål med flere stikkord, da funksjonen occLoc((k; u)) er uavhengig av k.

Imidlertid har AllTheWebs Rader og Søyler en rekke ulemper. For det første er antallet verter som aksesseres for et stikkord x: uavhengig av lengden til h! s posteringsliste; c verter må alltid aksesseres selv for stikkord med meget korte posteringslister. For det annet tar ikke AllTheWebs Rader og Søyler populariteten til et søkeord i spørsmålslasten i betraktning; hver komponent reproduserer seg r ganger selv om det forbundne stikkord aksesseres forholdsvis sjeldent. For det tredje er forandringene i den fysiske oppstilling for AllTheWebs Rader og Søyler begrenset til tilføyelse av verter i multipler av c og r på en gang, noe som resulterer i en ytterligere rad eller en ytterligere søyle i arkitekturen.

Tilføyelse av en ny (c vert-) rad er forholdsvis likefrem; tilføyelse av en ny (c vert-) søyle er imidlertid ikke-triviell. For å belyse dette poeng, kan det betraktes en forekomst av AllTheWeb Rader og Søyler med r rader og c søyler og som benytter en forbundet funksjon occLocc(-) med en verdimengde {1,c}. Når det tilføyes en annen rad, må en ny funksjon oecLoc'() med en verdimengde {1, c+1} velges og generelt has:

occLoc((at, u)) * occLoc' (( k, u)),

slik at alle posteringslister behøver å repartisjoneres i henhold til occLoc'( ), noe som i utgangspunktet resulterer i en ombygging av hele indeksen.

2. Helt adaptive Rader and Søyler ( Fully Adaptive Rows and Columns)

Nå skal det beskrives en løsning i henhold til den foreliggende oppfinnelse som tar hensyn til både forskjellen i størrelsen av posteringslister og forskjellen i populariteten til stikkordene i søkespørsmålet. Essensen i denne nye løsning er at AllTheWeb Rader og Søyler instansieres forskjellig for hvert stikkord: Hvert stikkord kan ha et forskjellig antall rader og søyler. Med andre ord, ved å benytte fremgangsmåten i henhold til den foreliggende oppfinnelse skaffes det en løsning med helt adaptive rader og søyler.

Betrakt et stikkord k. Start med en instansiering av numPartitions(zc). Da hver vert bare kan gjenfinne bue enheter og tilfredsstille det globale søkespørsmålslatenskrav latencyBound, er PL(*r) partisjonert i komponenter. Således er hver komponent dimensjonert slik at den kan leses innenfor søkespørsmållatenskravet fra en enkelt vert. Bemerk at for et stikkord som har meget korte posteringslister, blir én (eller meget få) komponent(er) dannet, mens for stikkord som har lange posteringslister, dannes mange komponenter.

Spørsmålet er nå hvor mange komponentreplikker det bør dannes for et stikkord k. Det skal huskes at komponentreplikker dannes med tanke på feiltoleranse og for å fordele søkespørsmålsbelastningen over vertene. For å tolerere/utilgjengelige verter, påtvinges numReplicas(xr) >/. For å balansere spørsmålsbelastningen, blir posteringslister for populære stikkord (i spørsmålsbelastningen) replisert hyppigere enn posteringslister for sjeldne stikkord. Så antallet replikker blir omvendt proporsjonalt med ankomstraten for stikkordet i belastningen.

Ved å gjøre numPartitions(/c) og numReplicas(K) forskjellige for hvert stikkord k, fås et antall rader og søyler som er spesifikt for hvert stikkord. Antall søyler angir fortsatt antallet partisjoner og antall rader antallet replikker for hver partisjon. Imidlertid har stikkord med lange posteringslister mange søyler, og stikkord med korte posteringslister har få søyler. Populære stikkord har mange rader, upopulære stikkord har få søyler. Sammenlignet med AllTheWeb Rader and Søyler resulterer Helt Adaptive Rader og Søyler i mindre ubalanse i størrelsen for komponentene for forskjellige stikkord. Det oppnås således at hver komponentreplikk nå normaliseres i den forstand at hver komponentreplikk har omtrent den samme størrelse (opp til en forskjell på bue) og har omtrent samme ankomstrate.

Det gis en rekke forskjellige måter for å tilordne komponentreplikker til verter. Gitt o verter, ville en mulighet være å spre hvert stikkord /crpå tallene fra 1 til o og deretter tilordne komponentene sekvensielt (mod 6) til verter. Begrepsmessig innbaker dette for et stikkord k k! s spesifikke matrise med numPartitions(x) søyler og numRepIicas(/c) rader sekvensielt i o verter. Formelt har tilordningsfunksjonen følgende form. La keywhash(-) være en funksjon framtil {1, o) med den egenskap at

for i e K til {1, ..., o} og x- e Å". Deretter kan undermatrisen for stikkordet k i i/ legges opp rad for rad som følger: hostAssign(*; i, j) = (keywHash(K) + { i - 1) • numPartitions(/c) + ( j - 1)) mod o,

hvor i e {1, ..., numReplicas(x)} ogj e {1, ..., numPartitions(xr)}.

Med dennes instansiering av hostAssign er spørsmålet nå hvor mange komponentreplikker som vil tilordnes til en vert. Med Helt Adaptive Rader og Søyler viser det følgende enkle teorem at det ikke vil være stor ubalanse mellom to verter med hensyn til antallet komponentreplikker.

Teorem 1

La s være det totale antall komponentreplikker dannet over alle stikkord k, formelt

La o være antallet verter og anta at hostAssign er definert som i det foregående avsnitt og anta at s = Q(ø). Da vil det maksimale antall komponentreplikker på hver vert h e //være dvs. det maksimale antall komponentreplikker tilordnet til en vert vil være i størrelsesorden av middeltallet for komponentreplikker tilordnet en vert.

Bevis

Følger fra "grenser for baller i binger" (bounds on balls into bins) [MR95].

For å gjenvinne posteringslisten for et stikkord tc\ ed prosessering av et søkespørsmål velges en vert fra hver av numPartitions(x) "virtuelle søyler" for k! s matrise; således vil antallet forskjellig muligheter for å velge denne mengden være numPartitions(/c)<n>umReplica<s>('<f>).

Prosessering av søkespørsmål med flere stikkord i Helt Adaptive Rader og Søyler er mye mer kostbart enn i AllTheWeb Rader and Søyler. For eksempel kan det betraktes et stikkord q = { kuk2} hvor

numPartitions(x:i) ^ numPartitions(/c2). Da stikkord K\ og k2 partisjoneres forskjellig, må posteringslisten til f.eks. Kj repartisjoneres for å tilsvare partisjonering av k2, noe som er en kostbar operasjon. I tillegg er det ingen garanti for at noen komponenter til K\ og tc2 er samplassert på samme vert.

3. To- Klasse Rader og Søyler ( Two- Class Rows and Columns)

En tredje instansiering er strukturen som realisert ved fremgangsmåten i henhold til den foreliggende oppfinnelse er spesialtilfellet av Helt Adaptive Rader og Søyler som resulterer i en meget enklere (og billigere) søkespørsmålsprosessering. Som i AllTheWeb Rader og Søyler er det antatt at r - c verter er anordnet i den vanlige matrise av verter.

For To-Klasse Rader og Søyler blir stikkordet klassifisert langs to akser. Den første aksen er størrelsen på posteringslisten, hvor stikkord partisjoneres i korte og lange stikkord basert på størrelsen av deres posteringslister. Den annen akse er ankomstraten for stikkordene i spørsmålsbelastningen hvor stikkord partisjoneres i populære og upopulære stikkord basert på deres ankomstrate. Dette resulterer i fire forskjellige klasser og stikkord. • Korte, upopulære (SU) stikkord. Posteringslisten til et SU-stikkord k blir ikke partisjonert og det dannes det minimale antall komponentreplikker for å oppnå den ønskede feiltoleransenivå. For et SU-stikkord usettes således numPartitions(K) = 1, og numReplicas(/c) =f. • Lange, upopulære (LU) stikkord. Posteringslisten til et LU-stikkord k partisjoneres i c komponenter og/komponentreplikker dannes for hver komponent for å oppnå feiltoleranse. Således settes for et LU-stikkord xrnumPartitions(x) = c, og numReplicas(K") =/ • Korte, populære (SP) stikkord. Posteringslisten til et SP-stikkord partisjoneres ikke og r komponentreplikker av k! s posteringslister dannes for å fordele ids ankomstrate over verter. For et SP-stikkord k settes således henholdsvis numPartitions(x) = 1, og numReplicas(Ac) = r. • Lange, populære (LP) stikkord. Posteringslisten til et LP-stikkord partisjoneres i c komponenter og hver komponent reproduseres r ganger. For et LP-stikkord k settes således henholdsvis numPartitions(K) = c, og numReplicas(K) = r.

Instansieringen av de to funksjoner numPartitions(-) og numReplicas(-) fra de foreliggende strukturer for de forskjellige klasser av stikkord er vist i tabell 2. Bemerk at sammenlignet med Helt Adaptive Rader og Søyler er det i To-Klasse Rader og Søyler bare fire forskjellige typer matriser som gjengitt på fig. 6, hvor man har feiltoleransenivået/= 2.

Tabell 2

Klassifikasjon av stikkord: Funksjoner (numPartitions(/c), numReplicas(*:))

La keywHash(-) være som definert og vist i forbindelse med drøftelsen av Helt Adaptive Rader og Søyler som ovenfor. La rowHash(v) være en funksjon fra Å" x {l,.../} to {\,..., r} slik at rowHash(ftr, i\) * rowHash(*:, i2) for i\, i2 e {l,...,r}. Hvordan komponentreplikkene til et stikkord er tilordnet til vertene avhenger av klassen av stikkordet.

• For et SU-stikkord kSu defineres

hostAssign(/f5ty,/,l) = (rowHash( x; z'),(keywHash( mod c) + 1)), forie {l,...j}.

• For et LU-stikkord klu, defineres

hostAssign(x-z,(/,y) = (rowHash(x:,/),y')s

for / e andye {l,...,c}.

• For et SP-stikkord ksp defineres

hostAssign(x"5p,z',l) = (/, (keywHash(x:5(/) mod c) + 1),

for i e { l,..., r}.

• For et LP-stikkord klp defineres

hostAssign(Ki,/»,zV) <=> (i,j),

for / e { l,..., r} and; e {l,...,c}.

I likhet med det foregående avsnitt kan det følgende teorem bevises.

Teorem 2

La s være det totale antall komponentreplikker dannet over alle stikkord k, (uavhengig av klassen av k), formelt

La o være antallet verter og anta at hostAssign er definert som i det

foregående avsnitt. Da vil det maksimale antall komponentreplikker ved hver vert h e //være dvs. det maksimale antall komponentreplikker tilordnet en vert er i størrelsesorden middeltallet for komponentreplikker tilordnet en vert.

Bevis Følger fra "grenser for baller i binger" (bounds on balls into bins) [MR95].

Gitt funksjonen hostAssign(*r,v) for de forskjellige klasser og stikkord er

ikke spørsmålsprosessering i To-Klasse Rader og Søyler svært komplisert, og det er vanligvis mange muligheter for hvordan et søkespørsmål kan prosesseres. Tabell 3 beskriver hvordan et søkespørsmål q = { k\, k2} kan prosesseres med to stikkord; søkespørsmålsprosessering for spørsmål med mer enn to stikkord er analog.

Mengden av mulige mengder av verter som skal velges for

spørsmålsprosessering er likefrem, gitt denne drøftelsen.

Basert på den forekommende struktur som skaffet ved fremgangsmåten i henhold til den foreliggende oppfinnelse og drøftet ovenfor, skal noen få praktiske betraktninger skisseres i det følgende.

For det første tillater bruk av fremgangsmåten i henhold til den foreliggende oppfinnelse en utvidelse av søkesystemets strukturer som gjør at hvert ord kan ha mer enn en enkelt rad- og søyleforekomst. Dette skal beskrives umiddelbart i det følgende.

I de ovennevnte utførelser er det så langt blitt antatt at for hvert stikkord k er det to funksjoner numPartitions(/c) og numReplicas(/r). Imidlertid kan det av hensyn til ytelse et stikkord kpartisjoneres på mer enn en måte og muligvis ha forskjellig antall replikker for de forskjellige partisjoneringer. For eksempel blir i To-Klasse Rader og Søyler posteringslisten for et SP-stikkord ksp reprodusert over en søyle. I tillegg til den foreliggende reproduksjon kan posteringslisten til KSp være partisjonert over en rad fordi KSp ofte forekommer sammen med en annen LP-stikkord klp som er partisjonert over alle rader.

Denne utvidelsen kan karakteriseres ved å forbinde mengder av funksjoner fra den resulterende struktur med hvert stikkord og benytte fremgangsmåten i henhold til den foreliggende oppfinnelse; f. eks. kunne et stikkord xrha to mengder av funksjoner {numPartitionsi(x-), numReplicasi(x)} og {numPartitions2(Kr), numReplicas2(K)}. Antallet mengder kunne være stikkordavhengige. Dette øker i høy grad de valgmulighetene for søkespørsmålsprosessering. Imidlertid skal denne utvidelsen ikke innføres formelt her, da den er begrepsmessig likefrem.

For det annet vil fagfolk innse at bruk av fremgangsmåten i henhold til den foreliggende oppfinnelse for å danne strukturer for virkelige søkesystemer, innbefattet bedriftssøkesystemer, kan tillate forskjellige optimeringer av disse. Slike optimeringer skal ta fremgangsmåten i henhold til den foreliggende oppfinnelse som deres utgangspunkt, men deres reduksjon til praksis antas å ligge utenfor rammen til den foreliggende oppfinnelse, og de skal følgelig ikke ytterligere omtales her.

Fremgangsmåten i henhold til den foreliggende oppfinnelse realiserer en struktur for å fordele indeksen til en søkemotor over flere verter i en databehandlingsklynge. Strukturene som vist skjelner mellom tre ortogonale mekanismer for å fordele en søkeindeks: Indekspartisjonering, indeksreproduksjon og tilordning av replikker til verter. Instansieringer av disse mekanismer gir forskjellige måter for å fordele indeksen til en søkemotor, innbefattet populære fremgangsmåter kjent fra litteraturen og nye metoder som helt og holdent utkonkurrerer kjent teknikk med hensyn til ressursbruk og ytelse, samtidig som det oppnås samme feiltoleransenivå.

Videre anerkjenner fremgangsmåten i henhold til den foreliggende oppfinnelse for første gang at forskjellige stikkord og forskjellige dokumenter i en søkemotor kan ha forskjellige egenskaper (så som lengde eller aksessfrekvens). Strukturen realisert ved å benytte fremgangsmåten i henhold til den foreliggende oppfinnelse danner en konfigurasjon av indeksen på en søkemotor i henhold til disse egenskaper. Strukturen tjener også til å skissere hvordan søkespørsmål behandles for konfigurasjonsrommet som muliggjøres ved realiseringer av strukturen Instansieringer av denne strukturen fører dessuten til eksisterende indekskonfigurasjoner som er kjent i teknikken så vel som til nye indekskonfigurasjoner som ikke vil være mulige med kjent teknikk.

Claims (10)

1. Fremgangsmåte for å forbedre effektiviteten til en søkemotor i aksessering, søking og gjenfinning av informasjon i form av dokumenter lagret i dokument- eller innholdsmagasiner, hvor et indekseringssystem i søkemotoren nedsamler de lagrede dokumenter og genererer en indeks for disse, hvor anvendelsen av en brukers søkespørsmål på indeksen vil returnere til brukeren en resultatmengde med i det minste noen dokumenter som tilsvarer søkespørsmålet, hvor søkemotoren omfatter en gruppe av søkenoder plassert på én eller flere tjenere, og hvor fremgangsmåten er karakter ti sert ved å konfigurere søkemotorens indeks på basis av én eller flere dokumentegenskaper og minst én blant et feiltoleransenivå, en ønsket søkeytelse, dokument-metaegenskaper og en optimal ressursutnyttelse;, å partisjonere indeksen, å reprodusere indeksen, å fordele den således partisjonerte og reproduserte indeks over gruppen av søkenoder, slik at indekspartisjonene av og replikkene av disse tilordnes nevnte én eller flere tjenere hvorpå gruppen av søkenoder er plassert, og å prosessere søkespørsmål på basis av den fordelte indeks.

2. Fremgangsmåte i henhold til krav 1, karakter ti sert ved å fordele indeksen slik at en søkespørsmålslatens befinner seg under en brukerspesifisert latensgrense.

3. Fremgangsmåte i henhold til krav 1, karakterisert ved å prosessere et søkespørsmål med posteringslister som har forskjellige klassifikasjoner.

4. Fremgangsmåte i henhold til krav 3, karakterisert ved å klassifisere posteringslister for søkespørsmål på basis av lengde og popularitet, idet sistnevnte bestemmes av brukeraksessmønsteret.

5. Fremgangsmåte i henhold til krav 4, hvor gruppen av søkenoder omfatter r rader og c søyler, karakterisert ved å benytte et antall partisjoner som er forskjellige fra antall replikker for hvert spørsmålsstikkord, slik at antallet rader og søyler er forskjellige for hvert spørsmålsstikkord, og å fordele indeksen under hensyntagen til enten posteringslistenes størrelsesforskjeller eller posteringslistenes popularitetsforskjeller, eller begge.

6. Fremgangsmåte i henhold til krav 4, hvor gruppen av søkenoder omfatter r rader og c søyler, karakterisert ved å klassifisere et søkespørsmål i to dimensjoner, idet en første dimensjon er en posteringslistestørrelse og en annen dimensjon ankomstraten for hver spørsmålsstikkord, slik at et spørsmålsstikkord partisjoneres i den første dimensjon som henholdsvis kort og langt og i den annen dimensjon som henholdsvis populært og upopulært, og å fordele indeksen under hensyntagen til minst én blant posteringslistenes størrelsesforskjeller, posteringslistenes popularitetsforskjeller og kostnaden for å prosessere et søkespørsmål.

7. Fremgangsmåte i henhold til krav 3, karakterisert ved å dele posteringslistene for søkespørsmål i komponenter for å balansere prosesseringsbelastningen for søkespørsmål mellom søkenodene.

8. Fremgangsmåte i henhold til krav 7, karakterisert ved å reprodusere posteringslistekomponenter slik at det for å øke feiltoleransenivået dannes identiske replikker av disse.

9. Fremgangsmåte i henhold til krav 8, karakterisert ved å tilordne komponentreplikkene til søkenodene for å balansere prosesseringsbelastningen for søkespørsmål mellom disse.

10. Fremgangsmåte i henhold til krav 1, karakterisert ved å fordele indeksen til søkemotoren på en todimensjonal, lineært skalerbar gruppe av søkenoder, hvor skaleringen i seg selv benyttes for å håndtere variasjoner enten i datavolumet eller i søkespørsmålsfrekvensen, eller begge.