Tolerancja zapisu

Tolerancja zapisu to dość skomplikowany temat. Po pierwsze, wraz z wprowadzeniem Solr 7.0 dostaliśmy różne rodzaje replik. Mamy repliki typu NRT, które zapisują dane do loga transakcyjnego, a indeksowanie odbywa się na każdej z replik. Mamy repliki typu TLOG, gdzie nowe dane zapisywane są do loga transakcyjnego, a samo indeksowanie nie następuje i występuje tylko binarna replikacja. W końcu repliki typu PULL, gdzie Solr nie korzysta z loga transakcyjnego replikując segmenty od lidera.

Nie będziemy się dzisiaj jednak zajmować dokładną analizą, jak działają poszczególne typy replik i skupimy się na domyślnym typie, czyli replikach NRT. Repliki te były z nami od początku SolrCloud i na szczęście są dalej

W przypadku replik NRT procedura indeksowania danych działa następująco – na początku lider przyjmuje dane, zapisuje je w logu transakcyjnym i wysyła do swoich replik (zakładamy, że wszystkie są typu NRT). Każda z replik zapisuje dane w logu transakcyjnym. W tym momencie nasze dane są już bezpieczne i Solr może zwrócić potwierdzenie przyjęcia danych. Oczywiście, gdzieś w między czasie, w zależności od konfiguracji tworzony jest odwrócony indeks. Co się stanie kiedy nie wszystkie shardy będą dostępne? Indeksowanie nie powiedzie się. Aby to przetestować wystarczy, że uruchomimy dwie instancje Solr następującymi komendami:

$ bin/solr start -c

$ bin/solr start -z localhost:9983 -p 6983

A następnie stworzymy kolekcję:

$ bin/solr create_collection -c test_index -shards 2 -replicationFactor 1

Zabijemy jedną z instancji:

$ bin/solr stop -p 6983

I spróbujemy zaindeksować dane:

$ curl -XPOST -H 'Content-type:application/json' 'localhost:8983/solr/test_index/update' -d '{
 "id" : 2,
 "name" : "Test document"
}'

Oczywiście, tak jak mogliśmy się spodziewać Solr zwróci bład:

{
  "responseHeader":{
    "status":503,
    "QTime":4011},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"No registered leader was found after waiting for 4000ms , collection: test_index slice: shard2 saw state=DocCollection(test_index//collections/test_index/state.json/8)={\n  \"pullReplicas\":\"0\",\n  \"replicationFactor\":\"1\",\n  \"shards\":{\n    \"shard1\":{\n      \"range\":\"80000000-ffffffff\",\n      \"state\":\"active\",\n      \"replicas\":{\"core_node3\":{\n          \"core\":\"test_index_shard1_replica_n1\",\n          \"base_url\":\"http://192.168.1.11:8983/solr\",\n          \"node_name\":\"192.168.1.11:8983_solr\",\n          \"state\":\"active\",\n          \"type\":\"NRT\",\n          \"force_set_state\":\"false\",\n          \"leader\":\"true\"}}},\n    \"shard2\":{\n      \"range\":\"0-7fffffff\",\n      \"state\":\"active\",\n      \"replicas\":{\"core_node4\":{\n          \"core\":\"test_index_shard2_replica_n2\",\n          \"base_url\":\"http://192.168.1.11:6983/solr\",\n          \"node_name\":\"192.168.1.11:6983_solr\",\n          \"state\":\"down\",\n          \"type\":\"NRT\",\n          \"force_set_state\":\"false\",\n          \"leader\":\"true\"}}}},\n  \"router\":{\"name\":\"compositeId\"},\n  \"maxShardsPerNode\":\"-1\",\n  \"autoAddReplicas\":\"false\",\n  \"nrtReplicas\":\"1\",\n  \"tlogReplicas\":\"0\"} with live_nodes=[192.168.1.11:8983_solr]",
    "code":503}}

W tym wypadku nie jesteśmy w stanie zrobić nic – nie chcemy, aby nasze dane wylądowały gdziekolwiek. Musimy czekać, aż Solr powróci do stanu używalności, albo sami go do niego doprowadzimy

Co jednak w przypadku, kiedy mamy wiele replik i tylko niektóre z nich nie są dostępne? W tym wypadku zapis się powiedzie, a w najnowszych wersjach Solr poinformuje nas o stanie replikacji poprzez umieszczenie w odpowiedzi parametru rf, czyli replication factor.

Stwórzmy sobie zatem jeszcze jedną kolekcję, tym razem składającą się z jednego lidera i jego repliki:

$ bin/solr create_collection -c test_index_2 -shards 1 -replicationFactor 2

