enterprise search – Smals Research https://www.smalsresearch.be Mon, 04 May 2026 09:51:08 +0000 en-GB hourly 1 https://wordpress.org/?v=7.0 https://www.smalsresearch.be/wp-content/uploads/2026/01/cropped-cropped-Smals_Research-32x32.png enterprise search – Smals Research https://www.smalsresearch.be 32 32 Cognitive Search: l’évolution des moteurs de recherche d’entreprise https://www.smalsresearch.be/cognitive-search-levolution-des-moteurs-de-recherche-dentreprise/ Mon, 11 Mar 2019 14:30:25 +0000 /?p=12761 « Data is the New Gold » : voici une citation que l’on a maintes fois vue et entendue quand il s’agit de parler de science des données ou d’intelligence artificielle. Ce blog se concentre sur les données non structurées et textuelles et une des nouvelles techniques qui permettent d’extraire « l’or » contenu dans celles-ci.

Les entreprises et organisations disposent en effet d’une grande quantité de données structurées et non structurées, souvent sous forme de textes. Pour exploiter au mieux l’information contenue dans ses données, elles utilisent des systèmes de recherche (Enterprise Search) pour retrouver rapidement l’information utile et pertinente. L’enterprise search désigne un système similaire au web search visant à faciliter la recherche d’information. Les données provenant de sources telles que les emails, l’intranet, les systèmes de gestion documentaires et les bases de données sont rassemblées et indexées tel qu’il soit aisé de naviguer et de retrouver du contenu. Ce système permet aussi de gérer la sécurité et les accès à l’information. Compte tenu du volume et de la complexité des données générées, il est parfois difficile et long d’accéder à l’information pertinente. En effet selon la façon dont la requête est effectuée, les moteurs de recherche retournent une liste plus ou moins longue de résultats que l’utilisateur doit passer en revue un par un pour retrouver l’information désirée.

La solution décrite ici se focalise sur l’implémentation d’un outil de recherche rapide type « web » et n’inclut pas la construction de thésaurus; les thésaurus apportent précision et spécificité mais ils requièrent des moyens et un effort manuel considérables.

Extrait de “The Forrester WaveTM: cognitive Search And Knowledge Discovery Solutions, Q2 2017″

Une nouvelle approche du enterprise search dite cognitive search, a été développée dans l’optique d’exploiter au mieux les données contenues dans les documents de l’entreprise et de proposer des résultats plus ciblés ; le cognitive search permet d’aller plus loin en intégrant le traitement automatique du langage naturel (NLP) et l’intelligence artificielle. Ces techniques sont utilisées pour enrichir l’information, elles permettent au système d’interpréter la requête et de proposer un résultat ciblé et pertinent. Cette approche est dite cognitive car elle tient compte du contexte et des préférences de l’utilisateur pour la recherche et s’améliore avec l’utilisation. On peut la caractériser par les points suivants :

  • Capacité d’intégrer les données ayant différents formats et provenant d’une multitude de sources externes et internes telles que les bases de données RDBMS/NO SQL, Sharepoint, les emails, …
  • Possibilité d’enrichir les données grâce à l’utilisation du NLP et de l’apprentissage automatique. En appliquant des techniques telles que l’extraction d’entités et de concepts, la classification, l’extraction des relations entre entités et la détection de thèmes (topic detection),
  • Personnalisation et contextualisation de l’information en combinant entre autre le moteur de recherche à une base de connaissance graphe (Knowledge Graph),
  • Adaptabilité à l’utilisateur en utilisant par exemple les systèmes de recommandations qui proposent des résultats basés sur les précédentes requêtes d’utilisateurs,
  • Capacité de s’améliorer au cours du temps c.-à-d. améliorer la pertinence des résultats.
Azure cognitive search de Microsoft combine le service Azure search avec des outils tels que Text analytics et Computer vision

