TIP: SOLR training in Amsterdam 24 Maart 2009

8 views
Skip to first unread message

Etienne Posthumus

unread,
Mar 11, 2009, 3:05:43 AM3/11/09
to code...@googlegroups.com
Zie http://www.eu.apachecon.com/c/aceu2009/sessions/201

Erik Hatcher 'wrote the book' wat Lucene betreft
http://www.librarything.com/work/440974 en bij de volgende Apachecon
in Amsterdam geeft hij een SOLR bootcamp.
Een aanrader, en de andere courses en de conf is natuurlijk ook niet
te versmaden. Zie de rest van de schedule.

EP

Boheemen, Peter van

unread,
Mar 11, 2009, 7:40:42 AM3/11/09
to code...@googlegroups.com
We gaan er zeker (met een aantal mensen) naar toe vanuit Wageningen.
Er is overigens ook een 2-daags Lucene bootcamp

Peter

Peter van Boheemen

unread,
Mar 11, 2009, 5:59:47 PM3/11/09
to code4bib
Ik vraag me eigenlijk af wie er in Nederland en Vlaanderen al bezig
zijn met SOLR. Ons Library Content Management Systeem maakt nu gebruik
van Oracle Text Retrieval. Dat is in sommige opzichten heel krachtig,
doordat we heel goed gebruik kunnen maken van XPath in de queries,
maar het is onvoldoende vwb de ondersteuning van echte text retrieval
faciliteiten. Daarom willen we over op Lucene.
Ik denk dat die overgang een stuk sneller kan verlopen wanneer we
gebruik maken van SOLR en de informatie in het LCMS aanbieden aan SOLR
en het daar laten indexeren. Het sluit hel erg aa bij onze huidige
zoekfuctionaliteit. we zullen de indexer wel wat eenvoudiger XML moete
aanbieden dan wat we nu hebben:

bv. http://library.wur.nl/WebQuery/titelplus/xml?recordtype=deel&wq_max=3

Dat soort complex xml, wordt uitstekend geïndexeerd door Oracle Text
Retrieval. SOLR kan volgens mij die ingewikkelde structuur niet zonder
meer indexen en vervolgens zinvol doorzoekbaar maken, dus ik denk dat
we het aanvullend moeten inzetten.

Het zou leuk zijn wanneer we SOLR ervaring zouden kunnen uitwisselen
met anderen.

Peter

Patrick Hochstenbach

