Zadawanie zapytań

Jestem pewien, że wiesz jak zadaje się zapytania do Solr, tak jak jesteśmy przyzwyczajeni. Zatem, aby dostać dokumenty, które mają term solr w polu _text_ moglibyśmy użyć następującej komendy:

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

Gwoli wyjaśnienia – korzystam z jednego z przykładów dostarczonych wraz z Solr (schemaless), a zaindeksowane dane to dokumenty znajdujące się w katalogu docs dostarczanym razem z Solr.

Oczywiście, powyższe zapytanie można zadać także używając JSON API. Aby Solr zwrócił nam dokładnie te same wyniki wyszukiwania, które dostaliśmy w przypadku zapytania powyżej, skorzystalibyśmy z następującej komendy:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr"
}'

Przyjemne i proste – jak widać, wszystko co musimy zrobić, to przekazać obiekt JSON jako payload żądania, który będzie posiadał pole query, za pomocą którego przekazujemy nasze zapytanie. Taki obiekt wysłaliśmy do handlera /query ze względu, że skonfigurowany jest, aby domyślnie odpowiadać w formacie JSON. Oczywiście moglibyśmy skorzystać z handlera /select, ale wtedy odpowiedź zwrócona zostałaby w formacie XML.

Jeżeli chodzi o zadawanie zapytań, to zamiast przekazywania obiektu JSON, możemy przekazać standardowe parametry. Dokładnie tak, nie musimy przekazywać ich jako parametrów URI, ale w ciele żądania:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d 'q=_text_:solr'

Tym razem, nie mamy obiektu JSON. Standardowy parametr q został przekazany w ciele żądania i przesłany do handlera /query. Jeżeli chcemy przekazać więcej parametrów oddzielamy je znakiem &.

Stronnicowanie

Oczywiście, korzystając z JSON API możemy także kontrolować stronicowanie. W tym celu korzystamy z dwóch parametrów – limit oraz offset. Pierwszy z nich, limit definiuje maksymalną liczbę dokumentów jaką Solr może zwrócić. Parametr offset odpowiedzialny jest za określenie od którego dokumentu wyniki wyszukiwania mają być pokazywane. Na przykład, aby dostać maksymalnie 20 dokumentów zaczynając od jedenastego wykorzystalibyśmy następujące zapytanie:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "limit":20,
 "offset":10
}'

Sortowanie

Kolejna rzecz to możliwość sortowania wyników wyszukiwania – oczywiście, także dostępna. Aby posortować nasze wyniki wyszukiwania na podstawie pola o nazwie id malejąco użylibyśmy następującego zapytania:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "sort":"id desc"
}'

Jak widać definicja sortowania jest taka sama, jak w przypadku sortowania w kiedy korzystamy z parametrów URI i parametru sort.

Filtrowanie

Na koniec zostawiliśmy sobie filtrowanie. Do filtrowania wykorzystujemy właściwość filter obiekty JSON przesyłanego w ciele żądania. Na przykład zapytanie zawężąjące wyniki wyszukiwania tylko do tych dokumentów, które mają wartość text/html w polu content_type wyglądałoby następująco:

curl -XGET 'localhost:8983/solr/gettingstarted/query' -d '{
 "query":"_text_:solr",
 "filter":"content_type:text/html"
}'

Co dalej?

Jak widać, JSON API w Solr jest bardzo przyjemne i proste w wykorzystaniu pozwalając nam na definiowanie zapytań z pewną strukturą. W następnym wpisie postaramy się przybliżyć kolejną możliwość JSON API, czyli faceting. Postaramy się pokazać różnice pomiędzy starą implementacją obecną w Solr już od bardzo dawna, a nową, wprowadzoną stosunkowo niedawno.

Kilka słów na początek

JsonUpdateRequestHandler, bo tak nazywa się nowy handler, pozwala na przesyłanie danych w formacie JSON`a, co teoretycznie powinno przełożyć się na mniejszą ilość danych przesyłanych przez sieć oraz na zwiększoną szybkość indeksowania, jako, że parser JSON`a jest teoretycznie szybszy, niż parsery XML. Jednak wydajność zostawmy sobie na koniec.

Konfiguracja

Zacznijmy od zdefiniowania handlera w celu jego wykorzystania. Aby to zrobić należy do pliku solrconfig.xml dodać następujący wpis (jeżeli korzystacie z domyślnego pliku solrconfig.xml dołączonego do Solr 3.1 ten handler jest już zdefiniowany):

<requestHandler name="/update/json" class="solr.JsonUpdateRequestHandler" startup="lazy" />

Powyższy wpis definiuje nowy handler ładowany przy pierwszym odwołaniu do niego (startup=”lazy”).

Indeksowanie

Kolejny krok to przygotowanie danych do zaindeksowania – oczywiście w formacie JSON. Poniżej przykład pokazujący dwa dokumenty w jednym pliku nazwanym dane.json:

{

"add": {
  "doc": {
    "id" : "123456788",
    "region" : ["abc","def"],
    "name" : "ABCDEF",
  }
}

,
"add": {
  "doc": {
    "id" : "123456789",
    "region" : ["abc","def"],
    "name" : "XYZMN",
  }
}

}

Tak przygotowany plik możemy wysłać na adres /update/json i tym samym zaindeksować. Należy pamiętać o wysłaniu polecenia commit pod odpowiedni adres (standardowo /update) w celu zapisania zmian w indeksie.

Kilka słów o wydajności

Na sam koniec zostawiłem sobie to, co mnie tak naprawdę najbardziej interesuje – wydajność nowego handlera. Zgodnie z informacjami zapisanymi w systemie JIRA można się spodziewać, iż JsonUpdateRequestHandler będzie szybszy od swojego odpowiednika przetwarzającego pliki w formacie XML. Żeby to sprawdzić, przygotowałem pliki o wielkości 10.000, 100.000 oraz 1.000.000 dokumentów, które zawierały identyfikator (pole typu String), dwa regiony (pole typu String, wielowartościowe) oraz nazwę (pole typu Text). Jeden plik został zapisany analogicznie do pokazanego wcześniej przykładu formatu JSON, drugi plik został zapisany w formacie XML, trzeci został zapisany w formacie CSV. Wszystkie pliki były następnie indeksowane. Poniżej przedstawiam wynik tego prostego testu:

Wnioski nasuwają się same. Po pierwsze plik XML z danymi jest stosunkowo większy od tego, który zapisany został w formacie JSON`a (różnica to około 35%). Natomiast plik zapisany w formacie JSON jest jednak większy (czego należało się spodziewać) od tego, który zapisujemy w CSV. Jeżeli przesyłamy dane nie w sieci lokalnej, to wielkość ta ma znaczenie – różnica w wielkości jest na tyle znacząca, iż warto się zastanowić nad zmianą z XML do któregoś z formatów wymagających mniej miejsca na dysku.

Czas indeksacji

Kolejna sprawa, to czas indeksowania. Podpierając się wynikami tego prostego testu można stwierdzić, iż JsonUpdateRequestHandler jest nieznacznie (około 7 – 9%) szybszy od XmlUpdateRequestHandler`a. Jak widać, podobna różnica jest w przypadku JsonUpdateRequestHandler oraz CSVRequestHandler, gdzie handler operujący na plikach w formacie CSV jest szybszy od swojego odpowiednika operującego na formacie JSON o około 7 do 9%. Miejmy nadzieję, iż kiedy kiedy biblioteka noggit wyjdzie z Apache Labs jej wydajność będzie jeszcze większa, a tym samym JsonUpdateRequestHandler będzie jeszcze szybszy.