Cette technologie présente un avantage particulier pour le secteur public qui génère une énorme masse de documents, répartis dans plusieurs bases de données sous différents formats. Les utilisateurs doivent pouvoir analyser et traiter des documents de manière rapide et efficace, en tenant compte des règles d’application dans leur domaine. Ces règles sont stockées dans des bases de connaissances mais changent régulièrement en fonction des politiques gouvernementales. Il est donc important pour assurer le traitement correct et équitable des dossiers que ces bases de données soient à jour et faciles à consulter. L’autre avantage qu’apporterait un système de recherche dit cognitif est qu’il tient compte du contexte et donne un résultat ciblé, on pourrait donc changer de paradigme ; l’utilisateur ne doit plus chercher activement un document dans la base de données mais en fonction du contexte et du processus (business process) dans lequel il évolue, les documents/ l’information lui sont suggérés.  En outre un système, rapide et spécifique, pourrait facilement s’intégrer avec des applications qui exécutent des requêtes tels que les chatbots, voire des applications mobiles. Une base de connaissance graphe (knowledge graph) associée au cognitive search permettrait aussi de mettre en évidence la connaissance « cachée » c.-à-d. découvrir des liens entre entités, des régularités ou des anomalies. Le cognitive search ne serait donc pas seulement utilisé pour rechercher du contenu mais il permettrait aussi de découvrir de la connaissance (knowledge discovery).  Ceci est notamment appliqué dans l’industrie des sciences du vivant pour accélérer le développement de nouveaux traitements. Dans ce contexte, la technologie est utilisée pour  extraire la connaissance générée par les équipes de recherche et contenue dans les LIMS (laboratory information management system), ELN (electronic lab notebook) , base de données scientifiques, etc (solution développée par ATTIVIO).

En résumé, le cognitive search offre beaucoup de possibilités et de facilités en termes de recherche d’information. Cette technologie permet à l’utilisateur de retrouver rapidement du contenu pertinent et contextualisé. Néanmoins son implémentation est complexe et à ses limites. Il faut ingérer l’information provenant de sources diverses sous différents formats et en extraire des textes qui seront indexés. Les algorithmes utilisés par exemple pour les systèmes de recommandations et d’extraction d’entités nécessitent d’être entrainés avec des données de qualité. Très souvent, ces modèles générés par apprentissage automatique ont une marge d’erreur non négligeable et il est alors nécessaire de les combiner avec des modèles basés sur des règles bien définies (rule-based). Il n’est pas non plus facile de mettre en place des solutions qui supportent plusieurs langues, étant assez générales pour inclure plusieurs domaines business tout en gardant la capacité de fournir des résultats de recherche pertinents. Et enfin, l’amélioration des performances du système de recherche ne se fait pas de façon totalement automatique. Par exemple, pour ce qui est de la solution développée par IBM (Watson Discovery), l’utilisateur doit fournir au système des exemples de requêtes types et classer les résultats retournés par celui-ci.

Etant donné ces difficultés, il est important de bien mesurer les avantages et inconvénients d’un tel système avant d’envisager de l’implémenter. Cependant, les fonctionnalités de recherche avancée qu’apporte le Cognitive Search restent impressionnantes si l’on accepte une certaine marge d’erreur.

Références

The Forrester Wave™: Cognitive Search And Knowledge Discovery Solutions, Q2 2017

5-Minute Guide to Cognitive Search for the Life Sciences (ATTIVIO)

https://azure.microsoft.com/en-in/blog/global-scale-ai-with-azure-cognitive-services

ttps://www.ibm.com/cloud/garage/architectures/cognitiveDiscoveryDomain/

https://www.elastic.co/

]]> Doorzoek je interne websites met Nutch https://www.smalsresearch.be/doorzoek-je-interne-websites-met-nutch/ Mon, 11 Mar 2013 09:16:53 +0000 /?p=5218

nutch_logo_tmIn een grotere organisatie heb je wel meerdere teams die een eigen website/wiki hebben naast het klassieke intranet. Vaak is dit niet geïntegreerd, terwijl dit een interessante bron van informatie kan zijn. Zoekmachines zijn de methode bij uitstek om disparate bronnen samen te brengen en doorzoekbaar te maken zonder alle sites samen te brengen op één platform.

