Dokumenty

Nasze dokumenty zawierają informację o uczestnikach konkursu – ich id, imię/nick (jako pole author) oraz pole email. Dla przykładu jeden rekord może wyglądać w następujący sposób:

<doc>
  <field name="id">1</id>
  <field name="author">Solr.pl author</field>
  <field name="email">blog(at)solr.pl</field>
</doc>

Nasze bardzo „big data” zawiera 19 rekordów, może powinniśmy użyć map/reduce? :).

Schema

Plik schema.xml opisujący strukturę indeksu jest również bardzo prosty. W naszym przypadku zawiera następujące pola:

<field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
<field name="author" type="text_general" indexed="true" stored="true"/>
<field name="email" type="text_general" indexed="true" stored="true"/>

Dodatkowa konfiguracja

Powinniśmy upewnić się się, że plik schema.xml zawiera następujące definicje typu i pola:

<fieldType name="random" class="solr.RandomSortField" indexed="true" />
<dynamicField name="random_*" type="random" />

W przykładowym pliku schema.xml dostarczanym przez Solr ten typ i definicja pola są dostępne domyślnie. Będziemy potrzebować tych definicji do generowania losowej kolejności wyników.

Wykonywanie zapytań z losowym porządkiem sortowania

Tworzenie zapytań z losowym porządkiem wyników jest trochę nietypowe. Budujemy zapytanie jak zwykle z wyjątkiem definicji sortowania wyników. Parametr sort używa zdefiniowanego wcześniej dynamicznego pola z prefiksem random. Na przykład:

localhost:8983/solr/competition/select?q=*:*&sort=random_12939291%20desc

Jak to działa?

Solr wylicza kolejność dokumentów bazując na nazwie pola dynamicznego oraz na numerze wersji indeksu. Oznacza to, że za każdym razem, gdy używamy tego samego pola na tym samym indeksie (jeżeli indeks nie zmienił się pomiędzy zapytaniami), otrzymamy te same rezultaty. To wada tej metody, chociaż może okazać się przydatna w pewnych okolicznościach. Na przykład stronicowanie – nie chcemy dostać zdublowanych wyników na różnych stronach, prawda? Z powodu powyższego za każdym razem powinniśmy generować nową nazwę pola przesyłając do Solr zapytanie z naszej aplikacji.

A taraz – wyniki konkursu!

W losowaniu użyliśmy podanego poniżej zapytania. Liczba użyta w nazwie pola dynamicznego jest absolutnie losowa i została wygenerowana poprzez zadanie następującego pytania: „Tato, możesz mi podać kilka dowolnych liczb?” :). Tak więc nasze zapytanie uzyskało formę:

localhost:8983/solr/collection1/select?q=*:*&indent=true&rows=2&sort=random_3721117253841%20desc

Co dało następujące wyniki:

<result name="response" numFound="19" start="0">
  <doc>
    <str name="id">9</str>
    <str name="author">Rajeev Srivastava</str>
    <str name="email">[CENSORED]</str>
    <long name="_version_">1431017731370516481</long></doc>
  <doc>
    <str name="id">8</str>
    <str name="author">Evgeny</str>
    <str name="email">[CENSORED]</str>
    <long name="_version_">1431017731370516480</long></doc>
</result>

Zwycięzcy

• Rajeev
• Evgeny

Gratulujemy! Skontaktujemy się z Wami w najbliższym czasie z dalszymi informacjami, w jaki sposób możecie otrzymać nagrodę. Jeszcze raz: gratulacje! Do wszystkich uczestników: Dziękujemy za udział i za Wasze komentarze.

Solr Cloud to zmienił. W tym artykule zainstalujemy nowy cluster SolrCloud „od zera” i zobaczymy jak to działa w praktyce.

Nasz przykładowy cluster

W przykładach będziemy używać trzech serwerów Solr. Każdy serwer w clustrze jest zdolny obsługiwać jednocześnie indeksowanie oraz zapytania. To podstawowa różnica w stosunku do wcześniejszego rozwiązania z jednym serwerem master i wieloma serwerami slave. W nowej architekturze pojawia się dodatkowy element: Zookeeper, odpowiedzialny za przechowywanie konfiguracji clustra i synchronizacje jego pracy. To jest bardzo ważna informacja oznaczająca, że gdy Zookeeper zawiedzie, cały cluster jest bezużyteczny. Z tego powodu niezbędne jest zapewnienie wysokiej dostępności tego elementu – dlatego w tym przykładzie używamy trzech niezależnych instancji Zookeepera.