Jeżeli spróbujemy zaindeksować dane takim samym poleceniem jak wcześniej (oczywiście zmieniając nazwę kolekcji) odpowiedź Solr w wersji 7.6.0 będzie wyglądała następująco:

{
  "responseHeader":{
    "rf":2,
    "status":0,
    "QTime":316}}

Jak widać parametr rf ustawiony został na wartość 2, co mówi nam, że indeksowanie powiodło się zarówno na liderze, jak i jego replice. Jeżeli zatrzymalibyśmy instancję Solr działającą na porcie 6983 i spróbowali ponowić indeksowanie Solr poinformuje nas, iż tylko jedna replika danych została zapisana:

{
  "responseHeader":{
    "rf":1,
    "status":0,
    "QTime":4}}

We wcześniejszych wersjach Solr, aby otrzymać tą informację należało dodać parametr min_rf większy od 1 do żądania zawierającego indeksowanie, aby dostać informację, jaki poziom replikacji został osiągnięty przez Solr.

Tolerancja odczytu

W przypadku odczytu sprawy mają się trochę inaczej. Brak spójności danych, np. w przypadku braku jednego lub kliku shardów spowoduje, iż Solr zwróci błąd. Możemy to bardzo prosto pokazać – tworzymy dwie instancje Solr:

$ bin/solr start -c

$ bin/solr start -z localhost:9983 -p 6983

Następnie tworzymy prostą kolekcję:

$ bin/solr create_collection -c test -shards 2 -replicationFactor 1

A teraz zatrzymujemy jedną z instancji:

$ bin/solr stop -p 6983

I teraz wystarczy zadać proste zapytanie:

http://localhost:8983/solr/test/select?q=*:*

W odpowiedzi zamiast pustej listy dokumentów dostaniemy błąd:

{
  "responseHeader":{
    "status":503,
    "QTime":6,
    "params":{
      "q":"*:*"}},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"no servers hosting shard: shard2",
    "code":503}}

Czasami jednak chcielibyśmy zaprezentować wyniki wyszukiwania pomimo braku części informacji. Nie jest to oczywiście idealna sytuacja, ale czasem lepiej pokazać mniej danych, niż nie pokazać nic, oczywiście jeżeli zdajemy sobie sprawę co robimy. W tym celu przychodzą nam z pomocą dwa parametry: shards.tolerant oraz shards.info. Oba powinny zostać ustawione na wartość true, czyli nasze zapytanie przyjmie następującą formę:

http://localhost:8983/solr/test/select?q=*:*&shards.tolerant=true&shards.info=true

Tym razem Solr nie zwróci już błędu, a nagłówek odpowiedzi będzie wyglądał następująco:

{
  "responseHeader":{
    "zkConnected":true,
    "partialResults":true,
    "status":0,
    "QTime":45,
    "params":{
      "q":"*:*",
      "shards.tolerant":"true",
      "shards.info":"true"}},
  "shards.info":{
    "":{
      "error":"org.apache.solr.common.SolrException: no servers hosting shard: ",
      "trace":"org.apache.solr.common.SolrException: no servers hosting shard: \n\tat org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:165)\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)\n\tat org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat java.lang.Thread.run(Thread.java:748)\n",
      "time":0},
    "http://192.168.1.11:8983/solr/test_shard1_replica_n1/":{
      "numFound":0,
      "maxScore":0.0,
      "shardAddress":"http://192.168.1.11:8983/solr/test_shard1_replica_n1/",
      "time":18}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  }}

Jak widać, działa to tak jakbyśmy chcieli. Nie dostaliśmy od Solr błędu, a odpowiedź. Dodatkowo widzimy, iż zwrócone są częściowe rezultaty (partialResults ustawione na true), co pozwala nam lub naszej aplikacji na stwierdzenie, że coś jest nie tak. Oprócz tego opcja shards.info=true pozwoliła Solr zwrócić informacje których shardów brakuje.

Wersja Solr

W celu przetestowania funkcjonalności o której mowa we wpisie, skorzystałem z nadchodzącej dużymi krokami Apache Solr 4.0 alpha.

Założenia

Załóżmy, że potrzebujemy aktualizować jedno z pól w indeksie, ale tak, aby nie przesyłać ponownie całego dokumentu. Np. niech to będzie cena produktu, która aktualizowana jest kilkukrotnie w ciągu dnia. Nie chcemy, za każdym razem gdy zmieni się cena, aktualizować całego dokumentu, ponieważ każdy dokument to tak naprawdę nie tylko meta dane, ale także pliki binarne przetwarzane przez Tika, a tym samym takie indeksowanie jest dość czasochłonne. Co możemy w takim wypadku zrobić ? O tym za chwilę, zacznijmy od struktury indeksu.