In de open source wereld zijn Apache Lucene en Solr de vaakst genoemde oplossingen om een zoekmachine te bouwen. Het probleem is dat deze geen ‘web crawler’ bevatten, namelijk een systeem dat webpagina’s opvraagt, de inhoud indexeert en de aanwezige links op hun beurt verwerkt, net zoals Google doet. Apache Nutch is een zusterproject van Lucene dat zich op dit terrein waagt, namelijk een “Google” voor intern gebruik. In deze post gaan we eens kijken hoe je Nutch opzet en gebruikt. Merk op dat dit een technische uitleg zal zijn.

Voorbereiding

Nutch bestaat al sinds 2005 als Apache project en bestaat momenteel in twee versies: 1.6 (de stabiele versie waar er nog releases op gebeuren) en 2.1 (een vernieuwde versie met ondersteuning voor NoSQL backends). Voor de tests heb ik gekozen voor de laatste versie (2.1). Het eerste wat opvalt is het gebrek aan goede documentatie voor de 2.x reeks. Er zijn wat startpunten (Nutch op HBase en op MySQL) maar vaak ben je toch aangewezen op forums en blogposts van anderen.
Al snel bleek dat het opzetten niet zo evident was aangezien de onderliggende database tijdens het crawlen crashte. Na pogingen met HBase, MySQL en Cassandra, is het uiteindelijk toch gelukt met HBase, nadat de onderliggende machine genoeg RAM geheugen had gekregen (6GB in dit geval). Let op dat je niet de laatste versie gebruikt van HBase maar een versie die compatibel is met Nutch, zoals de versie 0.90.6.
Nutch zal volgende stappen doorlopen bij een eerste crawl:
  • initiële URL’s worden aan Nutch gegeven, bijv. de lijst met websites die je wenst te indexeren (inject)
  • en dan doorloopt Nutch een aantal maal het proces (dit wordt de depth genoemd)
    • generatie van lijst van URLs die moet behandeld worden (generate)
    • pagina’s ophalen (fetch)
    • inhoud van de pagina’s verwerken (parse). Hierbij kunnen zowel gewone html pagina’s geïndexeerd worden als documenten (PDF, DOC, …)
    • de Nutch DB update (updatedb)
    • opslag van de resultaten in Solr (solrindex)

Hier kan je een voorbeeldscript vinden dat alle stappen samenbrengt. Je kan ook gebruiken maken van het ‘crawl’-commando dat de stappen combineert, maar dan heb je minder zicht op de verschillende stappen van het proces.

