Krótkie przypomnienie

W artykule SolrCloud – co się dzieje, kiedy ZooKeeper pada? pokazaliśmy, iż w przypadku awarii ZooKeeper’a jesteśmy w stanie bezproblemowo zadawać zapytania i dostawać poprawne wyniki wyszukiwania. Oczywiście jest to prawda do chwili, kiedy nie zmieniamy niczego w topologi klastra. Niestety, w przypadku indeksowania, nie jesteśmy w stanie zmieniać indeksu kiedy SolrCloud nie ma aktywnego połączenia z ZooKeeperem, lub kiedy nie ma quorum. Przyjrzyjmy się zatem dlaczego tak się dzieje.

Dlaczego możemy zadawać zapytania?

Sytuacja jest dość prosta – zadawanie zapytań nie jest operacją zmieniającą stan klastra SolrCloud. Jedyne co Solr musi zrobić, to przyjąć zapytanie i wysłać je do odpowiednich instancji Solr. Oczywiście topologia klastra nie jest odczytywana przy każdym zapytaniu, a w związku z tym nie mając aktywnego połączenia z ZooKeeper’em lub gdy nie ma quorum jesteśmy w stanie bez problemów zadawać zapytania.

Jest jeszcze jedna ciekawa opcja, chociaż dużo osób o tym nie wie – możliwość zwracania tylko częściowych wyników wyszukiwania w momencie, kiedy część kolekcji nie jest dostępna. Dodając parametr shards.tolerant=true do naszych zapytań informujemy Solr, że jesteśmy w stanie żyć w częściowymi wynikami, np. wtedy, gdy część kolekcji jest niedostępna. Domyślnie Solr po prostu zwróci błąd.

Dlaczego nie możemy indeksować danych?

Dlaczego nie możemy indeksować danych, jeżeli nie ma połączenia z ZooKeeper’em lub gdy nie ma quorum? Wszystkiemu winien jest brak wystarczającej ilości informacji, aby indeksacja mogła zostać przeprowadzona poprawnie. Dokładniej – Solr (potencjalnie) nie ma informacji o aktualnym stanie klastra, a co za tym idzie nie jest w stanie poprawnie wyliczyć, gdzie ma zostać umieszczony dokument, czy które core’y, na których instancjach Solr są replikami, a które leaderami kolekcji. Wszystko to powoduje, że indeksacja dokumentów nie jest możliwa.

Generalnie, warto pamiętać, iż operacje wymagające aktualizacji stanu Solr, czy też aktualizacji danych, które znajdują się z ZooKeeper nie będą możliwe do wykonania w wypadku braku kworum ZooKeepera (w naszym wypadku braku pojedynczego serwera ZooKeeper).

Oczywiście poprawność tego co napisaliśmy powyżej bardzo łatwo to sprawdzić i właśnie tym zajmiemy się w dalszej części wpisu.

Uruchamiamy ZooKeepera

Krok bardzo prosty. Do testów wystarczy nam pojedyncza instancja ZooKeepera uruchomiona w następujący sposób:

bin/zkServer.sh start

Na konsoli powinniśmy zobaczyć następujące informacje:

JMX enabled by default
Using config: /Users/gro/Solry/zookeeper/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED

I tym samym mamy działającą instancję ZooKeepera.

Uruchamiamy dwie instancje Solr

Do testów wykorzystaliśmy najnowszą, dostępną wersję Solr 5.2.1. Do uruchomienia dwóch instancji Solr korzystamy z następującego polecenia:

bin/solr start -e cloud -z localhost:2181

Podczas uruchamiania wybieramy, iż chcemy mieć 2 instancje, porty na których będą działać nie są ważne.

Dodatkowo wybraliśmy następujące opcje:

• nazwa kolekcji: gettingstarted
• liczba shardów: 2
• liczba replik: 1
• konfiguracja kolekcji: data_driven_schema_configs

Całość wyglądała mniej, więcej tak:

Dodajemy kilka dokumentów

Żeby sprawdzić, czy Solr na pewno działa dodajmy kilka dokumentów korzystając z następującego polecenia:

bin/post -c gettingstarted docs/

Jeżeli wszystko poszło zgodnie z planem, to na poniższe polecenie:

curl -XGET 'localhost:8983/solr/gettingstarted/select?indent=true&q=*:*&rows=0'

powinniśmy dostać następującą odpowiedź:

<?xml version="1.0" encoding="UTF-8"?>
<response>
 <lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">38</int>
  <lst name="params">
   <str name="q">*:*</str>
   <str name="indent">true</str>
   <str name="rows">0</str>
  </lst>
 </lst>
 <result name="response" numFound="3577" start="0" maxScore="1.0">
 </result>
</response>

