Dansk Virtuel Fælleskatalog? Tekniske og budgetmæssige overvejelser for fælles søgegrænseflade Index Data Aps d. 11/

Transkript

1 Dansk Virtuel Fælleskatalog? Tekniske og budgetmæssige overvejelser for fælles søgegrænseflade Index Data Aps d. 11/ Forudsætninger Dette dokument søger at levere et grundlag for at overveje omkostningerne forbundet ved at etablere envirtuel fælleskatalog for alle Danske biblioteker, baseret på den eksisterende Z infrastruktur (eller på en videreudvikling af denne hvis omkostninger og præcise natur ikke bliver vurderet i dette dokument). Forbehold Dette dokument repræsenterer ikke et konkret tilbud fra Index Data Aps på løsningen af denne opgave. I bedste fald repræsenterer dokumentet et forsøg på at konkretisere de væsentligste, tekniske udfordringer (og måske muligheder) i en virtuel fælleskatalog. Udviklingen af et sådant system vil under alle omstændigheder fordre dybere analyser og designmæssige overvejelser. Dokumentet skal heller ikke ses som en fuldstændig analyse af de tekniske problemer forbundet med en virtuel fælleskatalog. Det er derimod en gennemgang af de mest vigtige problemstillinger som vi oplever dem baseret på vores erfaringer med konstruktionen af den slags systemer. Antagelser Den præcise systemmæssige belastning af en virtuel fælleskatalog afhænger af en række designmæssige faktorer som ikke i dag er kendt. De konkrete tal der optræder i dette dokument har snarere til formål at belyse problemråder og give nogle overslag og "worst-case" vurderinger. Fælleskatalogen tænkes at opfylde de samme brugermæssige funktioner som i dag mødes af Bibliotek.dk og DANBIB (Netpunkt). Det vigtigste nøgletal for disse systemer er den samlede belastning i antal søgninger, da dette typisk er langt den mest krævende operation i et Z baseret fællessystem. De specifikke antagelser herunder er dels baseret på observationer fra de eksisterende services, dels baseret på skøn leveret fra Biblioteksstyrelsen. For de nævnte systemer er spidsbelastningen pt. omkring 6500 søgninger pr. time eller ca. 1,8 søgninger pr. sekund. Præcis hvor mange distinkte Z39.50-søgninger der kræves (hvor mange servere skal spørges) afhænger af en række designmæssige faktorer. Et bud, som er grebet ud af luften som værende ikke specielt pessimistisk eller optimistisk er 500 servere. Det antages dog, at ikke alle søgninger skal ramme alle 500 servere, men at en væsentlig del på grund af forskellige optimeringsteknikker kan begrænses til en langt mere snæver flok. I den specifikke vurdering af netværksbelastningen vil vi antage at kun omkring halvdelen af søginger rammer alle servere.

2 Fællessystemet Svartider og pålidelighed Lad os sige, at man ønsker at systemet i så mange søgninger som muligt svarer efter hensigten, og indenfor kort tid f.eks. 5 sekunder. Udfordringen i en virtuel katalog er at et samlet, korrekt svar reelt fordrer samlede, korrekte svar fra alle de involverede Z39.50 servere. Antager vi endvidere at hver enkelt Z39.50 server har en 99.9% chance for at svare hurtigt og korrekt, så bliver den samlede sandsynlighed for success ved 500 Z39.50 servere ca. 60% (spørger man derimod kun 50 servere, bliver sandsynligheden for success ca. 95%). Analyser har indikeret, at de mange, oplevede svartidsproblemer med Z39.50 'portaler' skyldes netop dette forhold: Efterhånden som antallet af uafhængige komponenter stiger, falder sandsynligheden for et fuldstændigt svar. Den øverste kurve viser sandsynligheden for et samlet "korrekt svar til tiden" under antagelse af at hver enkelt server svarer korrekt 999 gange ud af Den nederste kurve viser sansynligheden, hvis hver enkelt server svarer korrekt 99 gange ud af 100. X-aksen viser antallet af adspurgte servere. Er muligheden for at benytte en virtuel fælleskatalog herved fraskrevet? Nej, men det illustrerer hvad der må være et grundlæggende princip i et sådant system man kan ikke altid få et