Nutch kan zowel websites crawlen (http(s)://) als filesystemen (file:// en ftp://). Bij websites waar een HTTP authenticatie vereist is kunnen de nodige credentials in een configuratiebestand opgenomen worden. Let natuurlijk wel op dat dit credentials zijn die geen beschermde of gevoelige inhoud kunnen beschikbaar maken omdat de zoekresultaten publiek beschikbaar zullen zijn.

Configuratie

De configuratie van Nutch gebeurt in nutch-site.xml waar je de standaardparameters uit nutch-default.xml kan aanpassen. De interessante parameters zijn daar:
  • http.agent.name : welke browser agent string wordt er door doelwebsites gezien zodat je op die sites een crawler kan toelaten en ook een verschil kan maken tussen crawler-traffiek en gewone traffiek.
  • parser.character.encoding.default : welke encoding er moet gebruikt worden als deze ontbreekt (bijv. utf-8).
  • storage.data.store.class : welke backend er wordt gebruikt, bijv. org.apache.gora.hbase.store.HBaseStore voor Hbase.
  • plugin.includes : Nutch heeft een plugin architectuur die het mogelijk maakt om bepaalde functionaliteit toe te voegen. Er zijn een aantal plugins die standaard geconfigureerd zijn. In het geval van de tests werden volgende plugins gebruikt
protocol-httpclient|urlfilter-regex|parse-(html|tika)|index-(basic|anchor|more)|urlnormalizer-(pass|regex|basic)|scoring-opic
  • db.ignore.external.links : geeft aan of de crawler buiten de initieel aangegeven websites links mag volgen.
  • file.content.limit & http.content.limit: hoe groot mogen de geïndexeerde bestanden of webpagina’s zijn. Dit moet overeenkomen met wat je als groottebeperking opgeeft in de onderliggende databank.

Backend

De HBase backend kan ook getuned worden maar dat is eigenlijk een topic op zich. Je kan hier en hier wat  informatie vinden. Het belangrijkste is dat er genoeg geheugen beschikbaar is.

Plugins

Zoals gezegd zijn er verschillende plugins die het proces kunnen sturen. Je kan die plugins ook apart aanroepen om het effect van een bepaalde configuratie te testen, wat uitermate handig is.
De standaardplugins die mij goed van pas kwamen:
  • URLfilter-regex

Je kan URL’s filteren en bepalen welke URL’s in aanmerking komen en welke niet. In het configuratiebestand “regex-urlfilter.txt” kan je dit met behulp van reguliere expressies configureren. URL’s die voldoen aan de expressie kan je dan uitsluiten door er ‘-‘ voor te zetten of expliciet toevoegen door ‘+’. Zo zal de regel

-index.php/Help:.*

Wikimedia links met de hulppagina’s niet indexeren of kan je bijvoorbeeld instellen dat het url-pad niet dieper mag zijn dan 7 niveau’s:

"-.*/(?:[^/]+/){7,}

Je kan een regel toevoegen aan het bestand en dan testen met:

 <installatiedir>/bin/nutch plugin urlfilter-regex org.apache.nutch.urlfilter.regex.RegexURLFilter

Je geeft dan een url in en krijgt dan het resultaat of deze al dan niet gefilterd wordt.

  • URLNormalizer-regex

De opgehaalde URL’s kan je normalizeren naar een bepaalde vorm. Dit is vooral handig als je bijvoorbeeld een site indexeert waarvan documenten op verschillende locaties terugkomen maar met een verschillend pad. Dit was in de tests het geval met een website gebaseerd op IBM Lotus Domino. De url naar een document hangt af van het pad langswaar je er naar toe gaat.

Eenzelfde document heeft bijvoorbeeld als urls (met zijn identifier als laatste parameter):

http://website/databank.nsf/<id1>/<id>?OpenDocument
http://website/databank.nsf/<id2>/<id>?OpenDocument

Als je dan weet dat er een URL bestaat om het document rechtstreeks op te vragen door

http://website/databank.nsf/View/<id>

dan kan je de bovenstaande urls normalizeren met behulp van volgende expressies

<regex>
 <pattern>(\.nsf)/[^/]*/(.*OpenDocument$)</pattern>
 <substitution>$1/View/$2</substitution>
</regex>
  • index-more

Deze plugin indexeert onder andere ook het content-type van de gecrawlde inhoud. Dit kan je achteraf gebruiken om in de zoekmachine te kunnen vernauwen op bepaalde content types zoals een PDF.

Integratie met Solr

Nutch heeft zijn eigen index maar je kan de gecrawlde pagina’s in Solr stoppen. Dit heeft als voordeel dat je een centrale Solr server kan gebruiken voor allerlei zoekfuncties en dat je de kracht, flexibiliteit en mogelijkheden van Solr kan gebruiken. De configuratie van Solr valt echter buiten het bestek van deze post. Je kan facetten gebruiken op specifieke velden zoals de beschikbare websites, de content types en zelfs de taal die gedetecteerd werd.
Als je geen gebruik wenst te maken van Solr kan je ook ElasticSearch gebruiken.
Het feit dat er nog een extra index wordt gebruikt heeft natuurlijk wel als resultaat dat je twee backends hebt met de gegevens. Het voordeel is wel dat de Solr instantie los staat van Nutch en dus ook gevoed kan worden met andere data.

Aangezien Nutch 2.1 zelf geen userinterface heeft om de index te doorzoeken ben je zowiezo aangewezen op een UI die bijvoorbeeld bovenop Solr staat. In de tests werd geëxperimenteerd met Ajax-solr, een set Javascript libraries om een UI te bouwen.

3,2,1 … start

Na alles te hebben geïnstalleerd en configureerd kan je een crawl starten. Het blijkt al snel dat er redelijk wat tuning nodig is om de crawl snel genoeg te laten verlopen.

Snelheid

De standaardconfiguratie van Nutch beperkt sterk het aantal pagina’s per tijdseenheid die worden opgehaald. In een eerste run (7 iteraties van het hierboven beschreven proces) duurde het verschillende uren om 6000 pagina’s op te halen. Je kan dit sneller laten verlopen door te spelen met de parameter fetcher.server.delay (aantal seconden tussen requests op eenzelfde server, zodat je een server niet overspoelt met requests, ) en een aantal parameters van de Fetcher threads ( fetcher.threads.fetch,  fetcher.threads.per.queue, fetcher.threads.per.host). Met de waarden 3, 30, 15 en 3 voor deze vier parameters verliep dezelfde crawl een heel stuk sneller. Er werden uiteindelijk 80 000 urls verwerkt op 2.5 uur. Je moet wel in de gaten houden of de server nog meekan, de onderliggende backend en de Solr-instantie.

Onderhoud

De resultaten van de crawl kan je gaan bekijken door zoekopdrachten uit te voeren en te gaan kijken of er ongewenste resultaten bij zijn of andere vreemde URLs. Die kan je dan in de Nutch configuratie uitsluiten of omvormen.

Daarnaast moet je ook gaan kijken in de Solr index en configuratie wat er daar allemaal is van mogelijkheden en verbeteringen. Na aanpassingen te hebben gedaan in Solr kan je  de volledige Nutch-index opnieuw in Solr stoppen door volgend commando:

> bin/nutch solrindex <Url van solr> -reindex

Vernieuwen van pagina’s

Een onduidelijk punt dat bleef is het verversen van de pagina’s. Het zogenaamd “recrawlen” is niet goed gedocumenteerd. In de Nutch index wordt er bijgehouden wanneer een pagina opnieuw mag opgehaald worden. Deze waarde wordt ingesteld aan de hand van de parameters rond de “Fetchschedule” zoals db.fetch.interval.default. Standaard zal Nutch maar na 30 dagen een pagina opnieuw ophalen. Je kan voor een pagina gaan kijken wanneer ze de volgende keer zal opgehaald worden via volgend commando:

> bin/nutch readdb -url http://website.com/pagina
key: http://website.com/pagina
baseUrl: http://website.com/pagina
status: 2 (status_fetched)
fetchInterval:  83000
fetchTime:      1360246212783
prevFetchTime:  1360162351060
....
title:  Title
De parameter fetchTime geeft de datum & tijd vanaf wanneer de pagina opnieuw mag opgehaald worden. In dit geval is dit 1360246212(783) wat je via het commando date kan omzetten:
> date -u -d @1360246212
Thu Feb  7 14:10:12 UTC 2013

Het fetchInterval zal worden toegevoegd aan de moment dat de pagina opnieuw wordt opgevraagd, in dit geval 83000 seconden of 23 uur. Zo zal je dus elke dag de pagina’s kunnen vernieuwen.

Voor een recrawl kan je je bijvoorbeeld beperken tot 2 iteraties van het crawlproces. Zo worden bestaande pagina’s opnieuw overlopen en eventueel nieuwe links gedetecteerd. Deze worden dan in de volgende iteratie ook mee geïndexeerd. Het heeft ook als gevolg dat je index nog verder groeit als er bij vorige iteraties nog extra links werden gedetecteerd. Zo werd in de test een index van 80 000 pagina’s er snel eentje van 220 000 pagina’s.

Pagina’s die verdwijnen worden niet uit de Solr-index verwijderd. In Nutch 1.6 was er hiervoor een aparte job, voor Nutch 2.x is dit momenteel voorzien in de trunk en zal dit met de nieuwe versie beschikbaar zijn.

Gezien de indexatietijd redelijk beperkt is kan je er ook voor opteren om telkens een nieuwe crawl uit te voeren en de vorige index steeds te wissen.

Conclusie

Met de end-to-end implementatie van deze test is duidelijk dat er heel wat komt kijken bij de implementatie van een zoekoplossing, niet alleen voor de pure installatie/configuratie maar ook voor het iteratieve onderhoud zoals het opsporen/weren van ongewenste URLs.  Het ter beschikking stellen van de nodige Solr functionaliteit (zoals omgaan met meertaligheid, facetten, autocompletion, spellingscontrole, …) neemt ook een heel stuk van de implementatie in beslag. Dan spreken we nog niet over het nut van statistiek achteraf, zodat de zoekmachine meer kan aangepast worden naar de noden van de eindgebruiker. De implementatie van een zoekmachine is in dit aspect geen project maar een continu proces.

Nutch 2.1 is nog wat ruw, vooral op documentatievlak en ontbreekt ook nog een aantal belangrijke features zoals het schoonmaken van de Solr-index bij het verdwijnen van pagina’s. Maar het is alleszins een bruikbaar systeem. De nodige competenties gaan echter verder dan Nutch alleen want als je een NoSQL backend zoals HBase gebruikt heb je daar uiteraard ook kennis van nodig en met Solr heb je enorme mogelijkheden tot je beschikking.

Een gebruiker van een dergelijke zoekmachine kan alleen maar beter worden van een systeem dat alle interne websites ter beschikking stelt. Daar staat natuurlijk tegenover dat dit niet zo evident is om dit op een gebruiksvriendelijke manier aan te brengen. De aangeboden functionaliteit van een crawler is ook beperkt tot de gegevens die beschikbaar zijn in de webpagina. Standaard zal je dus de inhoud van de pagina in de index stoppen met wat metadata (zoals datum, content-type, url). Wil je meer specifieke informatie zoals de auteur van de tekst dan kan je dit niet met de crawler (tenzij je een specifiek veld hebt en de nodige logica om de auteur uit een metadata veld te halen op de pagina). Daarom dat een content management systeem dat zelf zijn inhoud in de zoekmachine stopt meer rijke informatie kan ter beschikking stellen.

]]> e-Discovery – Quesaco ? https://www.smalsresearch.be/e-discovery-quesaco/ Wed, 23 Nov 2011 07:00:26 +0000 /?p=3288 Il arrive régulièrement que l’on me demande ce qu’est l’e-discovery et dans quelle mesure cela peut intéresser nos clients. L’e-discovery “refers to any process in which electronic data is sought, located, secured, and searched with the intent of using it as evidence in a civil or criminal legal case. E-discovery can be carried out offline on a particular computer or it can be done in a network. Court-ordered or government sanctioned hacking for the purpose of obtaining critical evidence is also a type of e-discovery” (source).

