Założenia

Założenia projektu były dość proste – aplikacja korzystająca z Solr miała móc wyszukiwać zdjęcia po tytule, autorze i innych danych zawartych w EXIF, takich jak przesłona, czas naświetlania, ogniskowa czy wartość ISO. Kolejnym założeniem było to, iż to Solr musi sobie poradzić z wyodrębnieniem tych danych z plików, które dostaje do indeksowania. To tyle jeżeli chodzi o założenia dotyczące wyszukiwania zdjęć.

Struktura indeksu

Struktura indeksu była bardzo prosta i zawierała jedynie najbardziej niezbędne pola. Sama definicja pól wygląda następująco:

<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="name" type="text" indexed="true" stored="true" />
<field name="author" type="text" indexed="true" stored="true" />
<field name="iso" type="text" indexed="true" stored="true" multiValued="true" />
<field name="iso_string" type="text" indexed="true" stored="true" multiValued="true" />
<field name="aperture" type="double" indexed="true" stored="true" />
<field name="exposure" type="string" indexed="true" stored="true" />
<field name="exposure_time" type="double" indexed="true" stored="true" />
<field name="focal" type="string" indexed="true" stored="true" />
<field name="focal_35" type="string" indexed="true" stored="true" />
<dynamicField name="ignored_*" type="string" indexed="false" stored="false" multiValued="true" />

Pole dynamiczne zostało wprowadzone po to, aby umożliwić ignorowanie danych, które nas nie interesują. Dodatkowo, obecny był copyField kopiujący wartość z pola iso do pola iso_string.

Konfiguracja Solr

Poniżej przedstawiona została konfiguracja handlera w pliku solrconfig.xml:

<requestHandler name="/update/extract" class="solr.extraction.ExtractingRequestHandler">
 <lst name="defaults">
  <str name="uprefix">ignored_</str>
  <str name="lowernames">true</str>
  <str name="captureAttr">true</str>
  <str name="fmap.stream_name">name</str>
  <str name="fmap.artist">author</str>
  <str name="fmap.exif_isospeedratings">iso</str>
  <str name="fmap.exif_fnumber">aperture</str>
  <str name="fmap.exposure_time">exposure</str>
  <str name="fmap.exif_exposuretime">exposure_time</str>
  <str name="fmap.focal_length">focal</str>
  <str name="fmap.focal_length_35">focal_35</str>
 </lst>
</requestHandler>

Kilka słów wyjaśnienia konfiguracji. Parametr uprefix mówi o tym, jaki przedrostek nadać nazwom pól, które nie zostały wymienione w konfiguracji. W przypadku powyższej konfiguracji nazwy pól, które nie zostały wymienione zostaną poprzedzone słowem ignored_. Oznacza, to, że trafią do pola dynamicznego (patrz struktura indeksu) i nie zostaną zaindeksowane (stored=”false” oraz indexed=”false”). Parametr lowernames z wartością true powoduje sprowadzanie nazw pól do małych liter. Parametr captureAttr mówi natomiast o tym, iż mają być pobierane atrybuty pliku. Następne parametry to mapowanie pól zwracanych przez bibliotekę Tika do pól w indeksie. Np. parametr fmap.exif_fnumber o wartości aperture mówi o tym, żeby dane z atrybutu exif_fnumber zostały zapisane w polu aperture w indeksie.

Dodatkowe, potrzebne biblioteki

Aby powyższa zmiana zaczęła działać potrzebujemy jeszcze dodatkowych bibliotek (podobnie, jak w przypadku identyfikacji języka). Z katalogu dist, który znajduje się w dystrybucji Solr kopiujemy plik apache-solr-cell-3.5.0.jar do np. katalogu tikaDir, który tworzymy na tym samym poziomie co katalog webapps w Solr. Oraz dodajemy następującą linię do pliku solrconfig.xml:

<lib dir="../tikaLib/" />

Powyższa linia mówi Solr, aby wczytał wszystkie biblioteki z podanego katalogu. Następnie kopiujemy wszystkie biblioteki z katalogu contrib/extraction/ (także z dystrybucji Solr) do poprzednio stworzonego katalogu tikaDir. Dodatkowe zmiany w pliku solrconfig.xml nie są już potrzebne.

Indeksowanie danych

Przyrost zdjęć, których meta dane należało zaindeksować, wynosił około 10 tysięcy tygodniowo. Zdjęcia były składowane we współdzielonej lokalizacji. Wybieraniem zdjęć do indeksowania zajmował się prosty skrypt powłoki, który dla każdego pliku, który został zakwalifikowany, jako nowy, uruchamiał następujące polecenie:

curl 'http://solrmaster:8983/solr/photos/update/extract?literal.id=9926&commit=true" -F "myfile=@Wisła_2011_10_10.JPG"

Powyższe polecenie wysyła plik o nazwie Wisła_2011_10_10.JPG do handlera /extract i mówi aby wywołać polecenie commit po jego przetworzeniu. Do tego ustawiony zostaje unikalny klucz dla dokumentu (parametr literal.id), który powstanie po przetworzeniu wysyłanego pliku.

Zapytania