Struktura indeksu

Struktura indeksu, jest bardzo prosta, zawiera pola odpowiadające za identyfikator produktu (id), jego nazwę (title), cenę (price) oraz opis (description). Fragment pliku schema.xml wygląda następująco:

<fields>
  <field name="id" type="string" indexed="true" stored="true" required="true" />
  <field name="name" type="text_general" indexed="true" stored="true"/>
  <field name="price" type="float" indexed="true" stored="true" />
  <field name="description" type="text_general" indexed="true" stored="true" />
  <field name="_version_" type="long" indexed="true" stored="true"/>
</fields>

Warto zauważyć dwie rzeczy: po pierwsze wszystkie pola oznaczone są jako stored=”true”. Dlaczego tak ? O tym trochę później. Druga rzecz to pole o nazwie _version_, które używane jest używane wewnętrznie przez Solr i jest konieczne.

Zawartość indeksu

Do testów zaindeksowałem jeden przykładowy dokument, który po zadaniu zapytania q=*:* prezentował się następująco:

<?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="id">1</str>
    <str name="name">Test 1</str>
    <float name="price">479.95</float>
    <str name="description">Description 1</str>
    <long name="_version_">1406418192301031424</long>
  </doc>
</result>
</response>

Częściowa aktualizacja

Aby zaktualizować cenę dokumentu, należy do Solr wysłać następujące polecenie:

curl 'localhost:8983/solr/update?commit=true' -H 'Content-type:application/json' -d '[{"id":"1","price":{"set":100}}]'

Powyższe polecenie mówi, że w dokumencie o polu id równym 1 należy zmienić pole price i ustawić je na wartość 100. Jak wygląda nasze zapytanie q=*:* po wysłaniu powyższego zapytania ? Wynik tego zapytania wygląda następująco:

<?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="id">1</str>
    <str name="name">Test 1</str>
    <float name="price">100.0</float>
    <str name="description">Description 1</str>
    <long name="_version_">1406418399028838400</long>
  </doc>
</result>
</response>

Jak widać pole price zostało uaktualnione. Zmieniła się także wartość pola _version_. Czyli dokładnie to, o co nam chodziło.

Co oprócz aktualizacji ?

Oprócz aktualizacji wartości pól w dokumentach funkcjonalność ta pozwala także na inne operacje, takie jak np. dodawanie wartości do pól wielowartościowych. Dla zainteresowanych polecam testy z komendą add (w odróżnieniu do przykładowego wykorzystania komendy set). Jak widać, nowa funkcjonalność Solr nie ogranicza się zaledwie do aktualizacji wartości pól, ale pozwala na trochę więcej operacji na dokumencie.

Rzeczy o których należy pamiętać

Wróćmy do struktury indeksu. Jak napisałem wcześniej, wszystkie pola w dokumencie ustawione są jako stored=”true”. Dzieje się tak dlatego, że tak naprawdę pojedyncze pole w indeksie nie jest uaktualniane, a uaktualniany jest cały dokument. Solr stosuje sztuczkę i pobiera pola, które oznaczone są jako stored=”true”, usuwa dokument, a następnie dodaje go ponownie, nanosząc na pobrane wartości zmiany, które kazaliśmy zrobić. Tylko tyle i aż tyle.

Podsumowanie

Obecna w Solr 4.0 funkcjonalność aktualizacji pól dokumentów nie aktualizuje pól w indeksie, a usuwa istniejący dokument indeksując w jego miejsce uaktualniony. Wszystko dzieje się po stronie Solr, a zatem jesteśmy zwolnieni z obowiązku martwienia się o aktualizację pojedynczego (bądź wielu) pól w dokumentach znajdujących się w indeksie. Oczywiście, musimy pogodzić się z większym indeksem, ze względu na to, że pola dokumentów muszą być przechowywane w oryginalnej postaci, bo inaczej Solr nie będzie w stanie ich odczytać. Zyskujemy zatem czas potrzebny na przetworzenie dokumentu i przesłanie go przez sieć, należy jednak pamiętać, iż cały proces indeksacji zostanie wykonany na nowo.

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.