Explication

Il s’agit donc de pouvoir retrouver des données électroniques suite à une demande d’un juge ou pour prouver un élément devant les tribunaux. Pour ce faire, il faut mettre en place une démarche globale, qui a fait l’objet d’un modèle de référence (http://www.edrm.net/) comportant 9 étapes :

Ce n’est donc pas simplement une recherche d’informations dans un ou plusieurs systèmes à l’aide d’un outil de recherches. Le but visé par une recherche de type ‘e-discovery’ est de retrouver toutes les données concernant une demande bien spécifique.

Le e-discovery est :

  • une obligation de garder toute preuve (ou élément de preuve) que l’on estime relevant (à définir – cela peut aller jusqu’au SMS échangés – pensons au Fortisgate) ;
  • une interdiction de détruire tout document une fois un litige ouvert ou en voie d’ouverture ;
  • une obligation de fournir la liste des documents disponibles à l’autre partie afin qu’elle puisse en prendre connaissance et l’utiliser en justice ;
  • un besoin de pouvoir répondre dans des temps relativement courts (endéans la semaine).

En cela, il se différencie d’une démarche de type “information retrieval / search” qui n’a pas les mêmes exigences en matière d’exhaustivité et de preuve.

Origine

Ce besoin trouve son origine dans le droit anglo-saxon et dans un amendement du Federal Rules of Civil Procedure aux États-Unis. Alors que dans le droit européen, le juge ne peut exiger que la production d’un document bien particulier pour lequel il a des présomptions sérieuses qu’une des parties le détient, dans le droit anglo-saxon, le juge (ou une autorité de contrôle dans le cadre d’une enquête) peut exiger la production d’un ensemble de documents ou tous les documents qui concernent l’objet du litige (ou de l’enquête). En outre, les sanctions en cas de perte sont beaucoup plus sévères qu’en Europe (ex. en 2004, Philip Moris a été condamné à une amende de 2,75 M $ à la suite de la perte d’e-mails nécessaires dans le cadre d’un procès –source– ; Qualcomm Attorneys a été condamné en 2008 à une amende de 8 M $ pour des raisons similaires –source).

Utilité ?

Les Européens sont concernés par l’e-discovery en cas de litige devant les tribunaux anglais ou américains, en ce compris s’il s’agit de sous-traitance.

Dans la négative, il peut être utile s’il existe un besoin de pouvoir retrouver tout type de preuve très rapidement et de manière exhaustive. Dans le cas contraire, n’hésitez pas à poser un regard critique sur le discours des fournisseurs de logiciels qui utilisent souvent l’e-discovery comme argument de marketing.

Par ailleurs, il faut encore examiner dans quelle mesure les documents pourront être retenus comme preuve devant les tribunaux. Pour ce faire, certaines règles belges et/ou européennes en matière de recevabilité de la preuve devront être respectés.

]]> Apache Solr https://www.smalsresearch.be/apache-solr/ Fri, 23 Jul 2010 09:08:50 +0000 http://blogs.smals-mvm.be/research/?p=1298 In de wereld van content management duikt meer en meer de naam op van Apache Solr als het op zoekfunctionaliteit aankomt.