Oprócz standardowego filtrowania po autorze,  czy innych atrybutach zdjęcia wymaganie odnośnie wyszukiwania było jedno – ma działać. Stwierdziliśmy, że jeżeli sami mielibyśmy korzystać z powstającej aplikacji, na pewno ważnymi polami byłby autor oraz nazwa pliku. Zapytania, które odpowiadały temu wymaganiu wyglądały mniej więcej, tak jak to poniższe:

q=jan+kowalski+wisła&qf=name^100+author^1000+iso+aperture+exposure_time+focal&defType=dismax

Jak widać zapytanie jest bardzo proste. Dwa pola, spośród obecnych w indeksie są promowane – nazwa zdjęcia oraz jego autor. Znaczenie tych pól zostało określone poprzez dodanie odpowiednich podbić na etapie zapytania. Reszcie przeszukiwanych pól nie określono podbicia, a zatem jego wartość wyniosła 1.

Podsumowując

Opisanie powyżej wdrożenie jest dość proste. Sama aplikacja działa i ma się dobrze, jak również działa wyszukiwanie. Następnymi krokami, jakie należałoby uczynić w przypadku aplikacji, która byłaby wykorzystywana w większym gronie użytkowników, to m.in. tunning JVM i samego Solr. Jednym z elementów poprawiania działania Solr byłoby na pewno strojenie jakości wyników wyszukiwania i wydajności samego rozwiązania. Ale to zostanie opisanie w przyszłości.

Na początek

Należy pamiętać, iż opisywana funkcjonalność została wprowadzona w Solr w wersji 3.5.

Założenia

Język będziemy wykrywać na postawie dwóch pól: title oraz body. Chcemy, aby wykryty język został zapisany w polu o nazwie lang.

Struktura naszego indeksu

Struktura indeksu jest oczywiście mocno uproszczona i zawiera jedynie pola potrzebne do testu. Sama definicja pól wygląda następująco:

<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="title" type="text_ws" indexed="true" stored="true" />
<field name="body" type="text_ws" indexed="true" stored="true" />
<field name="lang" type="string" indexed="true" stored="true" />

Wszystkie pola oznaczone są jako stored=”true”, aby zobaczyć wynik przetwarzania dokumentu przez procesor.

Konfiguracja update request processor’a

