NO326041B1 - Fremgangsmate til administrasjon av datalagring i et system for soking og gjenfinning av informasjon - Google Patents

Abstract

I en fremgangsmåte for å administrere datalagring i et søke- og gjenfinningssystem for informasjon, spesielt i et bedriftssøkesystem, hvor systemet implementerer indekserings- og søkeapplikasjoner og omfatter en passende søkemotor, samt datalagringsinnretninger og et datakommunikasjonssystem som sammen realiserer et nettverkslagringssystem forsynt med et applikasjonsgrensesnitt, blir nettverkslagringssystemet delt i distinkte logiske volumer som forbindes med de fysiske datalagringsenheter og konfigureres avhengig av applikasjonen i henholdsvis en lese/skrivemodus og montert på en datamaskin, en lesemodus montert på en eller flere datamaskiner eller en flytende og umontert mode.

Description

Oppfinnelsen angår en fremgangsmåte for å administrere datalagring i et søke- og gjenfinningssystem for informasjon, spesielt i et bedriftssøkesystem, hvor systemet implementerer applikasjoner for indeksering og søking av informasjon fra objekter i innholdsmagasiner, hvor systemet omfatter en søkemotor anordnet på en rekke datamaskiner, hvor applikasjonene er fordelt over datamaskinene og en rekke datalagringsinnretninger i disse, hvor datamaskinene er forbundet i et datakommunikasjonssystem implementert på intranett eller ekstranett, hvor datalagringsinnretningene og et datanettverksystem realiserer et nettverkslagringssystem anordnet med applikasjonsprogrammert grensesnitt (API) og hvor fremgangsmåten omfatter å dele nettverkslagringssystemene i en rekke distinkte, logiske volumer, hvorved de logiske volumer hver kan forbindes med én eller flere fysiske lagringsenheter.

Fremgangsmåte angår således datalagring i forbindelse med bruk av en søkemotor for søking og gjenfinning av informasjon. En søkemotor som kjent i teknikken skal nå kort drøftes med henvisning til fig. la.

En søkemotor 100 i henhold til den foreliggende oppfinnelse vil som kjent i teknikken omfatte forskjellige undersystemer 101-107. Søkemotoren kan aksessere dokument- eller innholdsmagasiner anbrakt i et innholdsdomene eller -rom, hvorfra innholdet enten aktivt kan skyves inn i søkemotoren eller via en datakobling trekkes inn i søkemotoren. Typiske magasiner innbefatter databaser, kilder som står til rådighet 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, bilde og video. De gjenfunne dokumenter leveres til en søkemotor 100 via et innholds-API (Application Programming Interface) 102. Deretter blir dokumentene analysert i et innholdsanalysetrinn 103, også kalt et undersystem for forhåndsprosessering av innhold for å forbehandle innholdet for forbedrede søke- og oppdagelsesoperasjoner. Typisk er utgangen fra dette trinn en XML-representasjon av inngangsdokumentet. Utgangen fra innholdsanalysen benyttes til å mate kjerne søkemotoren 101. Kjerne søkemotoren 101 kan typisk være anbrakt på en tjenerfarm på en desentralisert måte for å gjøre det mulig å prosessere store mengder av dokumenter og høye spørsmålsbelastninger. Kjernesøkemotoren 101 kan akseptere

brukeranmodninger og danne lister av tilsvarende dokumenter. Dokumentordningen blir vanligvis bestemt i henhold til en relevansmodell som måler den sannsynlige viktighet av et gitt dokument relativt til søkespørsmålet. I tillegg kan kjernesøkemotoren 103 frembringe ytterligere metadata for resultatmengden, f.eks. sammendragsinformasjon på dokumentattributter. Kjernesøkemotoren 101 omfatter i seg selv ytterligere undersystemer, nemlig et indekseringsundersystem 101a for nedsamling ("crawling") og indeksering av innholdsdokumenter og et søkeundersystem 101 for å utføre den egentlige søking og gjenfinning. Alternativt kan utgangen fra innholdsanalysetrinnet 101 mates inn i en valgfri varselmotor 104. Varselmotoren 104 vil ha lagret en mengde søkespørsmål og kan bestemme hvilke søkespørsmål som ville akseptert den gitte dokumentinnmating. En søkemotor kan aksesseres fra mange 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, vil levere anmodninger til en søkemotor- eller klient-API 107. Søkemotoren 100 vil typisk besitte et ytterligere undersystem i form av et

søkespørsmålsanalysetrinn 105 for å analysere og forfine søkespørsmålet for å konstruere et avledet søkespørsmål som kan ekstrahere mer meningsfylt informasjon. Endelig kan utgangen fra kjernesøkemotoren 101 ytterligere analyseres 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 foreligger, er den forbundet i parallell med kjernesøkemotoren 101 mellom innholdsanalysetrinnet 103 og søkespørsmåls og resultatanalysetrinnene 105; 106.

Søkemotoren, spesielt benyttet som en bedriftssøkemotor i et bedriftssøkesystem for søking og gjenfinning av informasjon, er som nevnt implementert på en rekke datamaskiner, vanligvis anordnet som en farm av tjenere på en desentralisert måte. En i teknikken velkjent tjenerbasert systemarkitektur som eksempelvis støtter en felles bedriftssøkemotor, er vist på fig. lb. Et Ethernett 111 forbinder tjenere 112 innbyrdes, tjenerne omfatter én eller flere CPUer 113 og én eller flere lokale platestasjoner 114 forbundet med CPUene 113 via lokale koblinger som SCSI (Small Computer System Interface) eller IDE (Integrated Drive Electronics). Plate stasjonene kan være anordnet i en redundant gruppe av uavhengige og billige plate stasjoner (RAID). Den enkleste RAID-konfigurasjonen kombinerer en rekke platestasjoner til en enkelt logisk enhet.