Instalacja Zookeepera

Jak napisaliśmy wcześniej, Zookeeper jest istotną częścią rozwiązania SolrCloud. Mimo, że możemy używać Zookeepera wbudowanego w Solr, jest to przydatne w zasadzie tylko w testowaniu. Do rozwiązań produkcyjnych zdecydowanie potrzebujesz, by Zookeeper był zainstalowany niezależnie od Solr i działał w innym procesie JVM by wyeliminować możliwość wzajemnego wpływu na swoją pracę lub przerwę w działaniu.

Instalacja Apache Zookeeper jest całkiem prosta i może być opisana następującymi krokami:

1. Pobranie archiwum Zookeeper z: http://www.apache.org/dyn/closer.cgi/zookeeper/
2. Rozpakowanie pobranej paczki i skopiowanie conf/zoo_sample.cfg do conf/zoo.cfg
3. Modyfikacja zoo.cfg:
   1. Zmiana dataDir na katalog, gdzie chcesz przechowywać dane konfigracyjne generowane przez cluster
   2. Dodanie informacji o wszystkich instancjach Zookeepera (patrz niżej)

Po wspomnianych zmianach mój zoo.cfg wygląda następująco:

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/zookeeper/data
clientPort=2181
server.1=zk1:2888:3888
server.2=zk2:2888:3888
server.3=zk3:2888:3888

Następnie:

1. Skopiuj instalacje na wszystkie serwery, gdzie Zookeeper ma działać
2. Stwórz plik /var/zookeeper/data/myid z indentyfikatorem serwera. Identyfikator ten jest różny dla każdej instancji (np. dla maszyny  zk2  ten plik będzie zawierał liczbę:  2 )
3. Uruchom wszystkie instancje używając polecenia “bin/zkServer.sh start-foreground” i zweryfikuj poprawność instalacji
4. Dodaj “bin/zkServer.sh start” do skryptów startowych i upewnij się, że system operacyjny monitoruje dostępność instancji Zookeepera.

Instalacja Solr

Instalacja Solr jest następująca:

1. Pobierz archiwum Solr z: http://www.apache.org/dyn/closer.cgi/lucene/solr/4.1.0
2. Rozpakuj pobrany plik
3. W tym artykule będziemy używać gotowej instalacji z katalogu example i wszystkie zmiany będziemy wykonywać na tej przykładowej instalacji
4. Skopiuj instalację Solr na wszystkie serwery będące częścią clustera
5. Zainstaluj do Zookeepera dane konfiguracyjne, które będą używane przez cluster. W tym celu uruchom pierwszą instancję Solr z:

   java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=solr1 -DzkHost=zk1:2181 -DnumShards=2 -jar start.jar

Ta komenda powinna być wykonana tylko raz. Następne uruchomienia będą używać konfiguracji z Zookeepera i lokalna konfiguracja nie jest już potrzebna. Następnie:

1. Uruchom wszystkie instancje Solr używając:

   java –DzkHost=zk1:2181 –jar start.jar

Sprawdzenie poprawności instalacji

W tym celu idź do panelu administracyjnego na dowolnej instancji Solr. W naszym przykładzie URL jest następujący:  http://solr1:8983/solr. Gdy klikniesz na zakładce: cloud a następnie wybierzesz graph, powinieneś zobaczyć coś podobnego do poniższego obrazka:

Kolekcja

Nasz pierwsza kolekcja – collection1 jest podzielona na dwa shardy  (shard1 i shard2). Każdny z nich jest umiejscowiony na dwóch instancjach Solr (OK, na obrazku widzisz, że każdy Solr jest na tej samej maszynie fizycznej  – Mam aktualnie tylko jeden fizyczny serwer do testów – może jakiś ochotnik do darowizny?  ;)). Możesz też zobaczyć patrząc na grafikę kropki czy to jest primary shard czy replika.

Podsumowanie

Mam nadzieję, że to pierwszy z serii wpisów na temat solrCloud. Wiem, że jest bardzo krótki i pomija pewne detale i informację o shardach, replikach i architekturze rozwiązania. Potraktuj to jako checklistę do prostej (ale rzeczywistej) konfiguracji swojego rozwiązania „chmurowego”.

