Kurz gefasst:

  • 85 Pro­zent aller digi­ta­len Inhal­te in Unter­neh­men lie­gen unstruk­tu­riert vor und las­sen sich nicht in Daten­ban­ken spei­chern. Ten­denz: stei­gend. Such­lö­sun­gen hel­fen, die­se Inhal­te zu erschlie­ßen und wie­der zur Ver­fü­gung zu stel­len.
  • Open-Source-Such­pro­jek­te lösen pro­prie­tä­re Enter­pri­se-Such­lö­sun­gen zuneh­mend ab. Ihre Viel­fäl­tig­keit ist ihr Vor­teil: Pro­dukt­zy­klen wer­den durch eine enga­gier­te Ent­wick­ler-Com­mu­ni­ty schnel­ler durch­lau­fen, durch offe­nen Quell­code gibt es für fast jeden Son­der­fall eine Lösung.
  • Die zwei leis­tungs­fä­higs­ten Open-Source-Suchen sind Solr/Lucene und Elastic­se­arch. Um im Enter­pri­se-Umfeld die pas­sen­de Lösung aus­zu­wäh­len, muss man auf die Details ach­ten

Suche ist heut­zu­ta­ge ele­men­ta­rer Bestand­teil einer moder­nen Infor­ma­ti­ons­ar­chi­tek­tur von Unter­neh­men. Das digi­ta­le Daten­wachs­tum ver­dop­pelt sich nahe­zu jähr­lich. Der Groß­teil der pro­du­zier­ten Inhal­te liegt dabei nur in unstruk­tu­rier­ter Form vor. Gleich­zei­tig wird schnel­les und kom­for­ta­bles Fin­den pas­sen­der Infor­ma­tio­nen zuneh­mend unter­neh­mens­kri­ti­scher Bestand­teil all­täg­li­cher Arbeit. Die Open-Source-Com­mu­ni­ty hat für die­se Anwen­dungs­fäl­le in den ver­gan­ge­nen Jah­ren zwei leis­tungs­fä­hi­ge Lösun­gen her­vor­ge­bracht: Solr/Lucene und Elastic­se­arch. Bei­de Pro­jek­te lie­fern sich momen­tan ein Kopf-an-Kopf-Ren­nen um die Vor­herr­schaft im Open-Source-Such­markt. Wäh­rend Solr/Lucene bereits seit vie­len Jah­ren Maß­stä­be setzt, erfährt Elastic­se­arch vor allem seit dem ver­gan­ge­nen Jahr einen gro­ßen Schub im Big-Data-Such­um­feld. Im Fol­gen­den wer­den Ein­satz­zweck sowie gene­rel­le Unter­schie­de bei­der Lösun­gen beleuch­tet, um Hil­fe­stel­lung bei der Aus­wahl der pas­sen­den Open-Source-Such­lö­sung zu bie­ten.

 

Ohne eine effi­zi­en­te und gute Voll­text­such­lö­sung funk­tio­nie­ren Unter­neh­men im digi­ta­len Zeit­al­ter nicht mehr. Laut Gart­ner [1] lie­gen unglaub­li­che 85 Pro­zent der digi­ta­len Inhal­te in Unter­neh­men unstruk­tu­riert vor und las­sen sich nicht in Daten­ban­ken spei­chern. Und die Daten­men­ge steigt wei­ter­hin rasant an. Such­lö­sun­gen hel­fen dabei, die­se Inhal­te zu erschlie­ßen und wie­der zur Ver­fü­gung zu stel­len. In den ver­gan­ge­nen Jah­ren lösen mehr und mehr Open-Source-Such­lö­sun­gen die alten, pro­prie­tä­ren Enter­pri­se-Search-Lösun­gen ab. Vor allem Solr/Lucene, zuneh­mend jedoch auch Elastic­se­arch füh­ren die Rie­ge die­ser neu­en moder­nen Lösun­gen an.

 

Ent­wick­lung und gemein­sa­mer Ursprung bei­der Sys­te­me