Fig. 2 viser en nyere systemarkitektur for å støtte en bedriftssøkemotor. Denne systemarkitekturen er basert på et nettverkslagringssystem. Tjenerne 201 er sammenkoblet med hjelp av et Ethernet 206. Tjenerne 201 omfatter CPUer 202 som aksesserer data på én eller flere globale lagringssystemer 203 via datakommunikasjonsnettverket 205. Hyppig aksesserte data på et lagringssystem 203 mellomlagres i lokale tjenermellomlagre 204 for å forbedre ytelsen. Lagringssystemet 203 omfatter en rekke lagringsenheter 207 i form av platestasjoner slik at lagringssystemet 203 kan skaleres på volum, ytelse og feiltoleranse uavhengig av søkemotorens prosesseringssystem som innbefatter tjenerne 201. Sentralisering av lagringssystemet forenkler administrasjonen av fysisk samplasserte lagringsinnretninger. Nettverkslagringssystemer gir også høyere pålitelighet og ytelse, da dedisert maskinvare benyttes til å operere dem. Dataforvaltningstjenester som reserveløsninger, hurtig gjenoppretting etter ulykke, replikasjon (reproduksjon), overvåking og fjernforvaltning kan integreres tett innen lagringssystemet.

CPUene 202 krever en konsistent betraktning av lagringstilstanden. Sperring av lokale hurtigminner 204 gir utilfredsstillende ytelse da inn/ut for lagringen blir en flaskehals. Klyngefilsystemer gir hurtigminnekoherens ved å benytte nettverkprotokoll over en forbindelse 208 til å synkronisere hurtigminnene 204. Den ekstra nettverktrafikk for å synkronisere hurtigminnene 204 gir en noe lavere ytelse enn en direkte aksess til lagringsinnretningene selv og gir i tillegg betydelige finanskostnader med hensyn til initialt innkjøp, administrasjon, dokumentasjon osv. Et klyngefilsystem er vanligvis lisensiert for hver CPU 202. Store datavolumer kan typisk forbindes med intensiv prosessering som krever et stort antall CPUer og således høye lisenskostnader for klyngefilsystemet.

Selv om klyngefilsystemer tillater løsning av generelle problemer forbundet med administrasjon av datalagringssystemer, innfører de også uønskede kompleksiteter og kostnader.

Følgelig er det en første hensikt med den foreliggende oppfinnelse å skaffe en fremgangsmåte for å administrere nettverkslagringssystemer slik at ytelse, skalerbarhet, feiltoleranse, sikkerhet og administrasjon av systemet forbedres.

En ytterligere hensikt med den foreliggende oppfinnelse er å frembringe kunnskap om lagringsaksessmønstre for nettverkslagringssystemer slik at lokale lagringsenheter innenfor nettverkslagringssystemet kan konfigureres og styres.

En sluttelig hensikt med den foreliggende oppfinnelse er helt å kunne kvitte seg med klyngefilsystemet og således redusere kostnaden, kompleksiteten og vedlikeholdet av det totale nettverkslagringssystem.

De ovennevnte hensikter så vel som ytterligere trekk og fordeler er realisert med en fremgangsmåte i henhold til oppfinnelsen som er kjennetegnet ved å konfigurere de logiske volumer i én blant henholdsvis en lese/skrivemodus og montert på en datamaskin, en lesemodus og montert på én eller flere datamaskiner, eller en flytende modus som ikke er montert på noen datamaskin.

I en første fordelaktig utførelse av den foreliggende oppfinnelse blir ett eller flere logiske volumer konfigurert av en systemadministrator forut for en applikasjon, slik at applikasjonen monterer logiske volumer enten i lese/skrivemodus på én datamaskin eller i lesemodus på én eller flere datamaskiner.

I en annen fordelaktig utførelse i henhold til den foreliggende oppfinnelse blir ett eller flere logiske volumer konfigurert av applikasjonen selv på dens kjøretidspunkt, idet de nevnte ett eller flere logiske volumer dannes som påkrevet av applikasjonen slik at et logisk volum monteres i lese/skrivemodus på bare én datamaskin eller monteres i lesemodus på én eller flere datamaskiner.

Ytterligere trekk-og fordeler vil også fremgå av de etterfølgende, vedføyde uselvstendige krav.

Den foreliggende oppfinnelse vil forstås bedre fra den etterfølgende drøftelse av de foretrukkede utførelser og lest i samband med den vedføyde tegning, på hvilken

fig. la viser en søkemotor som kjent i teknikken og drøftet ovenfor,

fig. lb en tjenersystemarkitektur som støtter en søkemotor som kjent i teknikken og drøftet ovenfor,

fig. 2 en tjenersystemarkitektur med nettverkslagring som kjent i teknikken,

fig. 3 et indekserings- og søkeskjema som benytter alternerende logiske volumer eller lagringsenheter for en indekseringsapplikasjon,

fig. 4. et flytdiagram av en første utførelse av den foreliggende oppfinnelse,

fig. 5 et indekserings- og søkeskjema i henhold til den første utførelse av den foreliggende oppfinnelse,

fig. 6 et flytdiagram for en annen utførelse av den foreliggende oppfinnelse, og

fig. 7 et indekserings- og søkeskjema i henhold til den annen utførelse av den foreliggende oppfinnelse.

Før fremgangsmåten i henhold til den foreliggende oppfinnelser omtales mer inngående, skal nettverkslagringssystemet drøftes i noe detalj, og særlig med henvisning til enkelte eksemplifiserende utførelser av disse som kjent i teknikken og med spesiell relevans for bedriftssystemer for søking og gjenfinning av informasjon, men ikke nødvendigvis begrenset til slike.

Et eksempel på et nettverkslagringssystem er kalt nettverkforbundet lager (Network-Attached-Storage) (NAS). Tjeneren kommuniserer med et NAS på filnivåprotokoll via standard Ethernettprotokoller som Network File System (NFS) og Common Internet File System (CIFS). Med henvisning til fig. 2 kan nettverkene 205 og 206 være de samme fysiske nettverk. NAS-protokollene tilbyr uklar hurtigminnekoherens for å tilfredsstille gjengse typer av fildeling. For eksempel tilbyr NFS-protokollen lukket-til-åpen hurtigminnekonsistens og støtter tilfellet hvor en klient skriver en fil til lagringssystemet, lukker filen og flere klienter så åpner filen for leseaksess.