Każdy z nas wie co to jest plik schema.xml i do czego służy (jeżeli nie, to zapraszam do lektury wpisu znajdującego się pod adresem: http://solr.pl/2010/08/16/co-to-jest-schema/). Jakie błędy najczęściej popełniamy tworząc lub uaktualniając ten plik ? Ja osobiście spotkałem się z następującymi:

1. Śmietnik w konfiguracji

Pierwsza zasada jaką wyznaję to trzymanie pliku schema.xml w najprostszej z możliwych postaci. Wiąże się z tym jedna bardzo ważna sprawa – plik ten nie powinien być synonimem chaosu. Jednym słowem, nie trzymajmy tak niepotrzebnych komentarzy, niepotrzebnych typów, pól i tak dalej. Porządek w strukturze indeksu ułatwia nam nie tylko utrzymywanie tego pliku i jego modyfikacje, ale przede wszystkim upewnia nas, że nie indeksujemy informacji, które są zbędne z punktu widzenia aplikacji wykorzystującej Solr.

2. Kosmetyczne zmiany domyślnej konfiguracji

Ile z osób, które wykorzystuje Solr w swojej codziennej pracy brało domyślny plik schema.xml dostarczany w przykładowym wdrożeniu Solr i tylko nieznacznie modyfikowało jego zawartość – na przykład zmieniając tylko nazwy pól ? Sam powinienem podnieść rękę, bo sam kiedyś tak zrobiłem. Jest to dość duży błąd według mnie. Ktoś może się zapytać dlaczego. Czy na pewno robiąc wyszukiwanie w treściach napisanych w języku polskim potrzebujemy na przykład angielskiego stemmingu ? Wydaje mi się, że jednak nie potrzebujemy. Czy na pewno we wszystkich przypadkach potrzebujemy przechowywać informacje o wektorach termów ?

3. Brak uaktualnień

Czasami zdarza mi się trafić na wdrożenia, gdzie wraz z uaktualnieniami wersji Solr nie uaktualnia się pliku schema.xml. Jeżeli jest to świadoma decyzja, podyktowana np. kosztowną, bądź wręcz niemożliwą ponowną indeksacją wszystkich danych, to rozumiem sytuację. Są jednak przypadki kiedy uaktualnienie przyniosłoby same korzyści, a środki jakie trzeba by było przeznaczyć na takie uaktualnienie są minimalne (np. mało kosztowna reindeksacja, bądź niewielkie zmiany w aplikacji). Nie bójmy się uaktualniać pliku schema.xml – czy chodzi to o aktualizację pól, aktualizację typów, czy dodanie nowszych rzeczy. Dobrym przykładem jest tutaj migracja z Solr 1.3 na wersję 1.4 wprowadzającą duże zmiany związane z typami liczbowymi, gdzie migracja na nowe typy skutkowała naprawdę dużym wzrostem wydajności zapytań z nich korzystających (np. zapytań wykorzystujących przedziały wartości). 

4. „A może kiedyś się przyda”

Dodawanie nowych typów, nieusuwanie już niepotrzebnych, tak samo w przypadku pól, czy definicji copyField. Wiem, to się kiedyś może jeszcze przydać, ale pamiętajmy, że każdy typ to dodatkowa pamięć potrzebna Solr, każde pole to miejsce w indeksie, tak samo jak każdy copyField. Moja drobna rada – jeżeli przestajesz wykorzystywać typ, pole, czy cokolwiek innego co masz w pliku konfiguracyjnym (nie tylko w schema.xml) po prostu usuń to z tego pliku. Stosując tą zasadę przez cały cykl życia aplikacji korzystającej z Solr będziesz zawsze mieć pewność, że indeks jest w optymalnym stanie, a po kilku miesiącach od wdrożenia nie trzeba się będzie zastanawiać i przekopywać przez kod aplikacji, aby sprawdzić czy na pewno dane pole, czy typ jest wykorzystywany.

5. Atrybuty, atrybuty i jeszcze raz atrybuty

Przechowywanie oryginalnych wartości, dodanie wektora termów i jego właściwości to tylko przykłady, które mogą spowodować, mamy większy, niż wymaga tego aplikacja, index. Większy index, mniejsza wydajność, przynajmniej w niektórych wypadkach (np. w przypadku indeksowania). Warto więc zastanowić się, czy na pewno potrzebujemy tych wszystkich informacji, które każemy Solr wyliczać i przechowywać. Usunięcie niektórych, oczywiście niepotrzebnych z naszego punktu widzenia informacji, może nas miło zaskoczyć. Czasami warto spróbować

Zapraszam do komentowania, ponieważ chętnie poczytam, na co jeszcze powinno się zwracać uwagę przy modyfikacji pliku schema.xml.

Na koniec, warto wspomnieć o artykule „The Seven Deadly Sins of Solr” opublikowanym na stronach LucidImagination pod adresem: http://www.lucidimagination.com/blog/2010/01/21/the-seven-deadly-sins-of-solr/. Opisuje on złe praktyki w trakcie pracy z Solr i zahacza także o temat plików konfiguracyjnych. Moim zdaniem ciekawa lektura. Polecam.