Der Open-Source-Such­be­reich hat vor allem durch das von Doug Cut­ting im Jah­re 2001 vor­ge­stell­te Luce­ne Such-Frame­work Auf­schwung erlebt. Hier­bei han­delt es sich um eine Biblio­thek zur Ent­wick­lung von Voll­text­su­chen, die heut­zu­ta­ge die Basis vie­ler Open-Source-Such­lö­sun­gen bil­det. Zuvor muss­te man vie­le Jah­re lang ent­we­der teu­re, pro­prie­tä­re Lösun­gen für eine Voll­text­su­che erwer­ben oder rela­tio­na­le Daten­ban­ken wur­den um eine ein­fa­che, unzu­rei­chen­de Voll­text­su­che erwei­tert. Die­se Ange­bots­si­tua­ti­on führ­te zu einer wach­sen­den Ver­brei­tung von Luce­ne, so dass es im Jahr 2005 Teil des Open-Source-Pro­jekts Apa­che wur­de.

 

Solr ent­stand im Jahr 2006 aus dem Bedarf her­aus, einen Open-Source-basier­ten Enter­pri­se-Search-Ser­ver ein­fach auf Basis von Luce­ne zu betrei­ben. Vor­her ent­wi­ckel­te jedes Pro­jekt sei­ne Such­lö­sung indi­vi­du­ell auf Basis von Luce­ne. Im Jahr 2010 wur­den Solr und Luce­ne dann unter einem Pro­jekt zusam­men­ge­fasst, um die Ent­wick­lung zu beschleu­ni­gen und von­ein­an­der auch inhalt­lich stär­ker pro­fi­tie­ren zu kön­nen.

 

Eben­falls im Jahr 2010 stell­te Shay Banon erst­mals Elastic­se­arch vor. Es basiert wie Solr auf dem Luce­ne-Frame­work und ist eben­so ein Enter­pri­se-Search-Ser­ver. Der Fokus bei der Archi­tek­tur und der Ent­wick­lung lag jedoch sehr stark auf einer ver­teil­ten, ska­lier­ba­ren Voll­text­such­ma­schi­ne. Es ver­folgt damit einen grund­le­gend ande­ren Archi­tek­turan­satz als Solr/Lucene. Die­ses wur­de ursprüng­lich nicht für ver­teil­te Such­lö­sun­gen kon­zi­piert. Durch den stei­gen­den Bedarf von Big-Data-Such­lö­sun­gen erfuhr Elastic­se­arch in den ver­gan­ge­nen Mona­ten einen enor­men Schub in der Ver­brei­tung.

 

Solr/Lucene ist jedoch immer noch wei­ter ver­brei­tet und mitt­ler­wei­le auch in vie­len Soft­ware-Lösun­gen als Enter­pri­se-Search-Ser­ver inte­griert. Eine gro­ße Zahl pro­prie­tä­rer Lösun­gen wur­de damit ersetzt. Wich­ti­ge Fak­to­ren für den gro­ßen Erfolg Luce­ne-basier­ter Such­lö­sun­gen sind Kos­ten, Sta­bi­li­tät, Erwei­ter­bar­keit und Geschwin­dig­keit.

 

Bei­de Lösun­gen sind unter einer sehr libe­ra­len Open-Source-Lizenz nutz- und erwei­ter­bar (Apa­che 2.0 Lizenz). Bei bei­den Pro­jek­ten ist der Quell­code kom­plett offen und es wer­den kei­ne Lizenz­kos­ten für den kom­mer­zi­el­len Gebrauch fäl­lig.

 

Funk­ti­ons­um­fang: Wie Goog­le?

Bei­de Lösun­gen haben in den ver­gan­ge­nen zwei Jah­ren sowohl in ihrer Ver­brei­tung als auch in ihrem Fea­ture-Ange­bot gro­ße Fort­schrit­te gemacht. Durch die von Goog­le gepräg­te Erwar­tungs­hal­tung von Nut­zern an moder­ne Such­lö­sun­gen brin­gen bei­de die rele­van­ten Such­ser­ver-Fea­tures mit. Sie bie­ten eine kom­ple­xe Que­ry­spra­che für vie­le ver­schie­de­ne Ein­satz­zwe­cke und umfang­rei­che indi­vi­dua­li­sier­ba­re Rele­vanz­funk­tio­nen. Sie ermög­li­chen eine Echt­zeit-Indi­zie­rung von Inhal­ten, sind durch eine Viel­zahl von Plug­ins erwei­ter­bar und bie­ten Auto-Sug­gest-Funk­tio­na­li­tät und Tipp­feh­ler­kor­rek­tur. Selbst geo­ba­sier­te Such­vor­gän­ge auf Basis von Geo­ko­or­di­na­ten wer­den unter­stützt, eben­so die auf vie­len Such­sei­ten für die After-Search-Navi­ga­ti­on rele­van­ten Ergeb­nis-Facet­ten.

 