unread,
Mar 12, 2009, 2:25:22 AM3/12/09
to code...@googlegroups.com
De catalogus frontend in Gent (a.k.a meercat http://lib.ugent.be/) maakt al enkele jaren gebruik van Lucene. Wij willen graag overschakelen naar SOLR. Alle ontwikkeling die wij in Lucene hebben gestoken wordt ook door de SOLR mensen gedaan en veel,veel beter.
In Zweden wordt de ELIN databank (>50 miljoen records) door Lucene geindexeerd..alles op 1 krachtige server. Erg impressionant.

Patrick

2009/3/11 Peter van Boheemen <Peter.va...@wur.nl>

Patrick Hochstenbach

unread,
Mar 12, 2009, 2:27:44 AM3/12/09
to code...@googlegroups.com
Peter , je moet misschien eens kijken naar NetKernel http://www.1060.org/ ik heb hier een jaar of twee geleden wat projectjes mee gedaan. Ze hebben een XPath query op de Lucene laten maken meen ik me ter herinneren.

Patrick

2009/3/12 Patrick Hochstenbach <patrick.ho...@gmail.com>

Etienne Posthumus

unread,
Mar 12, 2009, 4:54:37 AM3/12/09
to code...@googlegroups.com
Peter,

Bij de code4lib conf 2009 was het SOLR overal. Het viel mij op wat een
enorm 'mindshare' het heeft in de information retrieval space. Twee
interesting snippets in div. presentaties was; direct support in SOLR
voor binary file types als PDF, Word files etc. en support voor GEO
datatypes (lengte en breedtegraad etc.) om 'close-to-this' type
searches te kunnen doen.

Een van de klachtes die ik vroeger hoorden over SOLR hier in NL was
performance issues met grote datasets, en dat is ook inmiddels
ontkracht. Bij Serial Solutions hebben zij een SOLR-indexed collection
voor het Summon product van 300 miljoen records en de projectie is dat
het op korte termijn tot tussen 6- en 900 mil. gaan groeien.

Ik heb een paar jaar geleden (huh? zo lang al? wat gaat de tijd snel)
iets soortgelijks aan SOLR gemaakt in Python, met PyLucene, voor een
cultuurhistorisch database en de index op de ICONCLASS classificatie
systeem maar ben van plan om mijn oude code in de prullenbak te
smijten en ook over te stappen op SOLR. De community is vele malen
groter en zeer dynamisch.

Voor de nieuwe versie van de TU Delft Repository ben ik nog steeds
aan't tobben over SOLR vs. Meresco die wij voor de integrated search
platform gebruiken. Maar dat is weer een heel ander discussie.

Wat jouw XML voorbeeld betreft, lijk mij dat je daar zonder al te veel
moeiten XSLTs op kan loslaten om er SOLR updates van te maken voor de
velden die je wil indexeren. Alle communicatie met SOLR is ook maar
XML over HTTP, dus zeer goed te doen.

gr.

EP


2009/3/11 Peter van Boheemen <Peter.va...@wur.nl>:

Boheemen, Peter van

unread,
Mar 12, 2009, 8:11:03 AM3/12/09
to code...@googlegroups.com
Etienne, Patrick,

Bedankt voor jullie respons. Het strekt ons nog meer in de overtuiging SOLR te gaan gebruiken en niet Lucene te incorporeren in onze eigen software.
We denken er zelfs serieus over om de gehele data opslag in SOLR te doen en Oracle geheel te laten vallen. Enige ideeën daarover ? We gaan het in ieder geval stapsgewijs doen, dus eerst maar even alleen om de boel te indexeren.
En deelanme aan de SOLR training is een mooi moment om de ontwikkelaars warm te laten lopen.

Peter

Etienne Posthumus

unread,
Mar 12, 2009, 8:43:56 AM3/12/09
to code...@googlegroups.com
2009/3/12 Boheemen, Peter van <Peter.va...@wur.nl>:

> We denken er zelfs serieus over om de gehele data opslag in SOLR te doen en Oracle geheel te laten vallen. Enige ideeën daarover ? We gaan het in ieder geval stapsgewijs doen, dus eerst maar even alleen om de boel te indexeren.

Als je veel records opslaan en over performance denken dan is het
beter om je spullen niet in SOLR op te slaan, maar alleen te indexeren
met SOLR. Stored fields vreet geheugen, je wil zover mogelijk alleen
indexed fields.

Ik vind <storage> + SOLR + memcache een goeie combo.

Waar <storage> zou kunnen zijn;
filesysteem (files on disk),
VCS (Subversion, git, bazaar),
db (Oracle, MySQL, Postgresql etc.)
XMLdb (Exist of Sleepycat/Oracle of MSSQL etc.)
Repository system (eprint, dspace, Fedora)

En memcache voor convenience.

EP

Boheemen, Peter van

unread,
Mar 12, 2009, 11:18:49 AM3/12/09
to code...@googlegroups.com
>> We denken er zelfs serieus over om de gehele data opslag in SOLR te doen en Oracle geheel te laten vallen.
>>Enige ideeën daarover ? We gaan het in ieder geval stapsgewijs doen, dus eerst maar even alleen om de boel te indexeren.

> Als je veel records opslaan en over performance denken dan is het beter om je spullen niet in SOLR op te slaan, maar alleen te
> indexeren met SOLR. Stored fields vreet geheugen, je wil zover mogelijk alleen indexed fields.
> Ik vind <storage> + SOLR + memcache een goeie combo.

OK, We gaan het vooralsnog oplossen in combinatie met XMl in Oracle, zoals we nu doen. En dan zien we weer verder.


> Waar <storage> zou kunnen zijn;
> filesysteem (files on disk),

Heeft veel voordelen, maar ook gevaren
> VCS (Subversion, git, bazaar),
Hmm, ik geloof dat we voor bibliografische bestanden niet zo'n behoefte aan versioning hebben.


> db (Oracle, MySQL, Postgresql etc.)
> XMLdb (Exist of Sleepycat/Oracle of MSSQL etc.)

Dat doen we dus nu maar dan zonder al te veel relationele balast


> Repository system (eprint, dspace, Fedora)

Hmm, dat is toch weer 'one of the above'. Wij noemen het geheel de repository :)

Peter

Jasper Op de Coul

unread,
Mar 13, 2009, 4:12:22 AM3/13/09
to code...@googlegroups.com
Hoi Allemaal,

Interessante topic, ik zou ook wel wat meer van SOLR willen weten.

Boheemen, Peter van wrote:
>>> We denken er zelfs serieus over om de gehele data opslag in SOLR te doen en Oracle geheel te laten vallen.
>>> Enige ideeën daarover ? We gaan het in ieder geval stapsgewijs doen, dus eerst maar even alleen om de boel te indexeren.
>
>> Als je veel records opslaan en over performance denken dan is het beter om je spullen niet in SOLR op te slaan, maar alleen te
>> indexeren met SOLR. Stored fields vreet geheugen, je wil zover mogelijk alleen indexed fields.
>> Ik vind <storage> + SOLR + memcache een goeie combo.
>
> OK, We gaan het vooralsnog oplossen in combinatie met XMl in Oracle, zoals we nu doen. En dan zien we weer verder.
>
>
>> Waar <storage> zou kunnen zijn;
>> filesysteem (files on disk),
> Heeft veel voordelen, maar ook gevaren
>> VCS (Subversion, git, bazaar),
> Hmm, ik geloof dat we voor bibliografische bestanden niet zo'n behoefte aan versioning hebben.