Aby móc wykorzystać funkcjonalność identyfikacji języka dokumentu konieczna jest konfiguacja następujących procesora aktualizacji. Skorzystamy z procesora opartego o Apache Tika (choć istnieje także druga implementacja oparta o http://code.google.com/p/language-detection/).  W tym celu dodajemy następujący update request processor do pliku solrconfig.xml:

<updateRequestProcessorChain name="langid">
  <processor name="langid" class="org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory">
    <lst name="defaults">
      <str name="langid.fl">title,body</str>
      <str name="langid.langField">lang</str>
    </lst>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

Inne parametry TikaLanguageIdentifierUpdateProcessorFactory opisane są na wiki Apache Solr pod adresem: http://wiki.apache.org/solr/LanguageDetection.

Dodatkowe, potrzebne biblioteki

Aby powyższa zmiana zaczęła działać potrzebujemy jeszcze dodatkowych bibliotek, a dokładniej jednej biblioteki. Z katalogu dist, który znajduje się w dystrybucji Solr kopiujemy plik apache-solr-langid-3.5.0.jar do np. katalogu tikaDir, który tworzyny na tym samym poziomie co katalog webapps w Solr. Oraz dodajemy następującą linię do pliku solrconfig.xml:

<lib dir="../tikaLib/" regex="apache-solr-langid-\d.*\.jar" />

Następna biblioteka, której potrzebujemy to Tika wraz z przyległościami (tika-app-1.0.jar) dostępna np. pod adresem: http://tika.apache.org/. Po skopiowaniu do katalogu tikaDir dodajemy następujący wpis do pliku solrconfig.xml:

<lib dir="../tikaLib/" regex="tika-app-1.0.jar" />

Testowe dokumenty

Do testów przygotowałem trzy dokumenty zawierające po jednym dokumencie w języku angielskim, polskim oraz niemieckim. Ich treść została pobrana z Wikipedii. Wyglądają następująco:

tika_en.xml

<add>
<doc>
  <field name="id">1</field>
  <field name="title">Water</field>
  <field name="body">Water is a chemical substance with the chemical formula H2O. A water molecule contains one oxygen and two hydrogen atoms connected by covalent bonds. Water is a liquid at ambient conditions, but it often co-exists on Earth with its solid state, ice, and gaseous state (water vapor or steam). Water also exists in a liquid crystal state near hydrophilic surfaces.[1][2] Under nomenclature used to name chemical compounds, Dihydrogen monoxide is the scientific name for water, though it is almost never used.</field>
</doc>
</add>

tika_pl.xml

<add>
<doc>
  <field name="id">2</field>
  <field name="title">Woda</field>
  <field name="body">Woda (tlenek wodoru; nazwa systematyczna IUPAC: oksydan) – związek chemiczny o wzorze H2O, występujący w warunkach standardowych w stanie ciekłym. W stanie gazowym wodę określa się mianem pary wodnej, a w stałym stanie skupienia – lodem. Słowo woda jako nazwa związku chemicznego może się odnosić do każdego stanu skupienia.</field>
</doc>
</add>

tika_de.xml

<add>
<doc>
  <field name="id">3</field>
  <field name="title">Wasser</field>
  <field name="body">Wasser (H2O) ist eine chemische Verbindung aus den Elementen Sauerstoff (O) und Wasserstoff (H). Wasser ist die einzige chemische Verbindung auf der Erde, die in der Natur in allen drei Aggregatzuständen vorkommt. Die Bezeichnung Wasser wird dabei besonders für den flüssigen Aggregatzustand verwendet. Im festen (gefrorenen) Zustand spricht man von Eis, im gasförmigen Zustand von Wasserdampf.</field>
</doc>
</add>

Testowanie działania

Aby zaindeksować dane wywołałem następującą serię poleceń:

curl 'http://localhost:8983/solr/update?update.chain=langid' --data-binary @tika_pl.xml -H 'Content-type:application/xml'
curl 'http://localhost:8983/solr/update?update.chain=langid' --data-binary @tika_en.xml -H 'Content-type:application/xml'
curl 'http://localhost:8983/solr/update?update.chain=langid' --data-binary @tika_de.xml -H 'Content-type:application/xml'
curl 'http://localhost:8983/solr/update?update.chain=langid' --data-binary '<commit/>' -H 'Content-type:application/xml'

Warto zauważyć, dodatkowy parameter update.chain=langid dodawany do requestu. Określna on update processor jaki powinien zostać użyty do przetwarzania danych. W tym wypadku chcemy, aby był to nasz zdefiniowany update processor.

Zaindeksowane dane

Sprawdźmy zatem co zostało zaindeksowane. Zróbmy to poprzez wysłanie następującego zapytania: q=*:*&indent=true.

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="indent">true</str>
    <str name="q">*:*</str>
  </lst>
</lst>
<result name="response" numFound="3" start="0">
  <doc>
    <str name="body">Woda (tlenek wodoru; nazwa systematyczna IUPAC: oksydan) – związek chemiczny o wzorze H2O, występujący w warunkach standardowych w stanie ciekłym. W stanie gazowym wodę określa się mianem pary wodnej, a w stałym stanie skupienia – lodem. Słowo woda jako nazwa związku chemicznego może się odnosić do każdego stanu skupienia.</str>
    <str name="id">2</str>
    <str name="lang">pl</str>
    <str name="title">Woda</str>
  </doc>
  <doc>
    <str name="body">Water is a chemical substance with the chemical formula H2O. A water molecule contains one oxygen and two hydrogen atoms connected by covalent bonds. Water is a liquid at ambient conditions, but it often co-exists on Earth with its solid state, ice, and gaseous state (water vapor or steam). Water also exists in a liquid crystal state near hydrophilic surfaces.[1][2] Under nomenclature used to name chemical compounds, Dihydrogen monoxide is the scientific name for water, though it is almost never used.</str>
    <str name="id">1</str>
    <str name="lang">en</str>
    <str name="title">Water</str>
  </doc>
  <doc>
    <str name="body">Wasser (H2O) ist eine chemische Verbindung aus den Elementen Sauerstoff (O) und Wasserstoff (H). Wasser ist die einzige chemische Verbindung auf der Erde, die in der Natur in allen drei Aggregatzuständen vorkommt. Die Bezeichnung Wasser wird dabei besonders für den flüssigen Aggregatzustand verwendet. Im festen (gefrorenen) Zustand spricht man von Eis, im gasförmigen Zustand von Wasserdampf.</str>
    <str name="id">3</str>
    <str name="lang">de</str>
    <str name="title">Wasser</str>
  </doc>
</result>
</response>

Jak widać, Solr przy pomocy biblioteki Tika, był w stanie poprawnie określić język trzech dokumentów jakie wysłaliśmy do indeksowania. Oczywiście, nie cieszmy się zbyt wcześnie, ponieważ pomyłki będą się zdarzać, szczególnie w przypadku, kiedy w ramach jednego dokumentu wykorzystywanych jest wiele języków.

Podsumowanie

Należy pamiętać, iż funkcjonalność detekcji języka dokumentu nie jest idealna i może się mylić. Dodatkowo, im dłuższe dokumenty, tym dokładniej będzie działać opisywana funkcjonalność. Oczywiście problemem jest to, że nie jesteśmy w stanie wykrywać języka podczas wyszukiwania, jednak nie jest to tylko problem Solr. Z tym możemy radzić sobie poprzez identyfikację przeglądarki użytkownika, języka w niej wykorzystywanej, bądź identyfikacji miejsca z którego łączy się do naszej aplikacji.

Sposobów na zaimportowanie danych jest kilka:

• Update Handler
• Cvs Request Handler
• Data Import Handler
• Extracting Request Handler (Solr Cell)
• Skorzystać z bibliotek klienckich (np. Solrj)
• Apache Connectors Framework (dawniej Lucene Connectors Framework)
• Apache nutch

Do tego można jeszcze dodać streaming, jako sposób przesyłania danych. Jak widać, panuje tutaj pewne zamieszanie i ciężko na pierwszy rzut oka podać najlepszą metodę do zastosowania w konkretnym wypadku.

Update Handler

Chyba najbardziej popularna metoda, ze względu na prostotę. Wymaga przygotowania odpowiedniego XML oraz przesłanie go poprzez HTTP do serwera Solr. Umożliwia podbijanie ważności dokumentów i pojedynczych pól.

CSV Request Handler

W przypadku, gdy dane wejściowe mamy w postaci CSV (Coma Separated Values) lub TSV (Tab Separated Values) ta opcja może być najwygodniejsza. Niestety, w przeciwieństwie do Update Handler, nie ma możliwości podbijania ważności.

Data Import Handler

Ta metoda jest mniej popularna, wymaga dodatkowej, czasem dość skomplikowanej konfiguracji, jednak pozwala na bezpośrednie podpięcie się do źródła danych. Dzięki temu nie wymaga żadnych dodatkowych skryptów eksportujących dane ze źródła i konwertujących je na format wymagany przez Solr. Standardowo jest dostępna integracja z bazami danych (w oparciu o JDBC), źródłami udostępniającymi XML (np. RSS), email (poprzez protokół IMAP), dokumenty obsługiwane przez projekt apache Tika (np. Openoffice, word, rtf, html i wiele innych). Dodatkowo można dopisywać własne źródła i transformacje.

Extracting Request Handler (Solr Cell)

Wyspecjalizowany handler do indeksowania treści dokumentów przechowywanych w plikach o różnych formatach. Lista obsługiwanych formatów jest dość szeroka a do indeksowania wykorzystywany jest projekt apache Tika. Wadą tego rozwiązania jest konieczność budowania dodatkowych rozwiązań dostarczających do SOLR namiary na dokument i informacje o identyfikatorze dokumentu oraz brak możliwości uzupełniania dokumentów o dodatkowe, zewnętrzne względem dokumentu, metadane.

Biblioteki klienckie

Solr udostępnia biblioteki klienckie do wielu języków programowania. Ich możliwości różnią się miedzy sobą, natomiast w przypadku, gdy dane są generowane na bieżąco przez aplikację i czas, po którym te dane muszą być dostępne do wyszukiwania jest bardzo mały, indeksowanie w ten sposób często jest jedyną dostępną opcją.

Apache Connectors Framework

ACF jest to relatywnie nowy projekt, który szerszej publiczności objawił się na początku 2010 roku. Projekt początkowo był wewnętrznym projektem prowadzonym przez firmę MetaCarta, został przekazany społeczności open source i w chwili obecnej rozwijany w ramach inkubatora apache. W założeniu jest to system, który dzięki szeregowi wtyczek pozwala „wyklikać” połączenie ze źródłem danych. W chwili obecnej brak jest opublikowanych wersji, ale sam system już warty jest zainteresowania w przypadku konieczności integracji z takimi systemami jak: FileNet P8 (IBM), Documentum (EMC), LiveLink (OpenText), Patriarch (Memex), Meridio (Autonomy), Windows shares (Microsoft) i SharePoint (Microsoft).

Apache nutch

Nutch to zasadzie to oddzielny projekt prowadzony przez Apache (wcześniej w ramach Apache Lucene). Dla osoby zajmującej się serwerem Solr jest on o tyle ciekawy, że pozwala na taką konfigurację, która umożliwia pobieranie stron WWW i indeksowanie ich poprzez Solr.

Słowo o streamingu

Streaming oznacza możliwość powiadomienia Solr,  skąd pobrać dane do zindeksowania. Pozwala to na uniknięcie zbędnego przesyłania danych przez sieć, jeśli dane znajdują się na zasobie lokalnym względem serwera indeksującego, lub podwójnego przesyłania danych (ze źródła do importera, z importera do Solra).

I słowo o bezpieczeństwie

Solr z założenia jest przewidziany do stosowania w architekturze zakładającej pracę w środowisku bezpiecznym. Bardzo ważne jest jednak zwrócenie uwagi na to, kto i jakie polecenia jest w stanie wykonywać. O ile zwracane dane można w miarę prosto ograniczyć, poprzez wymuszenie stosowania filtrów w definicji handlerów, o tyle w przypadku indeksowania nie jest to już takie proste. W szczególności niebezpieczny wydaje się być Solr Cell – nie tylko pozwoli na odczytanie dowolnego pliku, do którego ma dostęp Solr (np. pliki z hasłami), ale dodatkowo da możliwość atakującemu na ich wygodne przeszukiwanie w celu uzyskania przydatnych informacji

Inne opcje

Powyżej starałem się uwzględnić opcje, które nie wymagają dodatkowej pracy. Problemem może być definicja tej dodatkowej pracy, bo czasem łatwiej napisać dodatkową wtyczkę, niż przebijać się przez niezliczone opcje konfiguracyjne czy tworzyć gigantyczne XMLe. Dlatego też w wyborze metod kierowałem się własnym wyczuciem, co skutkowało pominięciem kilku sposobów (np. pobieranie danych ze stron WWW za pomocą Apache Droids lub Heritrixa, czy rozwiązania oparte o Open Pipeline lub Open Pipe).

Na pewno w tym krótkim artykule udało mi się pominąć jakieś ciekawe sposoby. Jeśli tak, proszę o komentarze, chętnie uaktualnię ten wpis

Konferencja została przez organizatorów podzielona na dwie części: treningową oraz typowo konferencyjną. O części treningowej nie napiszę wiele, ze względu na to, że nie uczestniczyliśmy w tej części konferencji. Treningi były prowadzone przez dwóch commiterów projektu Lucene/Solr: Erik`a Hatcher`a oraz Grant`a Ingersoll. Więcej informacji dotyczących tematów, jakie były poruszane w tej części konferencji można znaleźć pod adresem http://lucene-eurocon.org/training.html.

Początek

Właściwa konferencja zaczęła się w czwartek, 20 maja, od powitania, a następnie dwóch prezentacji: „The Search Revolution – How Lucene & Solr Are Changing the World” poprowadzonej przez CEO Lucid Imagination – Eric`a Gries (slajdy) oraz „From Publisher To Platform: How The Guardian Used Content, Search, and Open Source To Build a Powerful New Business Model” (slajdy) prezentowanej przez Stephen`a Dunn, stojącego na czele działu strategii i technologii w wydawnictwie The Guardian. Eric Gries w swojej prezentacji skupił się na rosnącym zapotrzebowaniu na przetwarzanie informacji, ich wyszukiwanie oraz oczywiście projektach Lucene i Solr, które w obu tych przypadkach sprawdzają się znakomicie. Oczywiście nie zabrakło także informacji o rosnącym zainteresowaniu na rynku pracy osobami, które posiadają wiedzę na temat wspomnianych projektów. Nie mógłbym nie wspomnieć, iż zazdroszczę umiejętności zainteresowania słuchaczy i takiego prowadzenia prezentacji. Chylę czoła. Natomiast druga z prezentacji, prowadzona przez Stephen`a Dunn to omówienie nowej platformy developerskiej wydawnictwa The Guardian nazwanej przez twórców „The Open Platform” pozwalającej na dostęp do bazy artykułów wydawnictwa The Guardian od 1991 rok, która w tym momencie składa się z około miliona dokumentów i ciągle rośnie. Autor skupił na opisie technicznych szczegółów związanych z implementacją w oparciu o silnik wyszukiwania Solr oraz na tym, co zyskują developerzy korzystając z platformy wydawnictwa.

Następnie konferencja podzieliła się na dwa tory. Ze względu na to, że fizyczna obecność możliwa była tylko na jednej z dwóch prezentacji, będę opisywał tylko te prezentacje na których byłem obecny. Dla ścisłości – pełna agenda dostępna jest pod adresem http://lucene-eurocon.org/agenda.html.

Tika i przyszłość Lucene

Dwie pierwsze prezentacje upłynęły pod znakiem „pierwszej ścieżki„. Na początek, trochę ciekawych, czasem szczegółowych informacji o produkcie jakim jest Tika w prezentacji „Text and Metadata Extraction with Apache Tika” (slajdy) prowadzonej przez Jukka Zittinga. Trochę informacji ogólnych, założeń oraz rys historyczny powstania projektu. Następnie informacje stricte techniczne włącznie z fragmentami kodu i pokazaniem jak można wykorzystać framework. Ogólnie dobra prezentacja, której słuchało się z punktu widzenia programisty, bardzo fajnie. Brak przerwy i od razu druga prezentacja, prowadzona przez Uwe Schindler`a oraz Simona Willnauer`a, pod intrygującym tytułem „Lucene Forecast: Version, Unicode, Flex and Modules” (slajdy). Z mojego, skromnego punktu widzenia, podczas tej prezentacji otrzymałem ogrom informacji dotyczących przyszłości zarówno Lucene, jak i Solr. Prezentacja zaczęła się tak naprawdę od wyjaśnienia czego dotyczyły ostatnie ruchy w projektach Lucene i Solr, czyli tak naprawdę połączenia developmentu obu projektów, połączenia gron`a commiterów oraz zmiana trybu tworzenia nowych wersji, przynajmniej jeżeli chodzi o Lucene – mówiąc bardzo krótko, od teraz trunk repozytorium Lucene i Solr odpowiada za przechowywanie rozwojowej wersji projektów (w tym momencie jest to wersja 4.0) oraz to, że wersja 4.0 biblioteki nie będzie wstecznie kompatybilna z poprzednimi wersjami Lucene. Oznacza to również to, iż produkty odparte o Lucene w wersji 3 będą musiały zostać przepisane, ze względu na zmianę API. Dalsze informacje przekazane przez prowadzących były nie mniej ciekawe – np. plany dodania mechanizmu facetingu znanego z Solr do Lucene. Sporo czasu poświęcono także omówieniu zmian związanych z pełną obsługą Unicode (moduł ICU Lucene) po czym prowadzący przeszli do bardzo ciekawego według mnie tematu, czyli Flexible Indexing. Jednak rozwinięcie tego tematu, jak również dużo więcej informacji o pakiecie ICU w Lucene w kolejnym wpisie.

W czasie trwania dwóch wspomnianych prezentacji, na „drugiej ścieżce” trwały dwie inne prezentacje. Poniżej ich tytuły wraz ze slajdami dla osób zainteresowanych. Niestety ze względu na to, że w nich nie uczestniczyłem, nie jestem w stanie powiedzieć na ich temat nic więcej:

• „Use of Solr at Trovit, A Leading Search Engine For Classified Ads” prowadzona przez Marc`a Sturlese (slajdy).
• „Implementing Solr in Online Media As An Alternative to Commercial Search Products” prowadzona przez Bo Raun`a (slajdy).

Magia post-procesingu

Po obiedzie i przerwie zdecydowałem się nie zmieniać ścieżki i obejrzeć prezentację Andrzeja Białeckiego pod tytułem „Munching and Crunching: Lucene Index Post-processing” (slajdy) i decyzja ta okazała się strzałem w przysłowiową dziesiątkę. Postanowiłem, że w tym momencie wspomnę tylko o czym była prezentacja, ponieważ było w niej tyle ważnych, moim zdaniem informacji, iż nie napisanie oddzielnego tekstu na ten temat będzie grzechem. Przedstawione informacje to głównie możliwości rozdzielania indeksu, czyszczenie, filtrowanie, czyli przechowywanie indeksu w pamięci RAM. Jak już pisałem, więcej na ten temat w oddzielnym wpisie. W tym samym czasie w „ścieżce drugiej” odbywała się prezentacja pod tytułem „Bringing Solr to Drupal: A General, and a Library-Specifix Use Case” prowadzona przez Peter`a Kiraly (slajdy).

Solr i NLP

Kolejną prezentację „pierwszej ścieżki” pod tytułem „Solr Schema Demystified” prowadzoną przez Uri Boness`a postanowiłem opuścić na rzecz „Integration of Natural Language Processing tools with Solr” prowadzoną przez Joan`a Codina-Filbà (slajdy). Prezentacja ciekawa dla osób starających się zintegrować Solr z narzędziami analizy językowej – zapisywać wyniki zwracane przez te narzędzia i je wykorzystywać. Przedstawionych zostało trochę informacji na temat wykorzystania UIMA, problemów na jakie natrafili programiści oraz w jaki sposób zostały rozwiązane oraz jak wyglądała kategoryzacja wyników przy użyciu Carrot2. Prezentujący pokazywał także różnice pomiędzy lametem, a wynikiem stemmingu, jak rozpoznawano części mowy oraz w jaki sposób zostało to wykorzystane do klasyfikacji, czy komentarz o danym produkcie miał pozytywny, czy negatywny wydźwięk. Wszystko to w kontekście Lucene/Solr oraz rozwiązania wykorzystującego payload`y, jak również bez ich wykorzystania. Szkoda, tylko, że całość została omówiona w kontekście języka hiszpańskiego, ale cóż, nie można mieć wszystkiego

Przetwarzanie dokumentów

Ze względu na to, iż na początku dnia usłyszałem co nieco o „The Open Platform” wydawnictwa The Guardian, postanowiłem odpuścić sobie prezentację pod tytułem „Solr in the Wild: The Guardian Open Platform Content API” prowadzoną przez Graham`a Tackley (slajdy) i zamiast niej posłuchać co ma do powiedzenia Max Charas oraz Karl Jansson, czyli prelegenci „Modular Document Processing for Solr/Lucene” (slajdy). Prezentacja, moim zdaniem, była bardziej pokazaniem możliwości produktów kilku sponsorów konferencji, niż czymś mocno odkrywczym, szczególnie patrząc na poziom niektórych, wcześniejszych prezentacji. Prawdę powiedziawszy, trochę wynudziłem się podczas słuchania tej prezentacji, ale może było to wynikiem przeładowania informacjami i ogólnego zmęczenia.

Wykorzystanie Solr w IBM

Po kolejnej krótkiej przerwie rozpoczęły się kolejne dwie prezentacje. Mając do wyboru „Make Your Domain Object Searchable with Hibernate Search” (slajdy) prowadzoną przez Gustavo Fernandes`a oraz „Social and Network Discovery (SaND) over Lucene” (slajdy) prowadzoną przez Shai Erera wybrałem tą drugą. W skrócie, prezentacja dotyczyła aplikacji stworzonej w firmie IBM na potrzeby przeszukiwania dokumentów, ludzi, stron itd, stworzonych wewnątrz wymienionej firmy. Prezentujący pokazał w jaki sposób zostało zaimplementowane wyszukiwanie (co i jak możemy wyszukiwać), jak działa zawężanie wyników (faceting, zawężanie oparte o datę, lokalizację, czy źródło pochodzenia informacji), czy prezentacja relacji pomiędzy osobami, czy dokumentami. Oprócz samego wyszukiwania SaND całkiem ciekawą funkcjonalność – a mianowicie graf relacji pomiędzy znalezionymi osobami/dokumentami/stronami (slajd 25 pokazuje graf zależności pomiędzy osobami). Prezentacja całkiem ciekawa, aczkolwiek przeprowadzona według mnie chaotycznie, co zakłóciło w pewnym stopniu odbiór informacji.

Migracja z FAST do Solr

Będąc już zmęczonym wybrałem ostatnią prezentację tego dnia, czyli „Key Topics When Migrating From FAST to Solr” (slajdy) prowadzoną przez Jana Høydahl na rzecz prezentacji „Query by Document: When „More Like This” Is Insufficient” (slajdy) prezentowaną przez Dusan`a Omercevic`a. Ciekawie było posłuchać o niektórych rozwiązaniach, jakie zostały zaimplementowane w FAST, a nie ma ich w Solr oraz jak sobie radzić w przypadku migracji. Jan Høydahl mówił całkiem ciekawie, pokazał różnice pomiędzy obiema technologiami oraz w jaki sposób można radzić sobie przypadku braków niektórych funkcjonalności, zarówno z jednej, jak i z drugiej strony. Co ciekawe, dla osoby, która nie miała doświadczenia komercyjnego z FAST, interesująca sprawa, to informacja, iż większość obróbki danych przygotowywana jest w FAST na etapie indeksowania – na przykład sortowanie musi być zdefiniowane na etapie indeksowania. Patrząc na FAST widać, czego jeszcze brakuje w Solr – na przykład pól wielojęzykowych, czy pipeline zintegrowany z silnikiem wyszukiwania. Następnie pokazany został przykładowy proces migracji z FAST do Solr, oczywiście mocno uproszczony, ale pokazujący, jak można ten proces wykonać. Ogólnie, bardzo fajna prezentacja.

Koniec pierwszego dnia

Następnie przyszedł czas na 90 minutową przerwę po których odbyło się pięć krótkich prezentacji, już mniej oficjalnych. Ze względu na ich rodzaj, oraz to, że wszyscy byli już bardziej myślami na czeskim festiwalu piwa, na który mieliśmy się udać po prelekcjach jako grupa, postanowiłem, iż tylko je wymienię:

• „Social Media Scheduler based on Solr + Hadoop + Amazon EC2” Pablo Aragón (slajdy)
• „Introduction to Collaborative Filtering using Mahout” Frank Scholten (slajdy)
• „Enterprise Search meets Enterprise CMS – TYPO3 and Apache Solr” Olivier Dobberkau (slajdy)
• „BM25 Scoring for Lucene” Yuval Feinstein (slajdy)
• „How We Scaled Solr to 3+ Billion Documents” Jason Rutherglen (slajdy)

Dzień drugi

Drugi dzień konferencji rozpoczął się od krótkiego wstępu poprowadzonego przez Grant`a Ingersoll, po czym rozpoczęła się właściwa część drugiego dnia.

A więc zaczynamy dzień drugi

Tak samo, jak w przypadku dnia poprzedniego, na początek dostaliśmy dwie prezentacje: „Software Disruption: How Open Source, Search, Big Data and Cloud Technology are Disrupting IT” (slajdy) prowadzona przez Zack`a Urlocker`a oraz „Solr 1.5 and Beyond” (slajdy) prowadzona przez Yonik`a Seeley`a. Pierwsza prezentacja, ze względu na swój marketingowy charakter raczej mało mnie interesowała, co nie zmienia faktu, że w jej trakcie przekazane zostały ciekawe informacje na temat rozwoju oprogramowania ze stajni open source. Nie zabrakło również przewidywań na temat kierunków rozwoju oprogramowania i zwrócenia się ku przetwarzaniu w chmurze. Sam prelegent ma na temat open source dużą wiedzę, jako jeden z ojców sukcesu MySQL`a. Druga prezentacja, była z mojego punktu widzenia dużo bardziej ciekawa, ze względu na techniczne zorientowanie. Dotyczyła m.in. kilku kluczowych tematów dla przyszłości Solr – połączenie z Lucene, rozszerzenie parsera dismax, integrację z Zookeeper`em (tzw. Solr Cloud), wyszukiwanie geograficzne, funkcjonalność field collapsing oraz NRE (near real time) search. Warto podkreślić, iż prezentacja była bardzo ciekawa, choć mówiła o kilku rzeczach o których usłyszeliśmy już podczas tej konferencji (m.in. Solr Cloud, czy połączenie developmentów). Moim zdaniem warto mieć na oku zmiany, jakie zachodzą w Solr, ponieważ przyszłość projektu rysuje się bardzo jasnych barwach, jeżeli tylko wszystko o czym była mowa podczas prezentacji uda się zrealizować, a przecież wiemy, że to nie wszystko co ma się znaleźć w przyszłych wersjach Solr.

Grant na temat relevance

I znów konferencja podzieliła się na dwie ścieżki. Wydawało mi się, że więcej zyskam słuchając Grant`a Ingersoll mówiącego o „Practical Relevance” (slajdy), niż Steve`a Kearns prezentującego „Building Multilingual Search Based Application” (slajdy). Moim zdaniem się nie pomyliłem. Grant mówił o ogólnie rozumianym poprawianiu jakości wyników wyszukiwania – w jaki sposób można to robić, czy analizować logi i jak to robić, co można wyciągnąć ze statystyk związanych z wyszukiwaniem i na czym należy się skupić podczas procesu poprawiania jakości. Wspominał o konieczności zbierania informacji od użytkowników, bo to oni docelowo zdecydują o sukcesie, bądź porażce aplikacji. Nie zabrakło również informacji, jak szybko zyskać zadowalające efekty dodając premiowanie dokumentów zawierających frazy składających się z wielu słów. Zbliżając się do końca prezentacji, Grant, mówił o zaawansowanych metodach wpływania na tzw. relevance, czyli o developmencie własnych komponentów odpowiedzialnych za liczenie ważności dokumentów, wspomniał także o projekcie Open Relevance będącym jednym z projektów zawartych w ekosystemie Lucene.

Lucene Connectors Framework

Następnie zdecydowałem się zostać w tej samej sali konferencyjnej i posłuchać Karl`a Wright, który mówił na temat Lucene Connectors Framework w prezentacji pod tytułem „Lucene Connectors Framework: An Introduction” (slajdy). W tym samym czasie uczestnicy konferencji mogli posłuchać Karel Braeckman i prezentacji pod tytułem „Unlocking a Broadcaster Video Archive Using Solr” (slajdy). Wspomniana prezentacja, to tak naprawdę głównie przedstawienie części framework`a, jego założeń oraz architektury. Dowiedzieliśmy się, że sam framework jest obecnie w trakcie migracji z postaci komercyjnej do postaci open source, dlatego w tym momencie dużo funkcjonalności może nie działać, ponieważ część z nich była oparta o komercyjne biblioteki, które z wiadomych przyczyn nie mogą zostać wykorzystane w projekcie open source. O ile sam framework będzie na pewno ciekawym i przydatnym narzędziem uzupełniającym Solr i Lucene o możliwości takie jak odczyt różnych źródeł danych (zarówno metodą PULL, jak i PUSH), możliwość dostarczania danych periodycznie, czy kompleksowy model bezpieczeństwa, to jednak w tym momencie kod średnio nadaje się do wykorzystania we własnej aplikacji i moim zdaniem, w tym momencie, należy traktować framework jak ciekawostkę – miejmy nadzieję, że to się szybko zmieni.

Solr + Zookeeper = Solr Cloud

Po przerwie na lunch i rozmowach z commiterami m.in. projektów Lucene i Solr rozpoczęła się kolejna sesja prezentacji. Wypoczęty i gotowy na słuchanie kolejnych informacji udałem się na prezentację Mark`a Millera pod tytułem „Solr in the Cloud” (slajdy). W sali obok rozpoczynała się w tym samym czasie prezentacja pod tytułem „The Path to Discovery: Facets and the Scent of Information” (slajdy) której prelegentami byli Tyler Tate oraz Stefan Olafsson. Jak można się domyślić tematem przewodnim prezentacji był tzw. Solr Cloud, czyli rozproszona farma instancji Solr zarządzanie tą instalacją przy pomocy Zookeeper`a. Zaczęło się od przedstawienia architektury master – slave oraz jak ta architektura wygląda w przypadku rozproszenia indeksu pomiędzy wiele shardów wraz z „rysem historycznym”, czyli wspomnieniem o skryptach powłoki i nowej, opartej o język Java replikacji indeksów. Następnie, Mark Miller, przeszedł do opisania głównych założeń, które leżą u podstaw integracji z Zookeeper`em, czyli scentralizowana konfiguracja, fault tolerance, możliwość automatycznego usuwania i dodawania kolejnych instancji Solr, czy wreszcie wsparcie dla sprawdzania dostępności poszczególnych instancji. Omówione zostało co do tej pory zostało zrobione w związku z integracją z Zookeeper`em, co jeszcze na pewno zostało do zrobienia oraz co jest w planach w dalszej przyszłości. Oprócz spraw związanych z zarządzaniem instancjami Mark Miller przedstawił nowość w Solr 1.4, czyli tzw. LoadBalanced Http Solr Server. Podsumowując, prezentacja bardzo ciekawa, pokazująca kolejną ścieżkę rozwoju Solr – jest na co czekać.

Chwila wytchnienia

Podczas, kiedy my rozmawialiśmy z innymi uczestnikami konferencji i nawiązywaliśmy kontakty, trwały dwie kolejne prezentacje:

• „Neural Networks, Newspapers and Solr – A short tour through extending Solr for real-world text-classification” (slajdy) prezentowana przez Sven`a Maurmann`a
• „Rapid Prototyping” (slajdy) prezentowana przez Eric`a Hatcher`a

To już prawie koniec

Ostatnimi prezentacjami, jakie miały być pokazane na konferencji były „Combatting Information Overload – Search in Military Information Gathering Systems” (slajdy), której prelegentem była pani Alexandra Larsson, kapitan szwedzkich sił powietrznych oraz „European Language Analysis with Hunspell” prowadzoną przez Chris`a Male. Po wysłuchaniu części tej drugiej prezentacji zdecydowałem się przejść do przyległej sali konferencyjnej i posłuchać o tym, jak szwedzkie służby wykorzystują Lucene i Solr w swoich systemach analitycznych. Ze względu nie wysłuchanie żadnej z prezentacji od początku do końca postanowiłem nie opisywać żadnej z nich, pomimo tego, że moim zdaniem pani kapitan mówiła o bardzo ciekawym zastosowaniu obu projektów, które to słowa wspomagała przykładami w postaci zrzutów ekranu z aplikacji i tłumaczenia w jaki sposób współgrają ze sobą poszczególne elementy.

Ostatnim akcentem, kończącym Lucene Eurocon 2010, było kilka słów Granta Ingersoll, losowanie wejściówki na Lucene Revolution w Bostonie oraz losowanie kilku egzemplarzy książek, czyli coś dla ludu

Podsumowanie

Podsumowując całe wydarzenie jestem zadowolony z tego, że mogłem w nim uczestniczyć. Ciekawe prezentacje, morze pomysłów i planów oraz upewnienie społeczności w tym, że Lucene i Solr są dojrzałymi produktami, które nie spoczęły na laurach i pomimo rosnącego zainteresowania ich obecnym kształtem mają za sobą ludzi, którzy dbają o to, żeby projekty nie stały w miejscu. Mam nadzieję, że będzie mi dane uczestniczyć w Lucene Eurocon 2011