Die Sprach­ana­ly­se-Fähig­kei­ten wur­den suk­zes­si­ve wei­ter aus­ge­baut, so dass eine Viel­zahl von Spra­chen bei der Indi­zie­rung von Daten und bei der Suche unter­stützt wird. Bei­de Lösun­gen ver­fü­gen über ent­spre­chen­de Schnitt­stel­len und las­sen sich so gut von einem Such-Front­end oder ande­ren Appli­ka­tio­nen inte­grie­ren.

 

Weder Solr/Lucene noch Elastic­se­arch besit­zen ein ein­ge­bau­tes Rech­tema­nage­ment. Dies war in bei­den Pro­jek­ten eine bewuss­te Design­ent­schei­dung. Aus die­sem Grund müs­sen Nut­zungs­rech­te und Zugrif­fe durch äuße­re Appli­ka­tio­nen umge­setzt wer­den.

 

Rele­van­te Unter­schie­de im Basis-Funk­ti­ons­um­fang gibt es dem­zu­fol­ge nicht. Sowohl mit Solr/Lucene als auch mit Elastic­se­arch las­sen sich her­vor­ra­gen­de Such­lö­sun­gen nach Goo­g­les Vor­bild bau­en. Bei der Aus­wahl ent­schei­det hier meist die Vor­lie­be der Ent­wick­ler oder der Con­sul­ting­fir­ma.

 

Genau hin­ge­schaut: die Unter­schie­de

Solr/Lucene besticht durch eine gute Erwei­ter­bar­keit, die in vie­len Pro­jek­ten mit zuneh­men­der Lauf­zeit eine Rol­le spielt. Ent­wick­ler kön­nen mit wenig Auf­wand den Such- und Indi­zie­rungs­work­flow durch eige­ne Soft­ware oder sogar kom­mer­zi­el­le Dritt­soft­ware, wie z.B. Seman­tikmodu­le oder Share­point-Inte­gra­ti­on, anpas­sen. Elastic­se­arch bie­tet hier vor allem vor­ge­fer­tig­te Plug­ins und ist weni­ger gut erwei­ter­bar.

 

Solr/Lucene ver­fügt über eine außer­or­dent­lich gute Doku­men­ta­ti­on. Elastic­se­arch man­gelt es noch an der Doku­men­ta­ti­ons­tie­fe und an kon­kre­ten Anwen­dungs­bei­spie­len. Hier hat Solr/Lucene sicher das sta­bi­le­re, erfah­re­ne­re Ent­wick­ler-Fun­da­ment. Die akti­ve Ent­wick­ler­ba­sis bei­der Pro­jek­te ist mitt­ler­wei­le ähn­lich groß, so dass man Sup­port und Hil­fe bei bei­den Lösun­gen für gewöhn­lich sehr schnell bekommt, so lan­ge das eige­ne Pro­blem detail­liert genug beschrie­ben ist.

 

Ein zen­tra­ler Unter­schied ist die Sche­ma­lo­sig­keit von Elastic­se­arch. Dies bedeu­tet, dass zu Pro­jekt­be­ginn kei­ne Daten­struk­tur ange­ge­ben wird, son­dern Elastic­se­arch die Aus­wahl von Daten­ty­pen auto­ma­tisch voll­führt. Die­ser doku­men­ten­zen­trier­te Ansatz kommt aus dem Bereich der Big-Data-Anwen­dungs­fäl­le, bei denen man es mit vie­len unter­schied­li­chen Daten zu tun hat. Unter­schied­li­che Doku­men­te las­sen sich so bequem in einem Index spei­chern und abfra­gen. Sche­ma­lo­sig­keit ist ein rele­van­ter Trend moder­ner Daten­ban­ken, aller­dings in vie­ler­lei Hin­sicht auch ris­kant. Eine qua­li­ta­tiv hoch­wer­ti­ge Voll­text­su­che bedarf einer kon­kre­ten Daten­spe­zi­fi­ka­ti­on, um Ergeb­nis­re­le­vanz, Indi­zie­rung und Ana­ly­se opti­mal umzu­set­zen.

 