Wszystko działa jak należy.

Czas na indeksowanie z wyłączonym Zookeeperem

Zatrzymajmy zatem naszą instancję ZooKeepera poleceniem:

bin/zkServer.sh stop

I spróbujmy jeszcze raz uruchomić następujące polecenie:

bin/post -c gettingstarted docs/

Tym razem, zamiast informacji o tym, że dokumenty są indeksowane powinniśmy widzieć coś w tym stylu:

POSTing file index.html (text/html) to [base]/extract
SimplePostTool: WARNING: Solr returned an error #503 (Service Unavailable) for url: http://localhost:8983/solr/gettingstarted/update/extract?resource.name=%2FUsers%2Fgro%2FSolry%2F5.2.1%2Fdocs%2Findex.html&literal.id=%2FUsers%2Fgro%2FSolry%2F5.2.1%2Fdocs%2Findex.html
SimplePostTool: WARNING: Response: <?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader"><int name="status">503</int><int name="QTime">3</int></lst><lst name="error"><str name="msg">Cannot talk to ZooKeeper - Updates are disabled.</str><int name="code">503</int></lst>
</response>

Jak widać, brak ZooKeepera skutkuje niemożliwością indeksowania. Oczywiście zadawanie zapytań wciąż działa. Ponowne włączenie ZooKeepera i rozpoczęcie indeksowania także będzie skutkowało bezproblemowym indeksowaniem, ze względu na to, że Solr ponownie się z nim połączy.

Krótkie podsumowanie

Oczywiście ten i poprzedni tekst dotykają tylko wierzchołka góry lodowej i pokazuje co się dzieje, gdy brakuje ZooKeepera. Bardzo dobry test dotyczący tego jak SolrCloud zachowuje się nie tylko podczas awarii ZooKeepera, ale także podczas problemów z infrastrukturą sieciową można znaleźć na http://lucidworks.com/blog/call-maybe-solrcloud-jepsen-flaky-networks/. Polecamy wszystkim, którzy mają ochotę dowiedzieć się, jak SolrCloud zachowa się w sytuacjach awaryjnych.

Struktura danych

Struktura danych (sekcja fields pliku schema.xml) wygląda następująco:

<fields>
 <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
 <field name="name" type="text_general" indexed="true" stored="true"/>
 <field name="_version_" type="long" indexed="true" stored="true"/>
</fields>

Dodatkowo w pliku schema.xml definiujemy, które pole będzie przechowywać unikalny identyfikator:

<uniqueKey>id</uniqueKey>

Konfiguracja Solr

Następnie musimy zmodyfikować konfigurację Solr dodając odpowiedni UpdateRequestProcessorChain do pliku solrconfig.xml:

<updateRequestProcessorChain>
 <processor class="solr.UUIDUpdateProcessorFactory">
  <str name="fieldName">id</str>
 </processor>
 <processor class="solr.LogUpdateProcessorFactory" />
 <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

Tym samym informujemy Solr, iż chcemy aby pole id było automatycznie wygenerowane.

Mały test

Przetestujmy to co zrobiliśmy. W tym celu wyślemy jeden dokument do zaindeksowania za pomocą następującego polecenia:

curl -XPOST 'localhost:8983/solr/update?commit=true' --data-binary '<add><doc><field name="name">Test</field></doc></add>' -H 'Content-type:application/xml'

Jeżeli wszystko poszło dobrze dokument został zaindeksowany. W związku z tym sprawdźmy, czy wygenerowany został identyfikator. Robimy to za pomocą następującego polecenia:

curl -XGET 'localhost:8983/solr/select?q=*:*&indent=true'

Odpowiedź na to zapytanie powinna wyglądać mniej, więcej tak:

<?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="1" start="0">
  <doc>
   <str name="name">Test</str>
   <str name="id">1cdee8b4-c42d-4101-8301-4dc350a4d522</str>
   <long name="_version_">1439726523307261952</long>
  </doc>
 </result>
</response>

Jak widać, identyfikator dokumentu został automatycznie wygenerowany. Jeżeli teraz uruchomilibyśmy indeksowanie jeszcze raz, czyli wykonali polecenie:

curl -XPOST 'localhost:8983/solr/update?commit=true' --data-binary '<add><doc><field name="name">Test</field></doc></add>' -H 'Content-type:application/xml'

A następnie znów wykonali zapytanie:

curl -XGET 'localhost:8983/solr/select?q=*:*&indent=true'

W odpowiedzi otrzymalibyśmy dwa dokumenty:

<?xml version="1.0" encoding="UTF-8"?>
<response>
 <lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">1</int>
  <lst name="params">
   <str name="indent">true</str>
   <str name="q">*:*</str>
  </lst>
 </lst>
 <result name="response" numFound="2" start="0">
  <doc>
   <str name="name">Test</str>
   <str name="id">1cdee8b4-c42d-4101-8301-4dc350a4d522</str>
   <long name="_version_">1439726523307261952</long>
  </doc>
  <doc>
   <str name="name">Test</str>
   <str name="id">9bedcb5f-1b71-4ab7-80a9-9882a6bf319e</str>
   <long name="_version_">1439726693819351040</long>
  </doc>
 </result>
</response>

Oba dokumenty mają zupełnie różne identyfikatory, które zostały wygenerowane automatycznie.

Aby odpowiedzieć sobie na pytanie, kiedy należy wysyłać polecenie commit, należy przyjrzeć się kilku różnym wariantom indeksowania danych oraz jak szybko chcemy te dane udostępniać. Przyglądając się typowym wdrożeniom, którymi miałem do czynienia, można wyróżnić następujące kategorie:

Dane mogą być udostępnione jedynie po całkowitej aktualizacji indeksu

Sytuacja teoretycznie i praktycznie bardzo prosta. Commitujemy dopiero kiedy skończą się dokumenty do zaindeksowania.

Dane mogą być udostępniane partiami, bez konieczności czekania na pełną aktualizację indeksu

Tutaj mamy trzy możliwości:

1. Jeżeli nie ma znaczenia czy dane będą udostępnianie partiami, czy nie możemy wysyłać polecenie commit dopiero po przesłaniu ostatniego dokuementu.
2. Jeżeli chcemy udostępniać dane partiami, nasza aplikacja może wysłać polecenie commit co pewien czas.
3. Jeżeli nie chcemy wysyłać polecenia commit z aplikacji, możemy powiedzieć, aby Solr robił to za nas, czyli po prostu skorzystać z mechanizmu autocommit.

Dane muszą być zaindeksowane najszybciej jak to możliwe

Jeżeli dane mają być indeksowane najszybciej jak to jest możliwe (pomijając w tym momencie temat sposobu indeksowania) należy wysyłać polecenie commit dopiero po przesłaniu wszystkich danych. Commit jest dość kosztowny pod względem wydajności i dlatego, w omawianym przypadku, powinien być stosowany jedynie na samym końcu procesu indeksacji.

Ważne jest, aby dane były publikowane jak najszybciej

Jest to chyba najtrudniejszy z wymienionych przypadków. Wszystko zależy od tego, jak szybko chcemy mieć dane widoczne na slave’ach. Na przykład w przypadku systemu CMS, kiedy użytkownik zapisuje edytowaną stronę, chcielibyśmy, aby jej zaktualizowana zawartość dostępna była od razu – wtedy commit po każdym dokumencie i szybka replikacja jest wskazana.W przypadku dodawania artykułów do sklepu internetowego, można pokusić się o pewne opóźnienie. Takie przypadki można mnożyć w nieskończoność. Należy jednak pamiętać o odpowiednim przygotowaniu zapytań rozgrzewających, aby Solr był przygotowany do obciążenia zapytaniami oraz o tym, aby nie replikować indeksów co 30 sekund, ponieważ może to być przyczyną problemów wydajnościowych.

Osoby zainteresowane bardzo częstą aktualizacją indeksu powinny obserwować to co się dzieje w Lucene i Solr odnośnie NRT (near real time).

Optymalizacja

Warto pamiętać też o optymalizacji indeksu. Jeżeli wysyłamy polecenie commit tylko raz, na zakończenie indeksowania warto zastanowić się, czy zamiast commit nie wysyłać optimize. Nasze slave’y dostaną wtedy zoptymalizowaną wersję indeksu z najnowszymi danymi. Należy jednak pamiętać, iż optymalizacja indeksu jest dłuższa, niż commit.

Niebezpieczeństwa

Warto pamiętać, iż odwlekanie operacji commit w nieskończoność wiąże się z niebezpieczeństwem utraty danych, które nie zostały fizycznie zapisane do plików indeksu. Oczywiście nic się z danymi nie stanie, jeżeli Solr zostanie poprawnie wyłączony, natomiast w przypadku awarii maszyny może się zdarzyć sytuacja, kiedy dane które indeksowaliśmy zostaną stracone.

Podsumowanie

Jak widać, nie ma jasnej odpowiedzi kiedy należy wysyłać polecenie commit ponieważ zależy to od sytuacji i indywidualnych potrzeb. Należy jednak pamiętać, iż czynności, jakie wykonywane są przez Lucene/Solr po wysłaniu polecenia commit są mocno zasobożerne. Nie korzystajmy z tego polecenia często ponieważ może się okazać, iż zamiast indeksować dane Lucene/Solr spędza większość czasu na przetwarzaniu polecenia commit.

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