In de Erasmus repository wordt alles opgeslagen in subversion, en dit is
ontzettend handig.

Je hebt een complete 'audit trail' van al je wijzigingen (tot op 'regel
niveau') en het is onmogelijk dat ooit nog iets per ongeluk verwijdert
wordt (je kunt altijd terug naar alle vorige revisies).
Het geeft ook een veilig gevoel als iets ingechecked is, en je kunt
altijd alle vragen beantwoorden wanneer iets gewijzigd is, en door wie.

Ook kun je de complete repository 'uitchecken' op een lokale computer en
makkelijk 'bulk editing' doen. Je kunt dan daarna handig kijken wat er
gewijzigd is, en alles weer inchecken, ook als in de tussentijd andere
gebruikers zaken gewijzigd hebben.


>> db (Oracle, MySQL, Postgresql etc.)
>> XMLdb (Exist of Sleepycat/Oracle of MSSQL etc.)
> Dat doen we dus nu maar dan zonder al te veel relationele balast

Dit is waarschijnlijk wel de meest simpele oplossing.
Ook als je filstorage gebruikt wil je trouwens de bestanden indexeren in
een database, daar ontkom je niet aan. Het verschil is dat de database
dan alleen een index stap is, en niet als 'storage' laag wordt gebruikt.

XMLdb's geloof ik eerlijk gezegd niet zo in, dan zou ik eerder een
'gewone' database gebruiken.
Ik ben zelf nogal voorstander van RDF, dit combineert volgens mij het
beste uit beide werelden. Je hebt een flexibel 'file based' formaat,
waar je makkelijk nieuwe types en velden kunt introduceren, en je kunt
het uploaden naar een RDF Database waarna alles geïndexeerd is (zonder
gezeur met db schemas enzo).

In alle gevallen heb je nog steeds iets nodig om je fulltext indexing te
doen. Daar ligt volgens mij vooral de waarde van SOLR omdat het erg
goede filter en ranking algoritmes heeft.

gr,
Jasper


>> Repository system (eprint, dspace, Fedora)
> Hmm, dat is toch weer 'one of the above'. Wij noemen het geheel de repository :)
>
> Peter
>

--
Jasper Op de Coul -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands

Patrick Hochstenbach

unread,
Mar 14, 2009, 6:10:53 AM3/14/09
to code...@googlegroups.com
Hebben jullie voor structurele data eens naar CouchDB (http://couchdb.apache.org/) gekeken? Een zeer eenvoudige, schaalbare store voor arbitraire hashes/arrays. Ik ben er wat mee aan het experimenteren hier in de bibliotheek.
Opslaan van data objecten is bijna triviaal te noemen. Ook heb je toegang tot versionering en kunnen binaire files worden opgeslagen. Dit in combinatie met Lucene/SOLR voor full-text search zou een machtige mooie combinatie zijn.

Groeten,
Patrick

PS> CouchDB past in het rijtje SimpleDB (Amazon), BigTable (Google), Memcache. Een migratie weg van relationele databanken..erg in de mode.

Afelonne Doek

unread,
May 11, 2009, 5:29:59 AM5/11/09
to code...@googlegroups.com

Nogmaals oproep voor de Worldcat Mashathon 13-14 mei in het Internationaal Instituut voor Sociale Geschiedenis te Amsterdam. Er zijn nog enkele plaatsen!

Groet, Afelonne Doek (IISG)

 

WORLDCAT MASHATHON IN AMSTERDAM

 

Join fellow coders for the WorldCat Mashathon in Amsterdam, May 13-14. Sponsored by the OCLC Developer Network and International Institute of Social History (IISH), the two-day event will be held Wednesday and Thursday at IISH headquarters in Amsterdam.

 

The European Mashathon follows on the heels of a previous WorldCat Hackathon in New York City. Participants will spend the two days brainstorming and coding mash-ups with local systems, OCLC Web Services, and many other Web Services to embellish existing, and create new, library services.

 

WorldCat includes national catalogues from the Netherlands, the UK, Ireland, Iceland, Germany, Sweden, Finland, Denmark, France, Spain, Switzerland, Czech Republic, Lithuania, Russia and many more—so there are plenty of potential uses and apps just waiting to happen.

 

Why attend the WorldCat Mashathon?

• Brainstorm potential uses for and play with the WorldCat Search API.

• Gain development access to 1.2 billion items from more than 10,000 libraries worldwide.

• Integrate these resources with many others to create innovative new services.

• Meet fellow developers across the information industry.

• Share your creative vision and be a part of the next wave of online library development.

 

Ideas, outcomes and code from the Mashathon, together with a participants list, will be shared during and after the event for others to download and build on.

 

Learn more and register for the WorldCat Mashathon on the OCLC Developer Network wiki. http://worldcat.org/devnet/wiki/2009EUMashathon

 

Reply all
Reply to author
Forward
0 new messages