Elastic­se­arch kann Such­an­fra­gen spei­chern und – sobald neue Doku­men­te indi­ziert sind – fest­stel­len, ob die­se von der Such­an­fra­ge gefun­den wer­den. Hier­mit las­sen sich Echt­zeit-Alerts für The­men und Tref­fer umset­zen. Solr/Lucene bie­tet eine sol­che Funk­ti­on nicht.

 

Der Anwen­dungs­fall Big Data 

Ska­lier­bar­keit von Such­tech­no­lo­gie ist ein zuneh­mend rele­van­ter Fak­tor. Durch die ver­stärk­te Nut­zung von Such­lö­sun­gen für Big-Data-Spei­che­rung, Busi­ness Intel­li­gence und in gro­ßen such­ba­sier­ten Anwen­dun­gen (wie z.B. Lin­kedIn) wer­den im Pro­jekt­ver­lauf oft­mals wei­te­re Daten­quel­len ange­bun­den. Die ver­ti­ka­le Ska­lier­bar­keit wird schnell unter­neh­mens­kri­tisch. Das zu erwar­ten­de Daten­vo­lu­men muss man bei der Aus­wahl der Lösung berück­sich­ti­gen. Elastic­se­arch wur­de von Grund auf für die­sen Anwen­dungs­fall kon­zi­piert und bringt dadurch Vor­tei­le mit.

 

Bei­spiels­wei­se funk­tio­niert bei Elastic­se­arch die Ver­tei­lung und Ska­lie­rung auf vie­le Hard­ware­sys­te­me weit­ge­hend pro­blem­los. Bei Aus­fäl­len von Maschi­nen eines Clus­ters wer­den die nicht mehr erreich­ba­ren Daten auf Basis von repli­zier­ten Ver­sio­nen der Daten auf noch lau­fen­den Maschi­nen auto­ma­tisch auf ande­re Maschi­nen des Clus­ters trans­fe­riert. Sobald die Maschi­nen wie­der ver­füg­bar sind, erfol­gen die Reinte­gra­ti­on in den Clus­ter und die Aktua­li­sie­rung voll­au­to­ma­tisch.

 

Solr/Lucene wur­de in Ver­si­on 4.0 durch das SolrCloud Plug­in erwei­tert. SolrCloud wur­de im Gegen­satz zur auto­ma­ti­schen Ver­tei­lung in Elastic­se­arch erst im Nach­gang ent­wi­ckelt und lässt wich­ti­ge Fea­tures wie auto­ma­ti­sches Reb­a­lan­cing im Fall von Sys­tem­aus­fäl­len ver­mis­sen. Man hat es nach sehr lan­ger Ent­wick­lungs­zeit ver­gleichs­wei­se spät ver­öf­fent­licht. Letzt­lich stellt es nur ein Add-on zu Solr/Lucene dar und ist nicht Teil der ursprüng­li­chen Archi­tek­tur­ba­sis.

 

Fest­hal­ten muss man aller­dings, dass der Groß­teil der Enter­pri­se-Search-Pro­jek­te meist nicht Big Data ist und somit die Daten­ska­lie­rung nicht not­wen­di­ger­wei­se ein Ent­schei­dungs­kri­te­ri­um dar­stellt. Die meis­ten Anwen­dungs­fäl­le erfor­dern Aus­fall­si­cher­heit und hohe Such­ge­schwin­dig­keit. Dies lässt sich mit bei­den Lösun­gen sehr gut umset­zen.

 

Sta­bi­li­tät und Kos­ten in der Pra­xis