Apache Solr is een zoekplatform dat deel uitmaakt van het Apache Lucene project. Lucene is een bekende softwarebibliotheek met uitgebreide functionaliteit voor de bouw van een eigen zoekmotor. Binnen Smals zijn er een aantal projecten die ervan gebruik maken. Lucene vervult twee nodige functionaliteiten van een zoekoplossing, namelijk het opbouwen van de index en het ondervragen ervan. Rond deze kernfunctionaliteiten werd een server gebouwd, Solr genaamd, die uitgebreider is qua functionaliteit dan enkel Lucene. Net zoals Lucene is Solr een oplossing gericht op developers.

Het werd dus tijd om deze open source oplossing eens van naderbij te bekijken. Hiervoor werd het product onderworpen aan een klein aantal tests.

Solr is Java-gebaseerd en maakt gebruik van een applicatieserver (Tomcat, Jboss, Jetty, WebLogic…). De interface met  Solr is echter programmeertaal-agnostisch, namelijk steunend op XML/JSON en HTTP. Dit maakt dat bijvoorbeeld ook PHP-oplossingen zoals Drupal ervan kunnen gebruik maken.

Deze oplossing biedt ondermeer:

  • configuratie via XML-bestanden
  • flexibel schema met heel wat configuratiemogelijkheden.
  • tekstanalyse afhankelijk van gedefinieerde veldtypes
  • Java API (SolrJ)
  • tools voor de conversie van documenten (MS Office, PDF, OpenOffice, …) naar het Solr-formaat (gebaseerd op Apache Tika)
  • Geavanceerde functionaliteit zoals facetten, highlighting, spellingscontrole (“bedoel je <dit woord>?”), gewogen queries, …
  • Schaalbare oplossing die gespreid kan worden over meerdere servers
  • Administratieinterface met mogelijkheden van debugging

Als serveroplossing biedt Solr het voordeel dat dit de basis kan vormen van een centrale zoekinfrastructuur die door één team kan beheerd worden. Dit in tegenstelling tot Lucene-implementaties die steeds specifiek per project worden gehanteerd.

Solr is (nog) niet vergelijkbaar met commerciële zoekoplossingen die out-of-the-box een reeks connectoren bezitten naar heel wat content management systemen. Met het Lucene Connectors Framework wenst men hieraan te verhelpen, zij het dat project nog in zijn kinderschoenen staat.

Uiteraard dien je in Solr nog heel wat werk zelf te doen zoals het indexeren van de documenten (die in een correct formaat moeten zijn), keuzes maken voor de tekstanalyse, bouwen van de zoekschermen, …

Daar staat dan tegenover dat Solr wel heel wat van de nodige functionaliteit in huis heeft en dus zeker de moeite waard is om te bekijken. Misschien kan dit het begin zijn voor een dienstenaanbod rond zoektechnologie?

]]>