3 fuldstændigt svar, til tiden. Den fysiske fælleskatalog har adgang til alle data, hele tiden, medens den virtuelle fælleskatalog generelt kun har adgang til en del af data, noget af tiden. I konstruktionen af en stor virtuel fælleskatalog til egentlig produktion for almindelige brugere må man angribe dette problem på to fronter. Dels må man sikre at systemet kan håndtere at ikke alle servere svarer til tiden, uden at det opleves som en belastning for brugeren. Dels må man sikre, at de vigtigste servere det kan være dem med de største eller mest populære samlinger svarer hurtigt så ofte som muligt. Netværkskommunikation og båndbredde Den mest krævende operation i Z39.50 er typisk den første søgning og efterfølgende returnering af data. Dette sker typisk i en enkelt operation, en kombineret søgning og præsentation af søgeresultat og de første svar-poster (en såkaldt "piggy-backed" present response). Set snævert i forhold til netværkstrafik er Z39.50 noget nær en optimal infrastruktur. Protokollen er designet til langt langsommere netværk, og alle data er enkodet for at minimere belastningen af netværket (dette står i kontrast til mere moderne, XML-baserede protokoller som, uden yderligere kompression, kan indebære en betydelig forøgelse af netværkstraffikken). Langt den største og måske een af de mest ofte forekommende er altså svaret på en søgning, inklusive et begrænset antal bibliografiske poster. Under almindelige omstændigheder fylder en sådan pakke (med 10 biblioteksposter) ca. 4KB (kilobytes). Til brug for dette overslag vil vi ignorere de øvrige, langt mindre protokolpakker. Forestiller man sig et system der udfører een søgning per sekund svarer det til en netværksbelastning på 4Kbit/sek, eller ca. 32Kbit/sek en yderst beskeden belastning for en typisk fastnetforbindelse. Et serversystem der skal udføre samtidige søgninger imod 500 Z39.50 targets een gang pr. sekund producerer en netværksbelastning på ca. 16Mbit/sek. plus "det løse". Selv hvis vi regner med at kun en vis andel af søgninger er "globale", bliver der altså produceret en del netværkstrafik af den centrale søgekomponent. De enkelte Z39.50-servere oplever derimod kun en langt mere begrænset netværkstrafik. Det er vores umiddelbare vurdering, at den netværks-infrastruktur der i dag findes blandt de danske biblioteker i det store hele er tilstrækkelig til at løfte opgaven. Den centrale søgeflade skal kunne håndtere en netværkstrafik et sted imellem 16 og 32 Mbit/sek. Det skal understreges igen at disse tal skal ses som meget grove antagelser, der snarere skal give et indtryk af projektets omfang end et egentligt grundlag for skaleringen af systemet. Den samlede netværksbelastning afhænger af flere faktorer i designet af systemet og brugergrænsefladen. Hardware/infrastruktur Kravene til hardware er ikke markant anderledes end de vil være for en fysisk fælleskatalog, med den undtagelse at behovene for både diskplads og løbende backup er langt mere beskedne. En fælles søgetjeneste egner sig godt til skalering ved replikering af tjenesten over flere maskiner. Med den almindelige udvikling af system-performance der er set over de senere år er valget af hardware ikke

4 længere kritisk. Generelt set er det formentlig at foretrække at investere i flere, billige og redundante servere end i få meget dyre serversystemer. Software Skal man producere en WWW/Z39.50 gateway der skalerer til flere hundrede samtidige søgninger uden at give køb på svartider kræver det både programmeringsteknikker og værktøjer der er opgaven voksen. Det er vores vurdering at der idag ikke findes højniveau-værktøjer eller programmeringssprog der med sikkerhed kan bære opgaven. Vores tilgang til et sådant projekt ville basere sig på prekompilerede sprog som C eller C++, og på optimeringsteknikker der minder om dem, der bruges ved udviklingen af et egentligt databasesystem. Teknikkerne for håndteringen af selve netværkstrafikken er enkle og velkendte, men effektiv håndtering, sortering og sammenfletning af større mængder databaseposter kræver omhyggeligt softwaredesign, der ligger ud over de mere dagligdags teknikker der kan benyttes i WWW/Z39.50-gateways ved små samlinger af databaser. Antager man at de vigtigste Z39.50-servere bringes til at understøtte online sortering efter et fælles kriterium (dette kriterium skal være harmoniseret med det flettekriterium der tænkes anvendt) er det muligt at levere søgesvar der ikke adskiller sig væsentligt fra det der kendes fra f.eks. bibliotek.dk i dag. Hvis serverne ikke sorterer, kan man reelt ikke levere et sorteret, flettet svar, med mindre antallet af fund for alle servere er beskedent måske omkring Det er ikke realistisk at hente større mængder af poster ned fra serverne og stadig producere korte svartider. Et realistisk alternativ er, at sortere resultatsæt der er meget små (10-12 poster per server). For lidt større sæt (måske per server) kan man advare brugeren om at dette kan tage tid, og evt. først vise ham et usorteret sæt. For endnu større resultater kan man reelt kun vise usorterede resultater, med mindre serveren tilbydder fletning. Antagelserne ovenfor forudsætter en traditionel, HTML-baseret fremvisning af poster lige som f.eks. bibliotek.dk og DEFKAT fungerer i dag. Men allerede i dag er det med brug af "client-side" programmer i Flash eller Java muligt at levere mere sofistikerede hybrider, hvor resultatet på skærmen løbende opdateres efterhånden som flere resultater bliver synlige. Konsekvensen af sådan en fremgangsmåde er yderligere krav til netværksforbindelser og brugerens browser-miljø, men med en projekthorisont på 1-2 år er det bestemt et realistisk alternativ. Fletning af poster i et online system kan formentlig ikke forventes at leve op til de samme, stringente regler som f.eks. ligger til grund for DANBIB-systemet i dag. Antagelsen må være, at en fletning der primært har et søge/lokaliseringsmæssigt sigte kan udføres med mere simple algoritmer svarende til dem der bliver anvendt i DEFKAT's sorteringsfunktion. Antallet af servere der skal spørges for at besvare en given forespørgsel kan reduceres på flere måder. Dels kan populære søgetermer caches, så man ikke behøver spørge de biblioteker som man ved ikke giver fund på en given søgning. Dels kan man, hvis man kender brugerens geografiske placering (eller mere specifikt, hans tilknytning til et givent bibliotek) måske i nogle situationer starte med at søge i biblioteker der er fysisk tæt på brugeren selv, og kun udbrede søgningen såfremt der ikke findes noget fornuftigt tættere på. Se iøvrigt diskutionen af hybride modeller nedenfor.