Pełna lista zmian w bibliotece Apache Lucene 4.0 beta znajduje się pod adresem: http://wiki.apache.org/lucene-java/ReleaseNote40beta. Pełną listę zmian w Apache Solr 4.0 beta znajdziemy pod adresem:http://wiki.apache.org/solr/ReleaseNote40beta.

Bibliotekę Apache Lucene w wersji 4.0 beta możemy znaleźć pod adresem:http://www.apache.org/dyn/closer.cgi/lucene/java/. Silnik wyszukiwania Apache Solr w wersji 4.0 beta można znaleźć pod adresem http://www.apache.org/dyn/closer.cgi/lucene/solr/.

W chwili publikowania tego wpisu wszystkie mirrory mogą nie być jeszcze uaktualnione.

Wymagania

Przy tworzeniu listy podpowiedzi przyjęliśmy następujące założenia:

1. Podpowiadana jest cała fraza a nie tylko pojedyncze słowo
2. Podpowiadana fraza może wystąpić w indeksie wielokrotnie
3. w wyniku chcemy znać liczbę wystąpień
4. Częściej występujące frazy są podpowiadane w pierwszej kolejności
5. Kolejność podawanych przez użytkownika słów nie musi odpowiadać kolejności występowania słów w podpowiadanej frazie

Rozwiązanie

Podany w pierwszej części sposób odpada ze względu na pierwsze założenie. Co prawda wyszukiwanie słów we frazie da się prosto osiągnąć zmieniając sposób analizy, jednak zwracane są pojedyncze słowa a nie cała fraza.

Rozwiązanie to zmodyfikowana wersja sposobu z facetingiem. Zamiast stosować wyszukiwanie wszystkich elementów i zawężanie wyników facetingu poprzez facet.prefix, możemy od razu wyszukać tylko te elementy, które mają fragment słowa wpisanego przez użytkownika. Ponieważ nie chcemy stosować zapytania prefiksowego ( „słowo*” ) ze względów wydajnościowych, na pomoc wezwiemy ngramy. Oznacza to zapisanie w indeksie wszystkich przedrostków słowa. Oczywistą wadą jest rozrost indeksu, ale w naszym przypadku jesteśmy w stanie z tym żyć

Schema.xml

Definiujemy więc dodatkowy typ:

  <fieldType name="text_autocomplete" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="25" />
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
  </fieldType>

Oraz pola: to, którego wartość będziemy wyświetlać oraz te, służące do wyszukiwania:

<field name="tag_autocomplete" type="text_autocomplete" indexed="true" stored="true" omitNorms="true" omitTermFreqAndPositions="true"/>
<field name="tag" type="string" indexed="true" stored="true" />

Zostaje jeszcze odpowiedni copyField:

<copyField source="tag" dest="tag_autocomplete"/>

 Zapytanie

Po przeindeksowaniu możemy przystąpić do tworzenia zapytania:

1. Zawężamy listę wyników do tych, które w polu tag_autocomplete mają poszukiwany fragment słowa: q=tag_autocomplete:(FRAZA)
2. W przypadku wielu podanych przez użytkownika fragmentów słów istotne jest, by były one wyszukiwane wszystkie: q.op=AND
3. Tak naprawdę wyniki nie są istotne, dane odczytamy z facetingu, więc informujemy solr, że nie potrzebujemy listy wyników: rows=0
4. Potrzebujemy natomiast faceting: facet=true
5. W dodatku to faceting po polu w którym przechowujemy oryginalną zawartość pola podpowiedzi: facet.field=tag
6. Nie interesują nas tagi, które nie zostały znalezione: facet.mincount=1
7. Interesuje nas 5 wyników: facet.limit=5

Ostateczne zapytanie:

?q=tag_autocomplete:(FRAZA)&q.op=AND&rows=0&facet=true&facet.field=tag&facet.mincount=1&facet.limit=5

Jeśli parametry, które są stałe umieścimy w handlerze, jako wartości domyślne, to zapytanie sprowadza się do:

?q=tag_autocomplete:(FRAZA)

Słowo na koniec

Podstawową zaletą tego rozwiązania w stosunku do rozwiązania opartego o faceting i facet.prefix jest możliwość używania innego pola do zwracania podpowiedzi. Dzięki temu przy podpowiadaniu pojedynczych słów możemy w wyniku wyświetlić całą zawartość pola „tag”.

• poprawki błędów
• wstępne wsparcie dla Solr 4.0
• obsługę ruby 1.9

Cały kod jest dostępny na naszym koncie GitHub.