Et annet eksempel på et nettverksystem kalles et lagerområdenettverk (SAN) Her er lagringssystemet delt i logiske volumer og hver logiske volum blir individuelt konfigurert uttrykt ved et antall fysiske platestasjoner som kan anordnes i en RAID-konfigurasjon. En tjener monterer et logisk volum og gjør det tilgjengelig i operativsystemet til søkemotoren som hvilken som helst annet lokalt platelager. Kommunikasjonen mellom tjenerne og SAN skjer typisk på blokknivå via en fiberkanalkontroll ( www. fibrechannel. org') eller på en fiberoptisk forbindelse, men Ethernett og settet av protokoller kalt TCP/IP (Transmission Control Protocol/Internet Protocol), deriblant en nettverkprotokollstandard så som iSCSI (Internet Small Computer System Interface) nå blir en sterk utfordrer. Et SAN har vanligvis en lavnivås platelagerreplikasjon, meget store hurtigminner og kraftig administrasj onsverktøy.

En likefrem applikasjon av SAN er å montere ett eller flere logiske volumer med klyngefilsystemet etter hvert som indeksen kontinuerlig oppdateres av indeksereren.

Et søk- og gjenfinningssystem for informasjon må typisk generere en eller flere store indekser som må lagres i et ikke-flyktig lager. Systemet tar periodisk indekssnapshoter av innholdet som befinner seg i systemet ved tidspunktet for snapshotet. Et generelt indeksering- og søkeskjema som belyser dette, er vist på figur 3. Her leverer en søkeapplikasjon 301 søkespørsmålet basert på innholdet til en indeks 302. På et eller annet tidspunkt starter indeksapplikasjonen eller indeksereren 304 å beregne en ny indeks 303 basert på nyere innhold enn det som er blitt tilføyd til systemet 301 etter den siste indeksering. Straks den nye indeks 303 er ferdig, svitsjer systemet sin tilstand som angitt ved 305 og søkeapplikasjonen 301 begynner nå å levere nye søkespørsmål fra den nye indeks 303, men søkespørsmålene som allerede er initiert på den gamle indeksen 302, blir fullført på denne indeks. Når alle søkespørsmål eksekvert på indeks 302 er fullført, frigis indeksen 302 fra søkeapplikasjonen 301 og står til rådighet for indekseringsapplikasjonen eller indeksereren 304 for å lage nye indekser. Nye indeksberegninger initialiseres på konfigurerbare kriterier, innbefattet indekserings-(publiserings)latens, søkespørsmålsytelse og ressursbruk.

I et desentralisert system for søking og gjenfinning av informasjon som omfatter datamaskiner med lokale platelagre, blir indeksene 302 og 303 overført via systemnettverket, f.eks. nettverket 206 som vist på fig. 2, til datamaskinen eller tjeneren som er vert for søkeapplikasjonen 301. Videre kan det være at indeksen må overføres til flere datamaskiner som er verter for redundante søkeapplikasjoner 301 for høy tilgjengelighet eller høyere søkespørsmålsytelse, gitt en lastbalanseringsmekanisme over søkeapplikasjonen 301.

Et nettverkslagringssystem tillater søkeapplikasjonen 301 og indekseringsapplikasjonen 304 å dele det samme lager. Publiseringslatensen, dvs. tiden fra innholdet adderes til systemet og til det blir søkbart, minker som et resultat av å eliminere behovet for å kopiere indeksene 302 og 303 over systemnettverket. De andre fordeler ved nettverkslagringssystemer er fortsatt til stede, f.eks. muligheten av å addere tilleggsplatelagre for å øke innholdsvolumet, for å oppnå høyere tilgjengelighet eller høyere ytelse.

Som ovenfor nevnt, blir SAN benyttet til å montere ett eller flere logiske volumer med et klyngefilsystem. Etter hvert som indeksen kontinuerlig oppdateres ved indeksereren 304, sikrer klyngefilsystemet at søkeapplikasjonen 301 har et koherent syn på indeksene 302 og 303. Blokknivåkommunikasjonen til et SAN gir typisk høyere søkeytelse enn filnivåkommunikasjonen til et NAS, da søking og gjenfinning av informasjon generelt involverer slumpmessige lesninger til lagringssystemet. Tradisjonelt har det vært vesentlig mer administrasjon for hver anmodning til et NAS-system enn det er i et SAN-system.

Slik det bør bemerkes, angår den foreliggende oppfinnelse et nettverkslagringssystem generelt, og innbefatter både SAN- og NAS-lagringssystemer. I det første tilfelle vil den foreliggende oppfinnelse eliminere behovet for et klyngefilsystem ved å kontrollere logiske volumer fra applikasjonen og rettet mot aksessmønstre for lager- og gjenfinningssystemer for informasjon.

I det følgende vil begrepet "dokument" benyttes til å betegne ethvert søkbart objekt og kunne følgelig anses å bety tekstdokument, en databaseinnførsel, tabell, søkespørsmål, eller databasesyn, en XML-struktur, eller et multimediaobjekt. Generelt skal dokumentene anses å befinne seg i dokument- eller innholdsmagasiner som er plassert utenfor selve systemet for søking og gjenfinning av informasjon, men hvorfra de kan ekstraheres av søkemotoren i systemet for gjenfinning og søking av informasjon. Videre er begrepet "datamaskin" (eller bare "maskin") som benyttet i det følgende, ment å dekke de separate tjenere i et desentralisert system for søking og gjenfinning av informasjon. Mer løselig kan begrepet "datamaskin" tas som CPUen til tjeneren uten at det skal redusere klarheten i den etterfølgende drøftelse av utførelser av den foreliggende oppfinnelse.

Fremgangsmåten i henhold til den foreliggende oppfinnelse eksemplifiseres av to spesielt foretrukkede utførelser. Felles for begge utførelser er at applikasjonen er fordelt over flere datamaskiner, slik at problemet med å tilby konsistent betraktning av de delte data i et nettverkslagringssystem uten administrasjon for synkronisering av lavnivåsaksesser må løses. I utførelsen av den foreliggende oppfinnelse synkroniserer applikasjonen dataaksessen på applikasjonsnivå og reduserer således administrasjonen i vesentlig grad. Det er også felles for begge utførelser at den tilgjengelige fysiske lagring innenfor nettverkslagringssystemet er delt i en rekke distinkte logiske volumer.

I en første foretrukket utførelse av fremgangsmåten i henhold til den foreliggende oppfinnelse konfigureres en rekke logiske volumer av systemadministratoren ved å tilordne fysiske platestasjoner til spesifikke logiske volumer slik at egenskaper som ytelse, feiltoleranse, reservekopiering og oppretting oppfyller systemkravene i tilstrekkelig grad. De logiske volumene reserveres for applikasjonen, og applikasjonen får kjennskap til egenskapene til de logiske volumer, enten implisitt ved inspeksjon via grensesnitt til nettverkslagringssystemet eller ved eksplisitt å deklareres av systemadministratoren. Basert på egenskapene til de logiske volumer kan applikasjonen håndtere de logiske volumer på en optimal måte. Applikasjonen som er fordelt på flere datamaskiner i et nettverk, monterer de logiske volumer enten i en lesemodus eller lese/skrivemodus til spesifikke datamaskiner. Applikasjonen sikrer at når et logisk volum er lese/skrivemontert på en datamaskin, er den ikke montert på noen annen datamaskin. Men på den annen side kan det logiske volumet være montert for lesing på én eller flere datamaskiner. Også avhengig av antallet datamaskiner og de pågående applikasjoner kan de logiske volumer dessuten eksistere i umontert eller flytende tilstand på ethvert gitt tidspunkt, dvs. at de ikke er forbundet med noen datamaskin. Applikasjonen benytter et grensesnitt til nettverkslagringssystemet for å montere logiske volumer for lesing eller lesing/skriving på en datamaskin så vel som for å avmontere logiske volumer fra denne. - Den første utførelse i henhold til den foreliggende oppfinnelse kan benyttes både med NAS- og SAN-systemer.

I en annen utførelse av fremgangsmåten i henhold til den foreliggende oppfinnelse blir de logiske volumer konfigurert av applikasjonen selv, vanligvis på applikasjonskjøretidspunktet. Systemadministratoren reserverer et sett av fysiske platelagere i et nettverkslagringssystem for applikasjonen. Applikasjonen har kjennskap til egenskapene til de fysiske platelagre og kan gruppere platelagre i logiske volumer med ønskede egenskaper. Applikasjonen danner logiske volumer etter behov og benytter dem i henhold til samme skjema som i den første utførelse drøftet ovenfor, dvs. et logisk volum er enten montert for lesing og skriving på én enkelt datamaskin eller montert utelukkende for lesing på én eller flere datamaskiner. Som før impliserer dette at avhengig av ressurser på ethvert tidspunkt kan det være logiske volumer som er avmontert eller flytende, dvs. ikke forbundet med noen datamaskin. Applikasjonen kan forandre egenskapene til et logisk volum; f.eks. kan et logisk volum monteres uten datareplikasjon eller reproduksjon for å unngå administrasjon av skrivereplikasjon av temporære data under indeksering. Når den endelige indeks er fullført, tilføyer applikasjonen platestasjoner til logiske volumer, slik at indeksene replikerer og tilbyr høyere ytelse. Også i denne utførelsen benytter applikasjonen et grensesnitt til nettverkslagringssystemet med samme formål som i den første utførelse, men i tillegg blir grensesnittet også benyttet for å montere, rekonfigurere og oppløse logiske volumer. - Denne annen utførelse av fremgangsmåten i henhold til den foreliggende oppfinnelse kan spesielt benyttes med SAN-systemer.

Både den første og den annen utførelse skal drøftes mer detaljert nedenfor med henvisning til flytdiagrammet på fig. 4 og 6, tatt henholdsvis i samband med indekserings- og søkeapplikasjonsskjemaene vist på fig. 5 og 7, men først skal det nå gis en detaljert fremstilling av hvordan dokumenter eller innhold fordelaktig kan håndteres med fremgangsmåten i henhold til den foreliggende oppfinnelse.

På toppnivå og som kjent i teknikken, er innholdet representert som mengde av dokumenter partisjonert i én eller flere innholdspartisjoner. Partisjoneringskriteriene kan innbefatte metadataverdier, herunder en dokumentidentifikator, innholdsoppdateringsmønstre, gjenfinningsmønstre, og dokumenters livssyklusegenskaper. For eksempel kan en e-postarkivløsning partisjonere innholdet etter frembringelsestidspunktet og på månedsbasis slik at reservekopiering og rensing av innholdet på månedlig basis forenkles. Dokumenter kan partisjoneres på aksessfrekvenser for

gjenfinning, slik at hyppigere returnerte dokumenter lagres i et logisk volum med redundante platelagre som støtter høy trafikk (slumpmessig lesing). De

nyest tilføyde eller oppdaterte dokumenter kan være inneholdt i en liten partisjon som tillater lav oppdateringslatensitet for innhold ved å flytte uforandrede dokumenter til større partisjoner etter en viss tid. Dokumenter kan partisjoneres ved aksesstillatelse slik at sikkerhetsmekanismer for hvert logiske volum i det underliggende lagringssystem kan bidra til å garantere en begrenset fordeling av innholdet. Visse dokumenter er oppdragskritiske, mens andre er det ikke. Dokumenter kan partisjoneres på viktighetsnivå slik at oppdragskritiske dokumenter befinner seg i logiske volumer med høy tilgjengelighet og feiltoleranse, innbefattet passende reservekopiløsninger og replikasjonsmekanismer håndtert effektivt med lagringssystemet.

For den foreliggende oppfinnelses formål er det mulig å partisjonere informasjonslagringssystemet i dets komponenter. F.eks. benytter en informasjonspjenfinninpsindeks datakataloger, inverterte indekser og dokumentlagre. Disse er separate komponenter som kan være plassert på separate logiske volumer i ett eller flere lagringsnettverk og individuelt partisjonert på kriteriene gitt ovenfor. Hver slik komponent har bestemte aksessmønstre og livssykluskrav som kan optimeres for samlet ytelse, tilgjengelighet etc. En invertert indeks kan ytterligere være underpartisjonert på indekstermene. For eksempel kan indeksen partisjoneres slik at hyppig aksesserte ord samplasseres på et logisk volum som gir høy leseytelse, mens det innlysende store volum av lite hyppig aksesserte ord plasseres på logiske volumer med andre karakteristikker.

Indekseringen, dvs. oppdateringsskjemaet for indeksen, kan som vist på fig. 3 benyttes i dokumentpartisjon hvor hver indeks forbindes med en logisk partisjon. På ethvert gitt tidspunkt er det bare en skriveapplikasjon (indekserer) eller flere leseapplikasjoner (søk) som aksesserer en bestemt indeks. Indeksereren monterer det ubenyttede logiske volum i operativsystemet for lese/skriveaksess og frembringer den nye indeks, avmonterer deretter volumet og tillater søkeapplikasjonen å montere dette logiske volum for leseaksess. Når en ny indeks (på et annet logisk volum) er klar, blir det gamle logiske volum avmontert og stilt til rådighet for påfølgende indeksering. Det er ikke nødvendig å benytte et klyngefilsystem, da det ikke er noen problemer med hurtigminnekoherens, bare den (eneste) indekserer som skriver til det logiske volum er tilknyttet mens volumet modifiseres med en ny indeks.

Starten av en indekseringsprosess eller applikasjon kan utløses av en rekke faktorer. Den medgåtte tid siden den siste indeks, antallet endrede dokumenter uttrykt ved tilføyde, endrede og slettede dokumenter, og det rene datavolum til det forandrede innhold kan hver eller sammen utløse genereringen av ny indeks innenfor partisjonen. Hvert dokument kan ha en prioritet, enten definert eksplisitt av klienten i systemet, eller utledet eller beregnet innenfor systemet, noe som er innbefattet og vektet i likhet med andre faktorer. Indekseringsapplikasjonen for store partisjoner er ressursintensiv og kan, f.eks. hvor systemet befinner seg på ressurser delt med andre programvaresystemer, være undergitt totale ressursbeskrankninger for systemet, så som CPU-kapasitet, RAM, lagring og nettverkbåndbredde.

Som det skal forstås av det ovenstående, skal det i henhold til den foreliggende oppfinnelse allokeres (minst) to logiske volumpartisjoner. På ethvert tidspunkt er ett logisk volum montert i lesetilstanden til én eller flere datamaskiner for å eksekvere en søkeapplikasjon, mens et annet kunne være i enten søke- eller indekseringsapplikasjonen eller være flytende og ikke montert på noen datamaskin. Dette krever minst en dobling av den effektive lagring i systemet for å håndtere samtidig forekommende topper i alle partisjoner. I en forbedret opplegg blir alle ubrukte (frie; umonterte) logiske volumer fordelt over partisjonene. Hvert logisk volum har visse egenskaper, f.eks. datakapasitet, aksessytelsestilgjengelighet (feiltoleranse) reservemuligheter, etc. En indekserer skaffer et passende logisk volum fra et forråd av frie logiske volumer, danner en indeks og leverer den videre til søkeapplikasjoner, og søkeapplikasjonene tilbakeleverer det logiske volum til forrådet når en ny indeks er effektiv. Dette opplegg reduserer behovet for lagringsplass på bekostning av å ikke å være i stand til å garantere indekseringslatensitet. Indeksereren kan være nødt til å vente til et passende logisk volum blir frigitt. Konflikt om et egnet, fritt, logisk volum er en annen faktor som påvirker planleggingen og triggingen av

indekseringsapplikasj oner.

Det begrepsmessige grunnlag for fremgangsmåten i henhold til den foreliggende oppfinnelse vil lettere bli foreslått med henvisning til fig. 5 som viser virkelig indekserings- og søkeapplikasjonsopplegg eksekvert i den første utførelse av den foreliggende oppfinnelse.

Fig. 5 viser et forråd 501 av frie, logiske volumer Pl5 P2... hvor innholdet er partisjonert i to partisjoner. En partisjon 509i betjenes av en søkeapplikasjon 502 som benytter en indeks på det logiske volum 503, og den annen partisjon 5092 betjenes av en søkeapplikasjon 504 som benytter en indeks på det logiske volum 505. Indekseringsapplikasjonen (indeksereren) 506 er forbundet med partisjonen 509 og er initialt uvirksom. De punkterte linjer viser overgangen når en ny indeks trigges som angitt ved 508. Indeksereren 506 finner et passende, fritt logisk volum 507, generer ny indeks på dette volum og stasjonerer det på en søkeapplikasjon, f.eks. 504. Det logiske volum 505 som inneholder den foregående indeks for søkeapplikasjonen 504, resirkuleres til forrådet 501 av frie eller umonterte logiske volumer.

Det vil være noe administrasjon for hvert logiske volum, slik at den ovenfor drøftede fremgangsmåte gjelder for større partisjoner. Ett eller flere logiske volumer kan reserveres for små partisjoner. Disse logiske volumer kunne konfigureres for optimal lese/skriveaksess, men et klyngefilsystem er fortsatt nødvendig hvis det er flere datamaskiner som aksesserer et volum. Imidlertid vil det være relativt få CPUer forbundet med klyngefilsystemet på de små partisjoner, og lisenskostnaden vil være marginal. Den overveiende andel av CPUene vil håndtere data i den store partisjonen som befinner seg på logiske volumer håndtert av applikasjonen. Bruk av et NAS eller lokale platelagre for små partisjoner vil gi et godt kompromiss mellom ytelse, innkjøpskostnader og vedlikeholdskostnader. I konfigurasjoner hvor de små partisjoner benyttes til å forbedre indekseringslatensitet, med flytting av gamle dokumenter til store partisjoner, vil det være få skalerbarhetsproblemer for de små partisjoner.

Den foreliggende oppfinnelse angår også logiske volumer forbundet med lokale platelagre, f.eks. som benyttet i SAN-systemet. Et nettverkslagringssystem kan konfigureres med flere logiske volumer, hver med en spesifikk konfigurasjon av platelagre, f.eks. et antall platelagre i et spesifikt RAID-arrangement. Applikasjonen monterer på anmodning disse logiske volumer i søke- og gjenfiningssystemet for informasjon. Alternativt er de logiske volumer forhåndsmontert, og applikasjonen forbinder monteringsstedet med de fysiske egenskaper til den underliggende logiske volum. Uansett dirigerer applikasjonen data til og fra passende logiske volumer. Det samme prinsipp gjelder naturligvis også NAS-systemer. Applikasjonen kan styre datastrømmen til og fra valgte NAS-enheter og valgte, logiske volumer innenfor hver NAS-enhet ved å ha kunnskap om avbildningen av logiske volumer innenfor filsystemhierarkiet, innbefattet egenskapene til volumene.

Den første utførelse hvorved konfigurering utføres av systemadministratoren, skal nå drøftes mer detaljert med henvisning til fig. 4 som viser et flytdiagram for å allokere logiske volumer i et system for søking og gjenfinning av informasjon, og den allerede nevnte fig. 5 som viser indekserings- og søkeapplikasjonsopplegget for denne utførelse. I trinn 401 i flytdiagrammet bestemmer systemadministratoren seg for å partisjonere nettverkslagringen i en mengde av logiske volumer L eksklusivt tilordnet et system for lagring og gjenfining av informasjon. De aktive indekser som lest av søkeapplikasjoner 502, 504, er plassert på undermengder av L som er montert for lesing tilpasset til datamaskinene som er verter for søkeapplikasjonene 502, 504. De resterende logiske volumer L er et forråd P av frie, dvs. umonterte, flytende logiske volumer Pls P2, ... Indekseringsapplikasjonen 506 er ikke forbundet til noen logiske volumer. I et trinn 402 må applikasjonen bygge en ny indeks 507 og gjøre den søkbar og fortsette til trinn 403.1 trinn 403 henter indekseringsapplikasjonen fra den ovennevnte forråd P en eller flere frie, logiske volumer P1? P2,... som oppfyller kravene til den nye indeks 507 og anskaffer muligvis også logiske volumer for temporære datastrukturer. Disse logiske volumer blir imidlertid returnert til forrådet når den nye indeks 507 er fullført. I trinn 404 monteres de anskaffede logiske volumer som danner en mengde I på datamaskinen som er vert for indeksapplikasjonen eller indeksereren 506. Indeksereren 506 genererer den nye indeks 507 på anskaffede logiske volumer i mengden I. De anskaffede logiske volumer av mengden I frigis fra samtlige datamaskiner, og temporære volumer fjernes fra forrådet I og returneres til forrådet P. I trinn 405 utfører indeksereren 506 en svitsjeoperasjon 502 og forbinder de logiske volumer i mengden I med en ny indeks 507 til den forbundne søkeapplikasjonen, eksempelvis 504. Søkespørsmål, som allerede er under vurdering/eksekvering, fullføres med den gamle indeks 503 på logiske volumer av en mengde S, mens nye søkespørsmål evalueres mot indeksvolumet 507.

I trinn 406 detekteres at det ikke er noen søkespørsmål som evalueres/eksekveres mot den gamle indeks 503, og indeksereren 506 fortsetter til trinn 407.1 trinn 407 blir de logiske volumer i mengden S frigitt fra samtlige datamaskiner som er verter for søkeapplikasjoner 502, 504 og returneres til forrådet av frie, logiske volumer P. Indeksereren 506 vender deretter tilbake til trinn 402.

Den første utførelse innbefatter en variant hvor ett logisk volum kan benyttes både for indeksering og for søking. En overføring av det logiske volum finner sted internt når kopieringen av en ny indeks eller katalog til en annen fysisk lagringsenhet finner sted. Søkeapplikasjonen avmonterer det tilføyde logiske volum når den nye indeks kopieres til dette og remonterer det logiske volum i en lesemodus, og søkeapplikasjonen fortsetter på nye indekser etter meget kort forsinkelse, avhengig av remonteringsprosessen.

Nå skal den annen utførelse av den foreliggende oppfinnelse drøftes i noen detalj med henvisning til flytdiagrammet på fig. 6 og indekserings- og søkeapplikasjonsskjemaet som vist på fig. 7.1 denne utførelse blir de logiske volumer konfigurert av selve applikasjonen, og denne applikasjonen er fordelt over flere datamaskiner som styrer de fysiske enheter til nettverkslagringssystemer, f.eks. platestasjoner.

I en initial tilstand 601 har en mengde D av platestasjoner 701 i nettverkslagringssystemet blitt allokert til systemet for lagring og gjenfinning av informasjon. Innholdet, på hvilken applikasjonen eksekveres, partisjoneres slik at hver innholdspartisjon blir utelukkende forbundet med en mengde V av logiske volumer (dvs. hvert logiske volum blir utelukkende forbundet med en innholdspartisjon). Hvert logiske volum 703 består av en mengde av fysiske platestasjoner. Mengden DF av de resterende platestasjoner svarer til de frie platestasjoner 702.

I trinn 602 bestemmer applikasjonen at en ny indeks på en innholdspartisjon skal genereres etter hvert som innholdet oppdateres og søkespørsmålstrafikken endrer seg. De mulige indekser som skal genereres, prioriteres etter kostnad og fordel ved å generere den nye indeks, og initieres som angitt ved 706 i fig. 7.

I trinn 603 danner indekseringsapplikasjonen for indeksene et nytt logisk volum 705 av fysiske platestasjoner fra forrådet av frie platestasjoner 702 slik at det logiske volum har den ønskede egenskap, dvs. redundans, ytelse etc.

I trinn 604 blir det logiske volum 705 montert i lese/skrivemodus på datamaskinen hvor indeksereren eller indeksapplikasjonen 704 for den forbundne innholdspartisjon befinner seg. Indeksereren 704 genererer den nye indeks til det nye logiske volum 705 og avmonterer dette volumet som angitt ved 707 på fig. 7.

I trinn 605 blir nye logiske volumer 753 montert i lesemoden til datamaskiner som kjører søkeapplikasjoner 701 på innholdspartisjonen. Disse søkeapplikasjoner starter med å bruke indeksen for nye søkespørsmål. Søkespørsmål som allerede er under evaluering, fullføres på den eksisterende indeks.

I trinn 606 bestemmes det hvorvidt alle søkespørsmål eksekvert på den gamle indeksen basert på den logiske volum 703 nå er fullført, og i så fall. fortsetter prosessen til trinn 607 hvor det gamle logiske volum med den gamle indeks avmonteres fra datamaskiner med søkeapplikasjonen 701 forbundet med innholdspartisjonen. Det angjeldende logiske volum er ikke lenger forbundet med en søkeapplikasjon 701 og fjernes fra nettverkslagringssystemet. De fysiske lagringsenheter, dvs. plate stasjonene forbundet med dette volum, returneres til forrådet DF av frie platestasjoner 702, og utførelsen returnerer til trinn 602.

I begge utførelsene i henhold til den foreliggende oppfinnelse skal indekseringssnapshoter vanligvis initieres som en reaksjon på en forandring i innholdsvolumet eller datastørrelsen, men kunne også bli initiert for å forandre antallet dokumenter, medgått tid siden siste forutgående indekssnapshot så vel som innholdsprioriteter, og tilgjengelig ressurser for lagring, prosessering og nettverkbåndbredde. Spesielt skal indekssnapshoter innenfor SAN trigges direkte av indeksereren, eksempelvis ved kjennskap til forandringer i data eller innhold.

Helt generelt kan de fysiske lagringsenheter likestilles med fysiske platestasjoner, og da kan de logiske volumer være anbrakt på lokale platelagre. I tilfelle av et nettverkforbundet lagringssystem (NAS) vil det logiske volum være plassert på en rekke NAS-enheter, og da skal en applikasjon ha kjennskap til plasseringen av de logiske volumer i filsystemet innenfor NAS-enheten og egenskapene til den førnevnte.

Hvis de logiske volumer er plassert i ett eller flere lagringsområdenettverk, kan de logiske volumer med fordel monteres via f.eks. et lagringsnettverk-API, en vevtjeneste for lagringsnettverk eller opprop for å ta kommandoen over linjeenheter, som innlysende for fagfolk på området. Kopiering eller kopimekanismer kan være anbrakt innenfor SAN-systemet slik at kopiering eller replikasjon av data finner sted direkte fra en applikasjon som initierer en kopimekanisme. Initiering kan bevirkes via grensesnitt som er industristandard eller leverandørspesifisert adaptere. For et slikt formål kunne kopimekanismene som leveres være lavnivås og egne. Fagfolk på området vil lett innse at det mest åpenbare behov for en kopimekanisme vil være å muliggjøre replikasjon av data fra et logisk volum forbundet med en indekseringsapplikasjon og til et logisk volum forbundet med en søkeapplikasjon. I dette tilfelle initierer indeksapplikasjonen selv naturligvis kopiering til den søkeforbundne logiske volum, som imidlertid da under dataoverføringsprosessen kortvarig avmonteres fra søkeapplikasjonen, som remonterer det logiske volum i en lesemodus når f.eks. en nylig dannet indeks eller katalog er overført.

Fremgangsmåten i henhold til den foreliggende oppfinnelse kan fordelaktig utføres på en slik måte at lagringsmuligheten utvides og forbedres i eksisterende lagrings- og informasjonsgjenfinningssystemer. Den kunne også benyttes til å støtte spesielle og nye lagringsmuligheter. Nedenfor skal det gis noen eksempler på mulighetene som tilbys i et system for lagring og gjenfinning ved utførelse av fremgangsmåten i henhold til den foreliggende oppfinnelse.

Eksempel 1 - Arkivering av informasjon for <g>jenfinning og aksess Lovbestemte krav tvinger bedrifter til å arkivere korrespondanse innbefattet all e-posttrafikk over et antall år, samtidig som de også må tillate effektiv aksess til all informasjon i tilfelle det foreligger mistanke om svindel. Systemet kan optimeres for bare å tilføye innhold, muligvis med lite hyppige modifikasjoner av metadata. Innhold slettes etter en viss utløpstid. Innholdet partisjoneres på dannelsestiden. Alt nytt innhold overføres til en partisjon som arbeider i synkronisert lese/skrivemodus, f.eks. på lokale platelagre. Etter hvert som partisjonen fylles, blir et nytt logisk volum allokert, muligvis ved å utvide den fysiske lagring. Den samlede indeks replikeres (reproduseres) på dette volum, og en ny søkeprosess starter og betjener partisjonen, mens partisjonen i økningsmodus ryddes.

Eksempel 2 - Lagring av kontotransaksionshistorie for bankkunder Bankkunder kan tillates å aksessere eldre transaksjoner med tjenester for søking og oppkoblet budsjettering. Verten, dvs. bankene selv, drar fordel fra transaksjonsdata ved å utføre analyser av kundeoppførsel. Innhold bare tilføyes. Feilaktige transaksjoner blir aldri forandret etter hvert som nye transaksjoner tilføyes for å korrigere feilene. De samme prinsipper for å arkivere informasjon i eksempel 1 ovenfor benyttes.

Eksempel 3 - Aksess til og informasjon om analyse fra loggetjenester

Dette er basert på de samme prinsipper som vist i eksempel 1 ovenfor. Lagrings- og gjenfinningssystemer for informasjon settes i stand til å lagre informasjon fra loggetjenester og skaffe brukeraksess til disse og tillate analyse av den relevant informasjon. Dette innbefatter slik informasjon som logging for brukervekselvirkning, datalogging fra fysiske prosesser med bruk av REID (Radio Frequency IDentification)-strømmer og vevarkivapplikasjoner.

Eksempel 4 - Innholdspartisjon på kringkastede multimediastrømmer

Hvis kringkastede multimediastrømmer også er etter sin art bare en tilføyelse, kan de innfanges og forfines. Strømmene blir deretter segmentert, og dokumentinnholdet kan benyttes på de valgte segmenter slik at innholdet kan partisjoneres på et passende kriterium, f.eks. tid.

Claims (17)

1. Fremgangsmåte for å administrere datalagring i et søke- og gjenfiningssystem for informasjon, spesielt i et bedriftssøkesystem, hvor systemet implementerer applikasjoner for indeksering og søking av informasjon fra objekter i innholdsmagasiner, hvor systemet omfatter en søkemotor (100) anordnet på en rekke datamaskiner (201), hvor applikasjonene er fordelt over datamaskinene og en rekke datalagringsinnretninger (207) i disse, hvor datamaskinene (201) er forbundet i et datakommunikasjonssystem (206) implementert på intranett eller ekstranett, hvor datalagringsinnretningene og et datakommunikasjonsnettverk (205) realiserer et nettverkslagringssystem (203) anordnet med applikasjonsprogrammert grensesnitt (API), og hvor fremgangsmåten omfatter å dele nettverkslagringssystemet (207) i en rekke distinkte logiske volumer, hvorved de logiske volumer hver kan forbindes med én eller flere fysiske datalagringsenheter (203), karakterisert ved å konfigurere de logiske volumer som én blant henholdsvis en lese/skrivemodus og montert på en datamaskin, en lesemodus og montert på én eller flere datamaskiner, eller en flytende modus som ikke er montert på noen datamaskin.

2. Fremgangsmåte i henhold til krav 1, karakterisert ved å konfigurere ett eller flere logiske volumer ved en systemadministrator forut for en applikasjon, slik at applikasjonen monterer logiske volumer i enten lese/skrivemodus på bare én datamaskin eller i lesemodus på én eller flere datamaskiner.

3. Fremgangsmåte i henhold til krav 1, karakterisert ved å la ett eller flere logiske volumer konfigureres momentant av applikasjonen selv ved en kjøretid for denne, idet de ett eller flere logiske volumer dannes på forlangende av applikasjonen, slik at et logisk volum monteres i lese/skrivemodus til bare én datamaskin eller monteres i lesemodus til én eller flere datamaskiner.

4. Fremgangsmåte i henhold til hvert av de foregående krav, karakterisert ved å partisjonere lagret informasjon på kriterier basert på dokumentmetadataverdier, innbefattet en dokumentidentifikator, eller informasjonslagringskomponenter, og å tilordne hver partisjon til ett eller flere logiske volumer.

5. Fremgangsmåte i henhold til krav 4, karakterisert ved å konfigurere de nevnte ett eller flere logiske volumer innenfor en partisjon i henhold til én eller flere systemegenskaper for partisjonen, idet nevnte én eller flere systemegenskaper innbefatter randomaksessleseytelse ved replikasjon av lagringsenheter med hensyn til informasjons- og søkeanmodninger og søkespørsmålstrafikk på en partisjon, feiltoleranse, sikkerhet, innholdsoppdateringstrafikk, og vedlikeholdsoperasjoner og deres frekvenser.

6. Fremgangsmåte i henhold til krav 5, hvor en partisjon omfatter minst to logiske volumer, karakterisert ved å anordne indeksen på ett logisk volum, idet det ene logiske volum med indeks er et søkevolum, å behandle partisjonen ved å montere søkevolumet på én eller flere datamaskiner i lesemodus, å la alle andre logiske volumer forbli i den flytende modus og umontert, idet de logiske volumer i den flytende modus er frie volumer, å tilordne et fritt volum for å foreta en indekssnapshot, idet det tilordnede frie volum er et indekseringsvolum, å konfigurere indekseringsvolumet for en indekseringsapplikasjon, å montere indekseringsvolumet i lese/skrivemodus på én datamaskin, idet den ene datamaskin kjøres som en indekseringsdatamaskin, å utføre ved hjelp av indekseringsdatamaskinen indekssnapshoten på indekseringsvolumet, avmontere indeksvolumet fra indekseringsdatamaskinen, og montere indekseringsvolumet i lesemoden på en rekke datamaskiner, idet disse datamaskiner kjøres som søkedatamaskiner hvorved indekseringsvolumet blir et nytt søkevolum, mens det initiale søkevolum avmonteres fra de nevnte én eller flere søkedatamaskiner for å bli et fritt logisk volum etter avslutningen av en søkeapplikasjon.

7. Fremgangsmåte i henhold til krav 6, karakterisert ved å tilordne partisjonen til to logiske volumer, idet ett logisk volum på ethvert tidspunkt er et søkevolum og det andre henholdsvis er et fritt volum, et indekseringsvolum eller et søkevolum.

8. Fremgangsmåte i henhold til krav 6, karakterisert ved å dele et forråd av frie logiske volumer blant to eller flere partisjoner, å prioritere et anmodet indekssnapshot, og å planlegge indekseringen på basis av de prioriterte anmodninger og tilgjengelige ressurser for en indekseringsapplikasjon, innbefattet frie logiske volumer og tilgjengelige indekseringsdatamaskiner.

9. Fremgangsmåte i henhold til krav 5, karakterisert ved å dele et forråd av frie lagringsenheter blant partisjonene, å prioritere anmodede indekseringssnapshoter på partisjonene som respons på konflikt om den frie lagringsenhet, å planlegge en indeksering basert på prioriterte anmodninger og tilgjengelige ressurser for en indekseringsapplikasjon, innbefattet frie lagringsenheter og datamaskiner som kan kjøres som indekseringsdatamaskiner, å tilordne frie lagringsenheter til logiske volumer for indeksering ved å fjerne de førnevnte fra forrådet av disse etter hvert som indekseringsapplikasjonen eksekveres, og å frigi lagringsenhetene til forrådet av frie lagringsenheter etter hvert som søkevolumene avmonteres.

10. Fremgangsmåte i henhold til krav 6 eller krav 9, karakterisert ved å initiere indeksshapshotene som respons på en forandring i innholdsvolumet eller datastørrelse, en forandring i antallet dokumenter som påvirkes, medgått tid siden siste foregående indekssnapshot, innholdsprioriteter og tilgjengelige ressurser for lagring, prosessering og nettverkbåndbredderessurser.

11. Fremgangsmåte i henhold til krav 1, karakterisert ved å anordne de fysiske datalagringsenheter som fysiske platestasjoner.

12. Fremgangsmåte i henhold til krav 1, karakterisert ved å plassere de logiske volumer på lokale platestasjoner.

13. Fremgangsmåte i henhold til krav 1, karakterisert ved å plassere de logiske volumer på en rekke nettverksforbundne lagringsenheter (NAS), slik at applikasjonen har kjennskap til plasseringen av logiske volumer i et filsystem innenfor NAS-enhetene og egenskapene til de logiske volumer.

14. Fremgangsmåte i henhold til krav 1, karakterisert ved å plassere de logiske volumer i ett eller flere lagringsområdenettverk (SAN).

15. Fremgangsmåte i henhold til krav 14, karakterisert ved å montere de logiske volumer via én blant et lagringsnettverk-API, lagringsnettverkvevtjenester, eller opprop for å ta kommando over linjeinnretninger.

16. Fremgangsmåte i henhold til krav 14, karakterisert ved å kopiere data med en applikasjon som initierer lavnivås og egne kopieringsmekanismer.

17. Fremgangsmåte i henhold til krav 16, karakterisert ved å kopiere data fra indekseringsvolumer til søkevolumer.