Bei­de Lösun­gen gel­ten als außer­or­dent­lich sta­bil und res­sour­cen­scho­nend. Vor allem die klas­si­sche Mas­ter-Slave-Archi­tek­tur ist sehr sicher und sta­bil und lässt sich kos­ten­güns­tig auf Stan­dard-Ser­ver­hard­ware betrei­ben. Bei­den Lösun­gen merkt man an, dass sie auf einem sehr aus­ge­reif­ten Fun­da­ment (Luce­ne) auf­set­zen. Sie glän­zen im All­tag durch Sta­bi­li­tät. Betrach­tet man jedoch das Big-Data-Sze­na­rio, kann es ver­gleichs­wei­se schnell pro­ble­ma­tisch wer­den.

 

Ein hoch­dy­na­mi­sches Sys­tem mit vie­len unter­schied­li­chen Daten erfor­dert im Betrieb viel Auf­merk­sam­keit und ist kein Selbst­läu­fer. Durch Plug­ins las­sen sich bei­de Lösung opti­mal über­wa­chen und in ein bestehen­des Moni­to­ring ein­bin­den. Sowohl Solr/Lucene als auch Elastic­se­arch brin­gen von Haus aus Admi­nis­tra­ti­ons­ober­flä­chen für den Betrieb und die Kon­fi­gu­ra­ti­on mit. Zuneh­mend gibt es auch kom­mer­zi­el­le Alter­na­ti­ven wie z.B. Elastic­se­arch Mar­vel, um bei­de Lösun­gen als gro­ße Such­clus­ter zu betrei­ben und zu über­wa­chen.

 

And the Win­ner is …

Solr/Lucene und Elastic­se­arch ähneln sich funk­tio­nal wegen des gemein­sa­men Luce­ne-Kerns, so dass es in all­täg­li­chen Anwen­dungs­fäl­len allen­falls fei­ne Unter­schie­de gibt und durch­aus die Vor­lie­be der Ent­wick­ler den Aus­schlag geben darf. Solr/Lucene gefällt vor allem durch sei­ne wei­te, sta­bi­le Ver­brei­tung, gute Erwei­ter­bar­keit und sinn­vol­le Repli­ka­ti­ons­me­cha­nis­men, die in vie­len Fäl­len aus­rei­chen und sich bewährt haben. Elastic­se­arch baut aktu­ell vor allem sei­ne Busi­ness Intel­li­gence- und Ana­ly­tics-Fähig­kei­ten aus und eig­net sich her­vor­ra­gend in Big-Data-Sze­na­ri­en. Somit ist es bei der Pla­nung eines gro­ßen Such­clus­ters mit rie­si­gen Daten­men­gen aus unter­schied­li­chen Daten­quel­len die ers­te Wahl.

 

Der häu­figs­te Enter­pri­se-Search-Case ohne gro­ße Ent­wick­lungs­ab­tei­lung und ohne kom­ple­xe eige­ne Anpas­sun­gen an der eigent­li­chen Such­soft­ware lässt sich durch bei­de Lösun­gen sehr gut bedie­nen. Die Ent­schei­dung soll­te jedoch klar für eine der bei­den Lösun­gen gefällt wer­den – bei­de Lösun­gen gleich­zei­tig im Ein­satz zu haben, ist durch die Unter­schie­de im Betrieb und in den Details der Anwen­dun­gen wenig sinn­voll.

 

Vom star­ken Wett­be­werb zwi­schen bei­den Lösun­gen pro­fi­tie­ren alle Anwen­der glei­cher­ma­ßen. Inno­va­tio­nen der einen Sei­te hal­ten in der einen oder ande­ren Form auch recht schnell Ein­zug auf der ande­ren Sei­te. Per­for­mance­ver­bes­se­run­gen fin­den für gewöhn­lich direkt auf Luce­ne-Ebe­ne statt, wovon bei­de Lösun­gen unmit­tel­bar pro­fi­tie­ren. Bei allen Abwä­gun­gen in den Details tritt eines jeden­falls ein­deu­tig zu Tage: Der Ein­satz pro­prie­tä­rer Such­lö­sun­gen lohnt sich allen­falls noch bei sehr indi­vi­du­el­len, spe­zi­el­len Anwen­dungs­fäl­len, in denen die Anpas­sungs­auf­wän­de und lau­fen­den Kos­ten für den Ein­satz von Open Source zu hoch wären.

 

Anmer­kung:

[1] Quel­le: Gart­ner; Infor­ma­ti­on 2020: Big Data and Bey­ond