5 Systemet skal håndtere den situation at ikke alle databaser altid er i stand til at svare til tiden. Som det kan ses ovenfor er det ikke realistisk at forvente at man, ved søgning i 500 servere, også får et korrekt svar indenfor et givent tidsrum. De fleste gateways, heriblandt DEFKAT, venter indtil alle servere har svaret før et resultat præsenteres for brugeren. I et storskala-produktionssystem med mange flere servere kan man f.eks. overveje at kategorisere bibliotekerne, således at systemet f.eks. nok venter et stykke tid på store, vigtige databaser, men ikke nødvendigvis på små eller perifære biblioteker.. Krav til Z39.50-servere Oppetidskrav til serverne er allerede blevet berørt ovenfor. Desuden er det væsentligt, at de enkelte servere er skaleret til at håndtere det større antal søgninger, der vil blive produceret af den fælles søgetjeneste. Som nævnt ovenfor kan dette betyde op til 3500 søgninger per time, afhængigt af detaljerne i den fælles søgetjeneste. Man skal ikke undervurdere konsekvenserne af denne belastning. Til sammenligning er spidsbelastningen på Statsbibliotekets katalogsystem pt. ca. 500 søgninger pr. time, eller ca. en syvendedel. Kan serveren klare noget der nærmer sig en 10-dobling af sin trafik? Dette aspekt af modellen vil blive drøftet af andre, men sikkert er det, at de enkelte Z39.50-servere i en virtuel fælleskatalog må omfattes den samme skalerings- vedligeholdelsesmæssige omhu som webserveren i et større bibliotek. Hybride modeller Ovenfor ses en række overvejelser i forbindelse med en "ren" virtuel fælleskatalog baseret på en central søgegateway og en udvidelse og videreførsel af den Z39.50 serverpark vi har i Danmark i dag. Nedenfor vil vi gennemgå eksempler på hybride løsninger der kombinerer den rene model med supplerende mekanismer der på forskellig vis kan reducere belastingen af bibliotekernes systemer eller forøge anvendeligheden af det centrale system. Kombinationsmodel I DANBIB udgøres en væsentlig del af data af fællesposter og beholdningsoplysninger fra folkebibliotekerne. Disse data er generelt opstået ud fra en fælles, ofte central katalogisering, og de er kendetegnet ved brug af en fælles ID-nummer systematik som voldsomt forenkler fletningen af data. Efter vores vurdering vil det være fornuftigt at vurdere at kombinere en fysisk fælleskatalog for folkebibliotekerne med en virtuel fælleskatalog for de øvrige, mindre homogene samlinger. Resultatet bliver for brugeren det samme som en rent virtuel fælleskatalog, men de tekniske krav til en række, mindre biblioteker bliver væsentlig mindre. En central database til søgning for en del af bibliotekerne udelukker ikke de øvrige fordele ved en virtuel fælleskatalog f.eks. direkte adgang til udlåns/cirkulationsoplysninger via Z39.50/holdings-profilen eller andre mekanismer (f.eks. NCIP). Aktiv caching Et fælles indeks baseret på "indeks høstning" af søgeord eller OAI-harvesting af hele bibliografiske databaser muliggør potentielt en reduktion af presset på lokalsystemerne. Selvom disse teknikker