Dla przypomnienia: jest to narzędzie do wizualizacji wyników zapytań zadawanych do Solr i odpowiedzi w przejrzystej formie na pytania:

• dlaczego dany dokument został znaleziony
• dlaczego dany dokument nie został znaleziony

Zdecydowaliśmy się w tym momencie opublikować, mimo, że jeszcze wiele rzeczy chcielibyśmy zmienić i poprawić. Jednak z drugiej strony zawsze będzie coś do poprawienia

Sama aplikacja została napisana z wykorzystaniem Ruby On Rails i chociaż widać, że była pisana przez osoby na codzień korzystające z innych języków programowania, to mamy nadzieje, że okaże się przydatna.

Kod jest udostępniony na zasadach licencje Apache (2.0), w przypadku jego wykorzystania będzie nam miło, jeśli dostaniemy o tym informację. Namawiamy również do podsyłania poprawek i zgłaszania błędów.

Kod jest dostępny na Githubie: https://github.com/solrpl/explain

• narzędzie wzbudziło pewne zainteresowanie, jednak większość analizowanych przez Was odpowiedzi solr jest zaznaczana jako niepubliczna.
• w stosunkowo dużej części zapytań zamiast odpowiedzi z SOLR wklejacie samo zapytanie
• również często wklejany wynik nie zawiera informacji diagnostycznych (debugQuery=true)
• nie wydana wersja 4.0 cieszy się dość dużą popularnością, niestety explain jeszcze jej nie wspiera
• z wyjątkiem oczywistych problemów z analizą odpowiedzi SOLR 4.0 parser radził sobie niespodziewanie dobrze

W chwili obecnej na explain.solr.pl znajduje się nowa wersja oprogramowania. Zmiany:

• dodano proste wsparcie dla analizy pod kątem wydajności
• poprawiono komunikaty na trochę bardziej przyjazne dla użytkownika
• poprawiono parser wyników w oparciu o pliki testowe odpowiedzi wygenerowanymi przez testy jednostkowe dostępne w kodzie Solr dla wersji 3.5
• drobne poprawki interfejsu

• przebudową analizatora informacji zwracanych przez explain Lucene, tak by przygotować się na wielkie zmiany w Lucene 4.0 (m.in per field similarity oraz flexible similarity)
• przebudową interfejsu i zwiększeniem czytelności
• porządkami w kodzie i przygotowaniem do publikacji źródeł

Na szczęście jesiennie i zimowe, długie wieczory sprzyjają pracy Postaramy się udostępnić http://explain.solr.pl jak najszybciej będzie to możliwe.

Dla nas najważniejszy był drugi dzień i efekty naszej pracy: Understanding & Visualising Solr 'explain’ Information. Prezentacja składała się z dwóch części. Pierwsza, teoretyczna, opisywała to, co prezentuje solr odnośnie ważności zwróconego dokumentu. Informacje te nie należą niestety do najbardziej czytelnych, szczególnie w sytuacji, gdy wyszukiwanie odbywa się po wielu polach korzystając często z dedykowanych parserów zapytań (na obrazku fragment opisujący trafienie tylko w jeden dokument (!)).

Sytuację pogarsza fakt, że pytania Klienta dotyczące prób zrozumienia kolejności dokumentów w wynikach wyszukiwania, są tym, co zajmuje sporo czasu w projekcie.

Druga część prezentacji pokazywała to, co postanowiliśmy z tym problemem zrobić. Pomysł pojawił się po obejrzeniu explain.depesz.com – podobnego narzędzia służącego wizualizacji informacji udostępnianych przez bazę postgreSQL.

Z perspektywy czasu nasz explain wydaje się być dobrym pomysłem. Samo narzędzie przydało nam się już wielokrotnie. Co ważniejsze – prezentacja na Euroconie pokazała, że jest również spore zainteresowanie społeczności. Dziękujemy za miłe słowa, zagrzewanie do walki a zwłaszcza za obietnice podesłania własnych modułów.

Obecna wersja explain.solr.pl skupia się na odczycie informacji generowanych przez solr 3.x. Pracujemy obecnie nad jej upublicznieniem oraz (trochę później) otwarciem kodu.

Podsumowując plany na najbliższy czas są dość ambitne:)