6 indebærer en central opsamling af data vil vedligeholdelsesomkostningerne dog være mindre end for et egentligt, fysisk fælleskatalog, da opsamlingen foregår fuldautomatisk. Indeks høstning er en forholdsvis uprøvet teknik, som bl.a. Netlab ved Lunds Tekniske Universitet p.t. har under overvejelse. Ideen er i korte træk at lade den centrale server periodisk 'høste' søgeord fra alle eller en del af de involverede Z39.50-servere. Dette kan f.eks. gøres ved hjælp af den skan/browse funktion der allerede i dag leveres af en del Z39.50-servere. Ved at have et sådant cachet indeks til rådighed behøver man kun at sende søgninger til de database som faktisk kan forventes at returnere fund for en given søgning, og især for emnespecifikke søgninger kan man forestille sig en betydelig effektivisering af den centrale søgefunktion helt transparent for brugeren. Høstning af hele kataloger kan være mere diskutabel specielt fordi den, fuldt realiseret, producerer et system der har visse ligheder med det vi kender i dag i DANBIB. Filosofien er her at den centrale service, i stedet for at høste søgeord eller indekser, høster en delmængde af data fra hver enkelt bibliotekspost det kunne f.eks. være et sæt felter baseret på Dublin Core-elementerne. Disse metadata kan så automatisk lægges i en central database der kan benyttes enten til direkte søgning, eller som ved indeks-høstningen, til at afgøre hvilke Z39.50-servere der skal adspørges. Denne fuldautomatiske, centrale "cache-funktion" bør vær betydeligt billigere at administrere end en egentlig, fysisk fælleskatalog da kravene til datakvalitet er lavere. Egentlige opslag efter detaljerede oplysninger og især cirkulations/beholdningsoplysninger sker fortsat direkte i de relevante bibliotekssystemer. Modulære Z39.50 servere Erfaringene med DanZIG-profilen har gennemgående været positive, men de har også vist udfordringerne ved at ensrette bl.a. søgeveje på tværs af organisationer. For nogle biblioteker har der hidtil været administrative vanskeligheder forbundet ved at tune eller at justere Z serverkomponenten. Desuden viser DEFKAT at både svartider og pålidelighed endnu er en udfordring, selv for nogle af de store, ressourcestærke biblioteker. I forbindelse med en videreudvikling af fælles services baseret på Z39.50 ville det være oplagt at tilbyde bibliotekerne et fælles "Z39.50 servermodul" som de kan anbringe foran deres bibliotekssystem. Et sådant modul kan enten bestå af en gratis softwarepakke, eller af en prækonfigureret maskine der blot skal anbringes på netværket. Servermodulet kan herefter dagligt ajourføre en simpel kopi af den lokale bibliografiske database, og stille den til rådighed via Z39.50 og DanZIG-profilen. Fordelen ved denne model er dels at den fjerner ekstrabelastningen fra bibliotekssystemet selv, og at et dedikeret indekserings/z39.50 serversystem ofte kan levere bedre svartider end et integreret bibliotekssystem. Evt. forespørgsler om beholdsningsdata sendes naturligvis direkte videre til det bagved liggende bibliotekssystem. Et sådant Z39.50 servermodul fungerer bedst hvis der findes en standardiseret metode til at udtrække poster fra bibliotekssystemet dette kunne f.eks. være OAI's harvesting-protokol der teknisk og semantisk er langt mindre krævende for systemleverandøren end Z En mekanisme som den her beskrevne kan ses som en mulighed for på meget billig vis at forøge kvaliteten af den Danske Z39.50-serverpark også uden for rammerne af en decideret national fælleskatalog (f.eks. kunne et system som DEFKAT også nyde gavn af det).

7 Omkostninger Uden nærmere analyse er det umuligt at give et endeligt bud på omkostningerne ved et fælles system som det ovenfor beskrevne, men en realistisk vurdering burde indeholde nogle af de følgende poster. Detaljerne i den valgte løsning vil influere på designomkostningerne, men nedenstående overslag giver rum til en vis grad af ambitiøsitet i løsningen. En mere konventionel løsning vil selvsagt være betragtelig billigere i alle henseender, men vil måske føre til uacceptable kompromiser på brugersiden. Omkostninger forbundet ved udviklingen af den centrale løsning, inkl. analyse af relevante hybride modeller (men ikke inklusive deres implementation). Post Beløb Design og analyse Konsulentbistand Løntimer blandt bibliotekerne , ,- Grafisk design ,- Softwareudvikling og tests ,- Hardware (excl. netværks-infrastruktur) ,- Samlet: Årlige omkostninger i forb. med drift o.l. Brugerrettet hotlinefunktion ikke inkluderet. Post Beløb Drift af hardware/softwaresupport ,- Biblioteksfaglig drift (samlet ca. 2 person på fuld tid) ,- Samlet: ,-