1. Po pierwsze – z kronikarskiego obowiązku – postaramy się opisać jak wyglądał Lucene Eurocon 2011 z naszej perspektywy. Planujemy opublikować dwa wpisy z których każdy będzie poświęcony jednemu dniu konferencji. Czyli coś do poczytania zanim pojawią się oficjalne filmy z konferencji.
2. Otworzenie explain.solr.pl dla szerokiego grona odbiorców
3. Opublikowanie kodu explain.solr.pl  (github)
4. Powrót do bardziej regularnych wpisów dotyczących Solr.

Trzymajcie kciuki

Jak łatwo się domyślić zadaniem filtra jest zamiana w strumieniu wejściowym tych fragmentów, które pasują do danego wyrażenia regularnego.

Dostępne są następujące parametry:

• pattern (wymagany) – wartość, która zostanie zamieniona (wyrażenie regularne)
• replacement (domyślnie: „”) – wartość, którą zostanie zastąpiony dopasowany do wyrażenia regularnego fragment
• blockDelimiters
• maxBlockChars (domyślnie: 10000, większe od 0) – bufor używany przy porówaniu

Przykłady wykorzystania

Wykorzystanie filtru sprowadza się do dodania jego definicji w definicji typu pola w schema.xml np.:

<fieldType name="textCharNorm" class="solr.TextField">
  <analyzer>
    <charFilter class="solr.PatternReplaceCharFilterFactory" …/>
    <charFilter class="solr.MappingCharFilterFactory" mapping="mapping-ISOLatin1Accent.txt"/>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  </analyzer>
</fieldType>

Poniżej przykładowe definicje dla różnych przypadków.

Wycinanie fragmentów tekstu

To najprostszy przypadek. Należy tylko podać w atrybucie pattern to co chcemy wyciąć i już. Przykład:

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="#TAG" />

co spowoduje pomijanie w treści danych elementów: „#TAG”

Zamiana fragmentów tekstu

Przypadek podobny do tego wyżej, natomiast chcemy zamienić tekst na inny.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="#TAG" replacement="[CENZORED]"/>

Zamiana wzorców

Powyższe przypadki były trywialne. To, co stanowi o sile tego filtru to obsługa wyrażeń regularnych. (Używasz wyrażeń regularnych, prawda?) Poniższy przykład jest prosty – ukrywa wszystkie liczby (zamieniając je na gwiazdki). Radzi sobie również z liczbami oddzielonymi myślnikami, traktując je jako pojedyncze liczby.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="(\\d+-*\\d+)+" replacement="*"/>

Manipulacja tekstem

Tekst zastępujący nie musi być prostym tekstem. Obsługiwane są tzw. odwołania wsteczne, które pozwalają na odwołanie się do fragmentów dopasowanego wzorca. Po szczegóły odsyłam do dokumentacji wyrażeń regularnych. W poniższym przykładzie wszystkie zwielokrotnione znaki zastępowane są znakiem pojedynczym.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="(.)\\1" replacement="$1"/>

Parametry zaawansowane

Do tej pory nie wspomniałem o parametrach: blockDelimiters i maxBlockChars. Jak wynika ze źródeł filtra, są one związane ze sposobem jego implementacji. CharFilter z założenia operuje na pojedynczych znakach, natomiast dopasowanie wzorca wymaga wczytania do wewnętrznego bufora większej liczby znaków. MaxBlockChars pozwala na okreśłenie rozmiaru tego bufora. W zasadzie nie musisz się tym martwić, jeśli wzorzec, który zdefiniowałeś, nie powoduje dopasowania większego kawałka tekstu (większy oznacza tu powyżej 10tys znaków). BlockDelimiters pozwala dodatkowo zoptymalizować wypełnianie tego bufora. Może być używany, jeśli informacja w analizowanym polu jest w jakiś sposób podzielona na sekcje (np. jest to CSV, zdania itp.). Jest to tekst, który informuje skaner, że zaczyna się nowa sekcja, w związku z tym, ew fragmenty dopasowania z poprzedniej sekcji już się nie przydadzą.

Ograniczenia

Ważnym ograniczeniem filtra jest to, że w bezpośredni sposób manipuluje napisem wejściowym, nie zachowując informacji związanych z początkowym tekstem. Oznacza to, że jeśli filtr usunie jakiś fragment napisu, lub doda nowy fragment, tokenizer tego nie zauważy i położenie tokenów w oryginalnym polu nie zostanie poprawnie zapisane. Trzeba mieć tego świadomość w sytuacji używania zapytań biorących pod uwagę wzajemne położenie słów oraz w przypadku używania highlightingu.