Mając pod ręką przykładowe dane z albumami i wykonawcami postanowiłem pokazać mój sposób postępowania w takich wypadkach. Dla uproszczenia i przejrzystości zakładam, że po pierwszym zaimportowaniu, danych może tylko ubywać.

Dane testowe

Moje dane testowe mieszczą się bazie PostgreSQL w tabeli zdefiniowanej następująco:

Table "public.albums"
Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
id     | integer | not null default nextval('albums_id_seq'::regclass)
name   | text    | not null
author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)

W tabeli znajduje się 825661 rekordów.

Instalacja testowa

Do testów użyłem instancji SOLR posiadającej następującą charakterystykę:

Definicja w schema.xml:

<fields>
<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="album" type="text" indexed="true" stored="true" multiValued="true"/>
<field name="author" type="text" indexed="true" stored="true" multiValued="true"/>
</fields>
<uniqueKey>id</uniqueKey>
<defaultSearchField>album</defaultSearchField>

Definicja DIH w solrconfig.xml:

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">db-data-config.xml</str>
</lst>
</requestHandler>

I plik DIH db-data-config.xml:

<dataConfig>
<dataSource driver="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/shardtest" user="solr" password="secret" />
<document>
<entity name="album" query="SELECT * from albums">
<field column="id" name="id" />
<field column="name" name="album" />
<field column="author" name="author" />
</entity>
</document>
</dataConfig>

Przed naszym testem zaimportowałem wszystkie dane z tabeli albums.

Usuwanie danych

Patrząc na tabelę widać, że gdy usuniemy rekord, ginie on bez śladu i jedynym sposobem aktualizacji naszego indeksu byłoby porównanie identyfikatorów dokumentów w indeksie z identyfikatorami w bazie i wyrzucenie tych, które w bazie już nie istnieją. Wolne i niewygodne. Innym sposobem jest dodatnie kolumny deleted_at: zamiast kasowania fizycznie rekordu, uzupełniamy tylko tę kolumnę. DIH może wtedy pobrać wszystkie rekordy z ustawioną datą późniejszą od ostatniego indeksowania. Wadą tego rozwiązania może by konieczność modyfikacji aplikacji by uwzględniały tak „skasowane” rekordy.

Ja zastosuje inne rozwiązanie, przeźroczyste dla aplikacji. Tworzymy nową tabelę:

CREATE TABLE deletes
(
id serial NOT NULL,
deleted_id bigint,
deleted_at timestamp without time zone NOT NULL,
CONSTRAINT deletes_pk PRIMARY KEY (id)
);

Do tej tabeli automagicznie będziemy dopisywać identyfikatory tych elementów, które zostały usunięte z tabeli albums oraz informacje kiedy zostały usunięte.

Teraz dodamy jeszcze funkcję:

CREATE OR REPLACE FUNCTION insert_after_delete()
RETURNS trigger AS
$BODY$BEGIN
IF tg_op = 'DELETE' THEN
INSERT INTO deletes(deleted_id, deleted_at)
VALUES (old.id, now());
RETURN old;
END IF;
END$BODY$
LANGUAGE plpgsql VOLATILE;

oraz trigger:

CREATE TRIGGER deleted_trg
BEFORE DELETE
ON albums
FOR EACH ROW
EXECUTE PROCEDURE insert_after_delete();

Sprawdzamy działanie

Zgodnie z planem, każdy usunięty wpis w tabeli albums powinien skutkować uzupełnieniem tabeli
deletes. Sprawdźmy więc. Usuwamy parę rekordów:

=> DELETE FROM albums where id < 37;
DELETE 2
=> SELECT * from deletes;
id | deleted_id |         deleted_at
----+------------+----------------------------
26 |         35 | 2010-12-23 13:53:18.034612
27 |         36 | 2010-12-23 13:53:18.034612
(2 rows)

Czyli baza działa.

Uzupełniamy plik konfiguracyjny DIH tak, by entity było zdefiniowane następująco:

<entity name="album" query="SELECT * from albums"
  deletedPkQuery="SELECT deleted_id as id FROM deletes WHERE deleted_at > '$'{dataimporter.last_index_time}'">

Dzięki temu przy imporcie przyrostowym DIH użyje atrybutu deletedPkQuery by pobrać identyfikatory tych dokumentów, które należy usunąć.

Sprytny czytelnik pewnie zacznie się zastanawiać, czy na pewno potrzebna jest nam kolumna z datą usunięcia rekordu. Przecież możemy usunąć wszystkie rekordy znalezione w tabeli deleted a następnie skasować zawartość tej tabeli. Teoretycznie to prawda, ale w przypadku problemu z serwerem indeksującym SOLR w naszym wypadku łatwo zastąpić go innym – jego stopień synchronizacji z bazą nie jest bardzo istotny – po prostu za następnym importem przyrostowym nastąpi synchronizacja z bazą. W opcji z kasowaniem zawartości deletes takie możliwości nie ma.

Wykonujemy teraz import przyrostowy wywołując adres: /solr/dataimport?command=delta-import
W logach powinna pojawić się linia podobna do tej:
INFO: {delete=[35, 36],optimize=} 0 2
Co oznacza, że DIH poprawnie usunął z indeksu te dokumenty, które usunęliśmy wcześniej z bazy.

Co to jest sharding?

Sharding oznacza podział danych na kilka części oraz przechowywanie i obróbkę tych danych niezależnie. Dodatkowa logika w ramach aplikacji pozwala na wybranie odpowiedniej części zbioru danych i/lub łączenie wyników z poszczególnych źródeł. W przypadku DIH i shardingu możemy mieć do czynienia z następującym przypadkiem:

• sharding po stronie źródło danych – czyli wiele lokalizacji / tabel zawierających poszczególne części zbioru danych
• sharding po stronie SOLR – czyli podzielenie danych ze źródła na wiele niezależnych instancji SOLR
• oba powyższe jednocześnie

W opisywanym przypadku mamy jeden zbiór danych i chcemy stworzyć wiele zbiorów (tzw. shardów) po stronie SOLR.

Kiedy stosować sharding?

Bardzo ważna kwestia: po co? W moim mniemaniu sharding bywa zbyt często nadużywany generując mnóstwo dodatkowych komplikacji i ograniczeń. Główny powód to duży wolumen danych, które powodują, że indeks SOLR nie mieści się w obrębie jednej maszyny. Jeśli tak nie jest – często oznacza to, że sharding jest zbędny. Kolejny powód to wydajność. Jednak sharding może tutaj pomóc tylko wtedy, gdy inne optymalizacje zawiodą a zapytania są na tyle skomplikowane, że sam narzut shardingu (przekazania zapytania do poszczególnych shardów i łączenie ich odpowiedzi) jest mniejszy niż zysk możliwy do uzyskania.

Dane testowe

Zakładamy jednak, że sharding jest nam potrzebny. W przykładzie poniżej użyłem danych z musicbrainz tworząc prostą tabelę postgresową:

Table "public.albums"

 Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------

 id     | integer | not null default nextval('albums_id_seq'::regclass)

 name   | text    | not null

 author | text    | not null

Indexes:

"albums_pk" PRIMARY KEY, btree (id)

W tabeli znajduje się 825661 rekordów. Podkreślam tutaj, że zarówno struktura jak i ilość danych jest na tyle małe, że praktyczna przydatność shardingu jest tu pomijalna.

Instalacja testowa

Do testów użyjemy trzech instancji SOLR. Wszystkie instancje są identyczne, różnica jest związana tylko z numerem portów (8983, 7872, 6761) – testy będą wykonywane na jednej fizycznej maszynie.

Definicja w schema.xml:

<fields>
 <field name="id" type="string" indexed="true" stored="true" required="true" />
 <field name="album" type="text" indexed="true" stored="true" multiValued="true"/>
 <field name="author" type="text" indexed="true" stored="true" multiValued="true"/>
</fields>
<uniqueKey>id</uniqueKey>
<defaultSearchField>album</defaultSearchField>

Definicja DIH w solrconfig.xml:

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
 <lst name="defaults">
  <str name="config">db-data-config.xml</str>
 </lst>
</requestHandler>

I plik DIH db-data-config.xml:

<dataConfig>
 <dataSource driver="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/shardtest" user="solr" password="secret" />
 <document>
  <entity name="album" query="SELECT * from albums">
   <field column="id" name="id" />
   <field column="name" name="album" />
   <field column="author" name="author" />
  </entity>
 </document>
</dataConfig>

W tym momencie każda instancja jest w stanie dokonać pełnego importu danych.

Zestawiamy sharding

Naszym celem jest takie zmodyfikowanie konfiguracji DIH by każda instancja indeksowała tylko „swoją” część danych. Najprościej zrobić to modyfikując zapytanie pobierające dane np w ten sposób:

SELECT * from albums where id % LICZBA_INSTANCJI = NUMER_INSTANCJI

gdzie:

• LICZBA_INSTANCJI – liczba serwerów SOLR przechowujących unikalne części zbioru danych
• NUMER_INSTANCJI – numer instancji (liczony od zera)

takie zapytanie nie gwarantuje nam dokładnie i idealnie równego podziału ale spełnia dwa konieczne warunki:

• dany rekord trafi zawsze na konkretną i zawszę tę samą instancję
• pojedynczy rekord trafi zawsze na tylko jedną instancję

czyli db-data-config.xml na każdej maszynie różni się teraz zapytaniem i wygląda na poszczególnych instancjach następująco:

• SELECT * from albums where id % 3 = 0
• SELECT * from albums where id % 3 = 1
• SELECT * from albums where id % 3 = 2

Sprawdzamy działanie

Po uruchomieniu wszystkich instancji SOLR na każdej wywołujemy adres:

/solr/dataimport?command=full-import

Po zakończeniu pracy DIH i wywołaniu:

/solr/dataimport?command=status

dostajemy w odpowiedzi od instancji odpowiednio:

• Added/Updated: 275220 documents.
• Added/Updated: 275221 documents.
• Added/Updated: 275220 documents.

Wykonując prostą operację dodawania widzimy, że we wszystkich instancjach łącznie mamy 825661 dokumentów, czyli tyle ile powinno tam być
Wykonajmy jeszcze zapytanie o wszystkie dokumenty, z wykorzystaniem shardingu wywołując na dowolnej instancji:

/solr/select/?q=*:*&shards=localhost:6761/solr,localhost:7872/solr,localhost:8983/solr

Wynik: 825661.

To działa!

W przykładach użyta została baza PostgeSQL zawierająca dane polskiej wikipedii. Testowa instancja solr została zdefiniowana jako rdzeń „wikipedia” i dostępna była pod adresem:

http://localhost:8983/solr/wikipedia/admin/

Konfiguracja solrconfig.xml

Konfiguracja sprowadza się do dodania dodatkowego requestHandlera. Parametr: config określa plik konfiguracyjny, w którym znajduje się definicja źródła danych.

 <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
  <lst name="defaults">
   <str name="config">db-data-config.xml</str>
  </lst>
</requestHandler>

Dzięki takiej definicji zyskujemy możliwość wywoływania adresu HTTP obsługującego import:

• /dataimport – w celu uzyskania aktualnego statusu
• /dataimport?command=reload-config – w celu ponownego odczytania konfiguracji
• /dataimport?command=full-import – w celu zlecenia rozpoczęcia pełnego indeksowania danych
• /dataimport?command=delta-import – w celu zlecenia rozpoczęcia indeksowania przyrostowego

(dla mojej konfiguracji pełen adres to: http://localhost:8983/solr/wikipedia/dataimport)

Powyżej widzimy dwie możliwości importowania danych: import pełny i przyrostowy.

Pełny import danych polega na każdorazowym wczytaniu wszystkich danych, które powinny znaleźć się w indeksie, podczas gdy import przyrostowy oznacza tylko dodanie i aktualizację w indeksie tych danych, które zmieniły się od ostatniego indeksowania. Pełny import zwykle trwa znacznie dłużej stąd prosty wniosek: jeśli czas pełnego indeksowania nie jest dla nas problemem – prawdopodobnie nie warto zawracać sobie głowy konfiguracją indeksowania przyrostowego, zwłaszcza, że nakłada ono  dodatkowe wymagania na strukturę źródła danych.

Warto zaznaczyć, że pełny import domyślnie rozpoczyna się od usunięcia istniejącego indeksu. Istnieje możliwość uniknięcia takiego zachowania poprzez dodanie parametru: clean=false.

Konfiguracja źródła danych

Konfiguracja polega na zdefiniowaniu zapytań pozwalających solr na pobieranie danych do indeksowania i zawiera się w pliku określonym przy definicji handlera (u nas: db-data-config.xml) W tym wpisie zaczniemy od zdefiniowania pełnego importu. Następnie, w kolejnej części artykułu rozbudujemy go o możliwość importowania przyrostowego.

Pełny import

<dataConfig>
  <dataSource driver="org.postgresql.Driver"
     url="jdbc:postgresql://localhost:5432/wikipedia"
     user="wikipedia"
     password="secret" />
  <document>
    <entity name="page" query="SELECT page_id, page_title from page">
      <field column="page_id" name="id" />
      <field column="page_title" name="name" />
      <entity name="revision" query="select rev_id from revision where rev_page=${page.page_id}">
        <entity name="pagecontent" query="select old_text from pagecontent where old_id=${revision.rev_id}">
          <field column="old_text" name="text" />
        </entity>
      </entity>
   </entity>
  </document>
</dataConfig>

Jak widzimy definicja źródła składa się z opisu sposobu połączenia do baz danych oraz opisu indeksowanego dokumentu. Import następuje zgodnie z następującym algorytmem:

1. Usuwany jest stary indeks (jeśli nie użyto parametru clean=false)
2. Solr po wywołaniu komendy indeksowania nawiązuje połączenie do bazy danych.
3. Definiowany jest kursor bazodanowy wykorzystujący zapytanie określone w argumencie „query” w głównej encji
4. Pobierana jest porcja danych
5. Dla każdego pobranego rekordu definiowane są zmienne postaci <nazwa encji>.<zwracana kolumna>, dzięki czemu do zwróconych wartości można odwołać się w encjach zagnieżdżonych
6. Wykonywane są zapytania z encji zagnieżdżonych
7. Encja może zawierać definicje pól. Dzięki temu Solr jest w stanie określić mapowanie kolumny z wyniku na pole dokumentu zdefiniowane w schema.xml
8. Dokument stworzony dzięki wartościom zwróconych przez zapytania jest dodawany do indeksu
9. Jeśli kursor posiada kolejne wyniki następuje skok do punktu 4.
10. Następuje zapisanie danych do pliku dataimport.properties, dane zostają zatwierdzone (commit) i wykonywana jest optymalizacja indeksu

Po uruchomieniu solr i wejściu na stronę: http://localhost:8983/solr/wikipedia/dataimport pojawiła sie odpowiedź:

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">idle</str>
  <str name="importResponse"/>
  <lst name="statusMessages"/>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>

Uwagę zwraca wpis: status: idle. Oznacza to, że nasz importer jest gotowy do pracy. W innym przypadku (np. Błąd poprawności XML konfiguracyjnego) dostaniemy opis wyjątku. Niestety na tym etapie nie są wykrywane jeszcze błędy związane np. z niewłaściwą definicją połączenia do bazy lub braku sterownika JDBC.

Wchodzimy więc na stronę: http://localhost:8983/solr/wikipedia/dataimport?command=full-import

To co powinniśmy otrzymać, to podobny jak wyżej XML. Jednak po ponownym wejściu na stronę: http://localhost:8983/solr/wikipedia/dataimport dostajemy już inny wynik.

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">busy</str>
  <str name="importResponse">A command is still running...</str>
  <lst name="statusMessages">
    <str name="Time Elapsed">0:1:15.460</str>
    <str name="Total Requests made to DataSource">39547</str>
    <str name="Total Rows Fetched">59319</str>
    <str name="Total Documents Processed">19772</str>
    <str name="Total Documents Skipped">0</str>
    <str name="Full Dump Started">2010-10-03 14:28:00</str>
  </lst>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>

Czyli importer pracuje.

Po pewnym czasie, zależnym od ilości indeksowanych danych i szybkości komputera otrzymamy:

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">idle</str>
  <str name="importResponse"/>
  <lst name="statusMessages">
    <str name="Total Requests made to DataSource">2118645</str>
    <str name="Total Rows Fetched">3177966</str>
    <str name="Total Documents Skipped">0</str>
    <str name="Full Dump Started">2010-10-03 14:28:00</str>
    <str name="">Indexing completed. Added/Updated: 1059322 documents. Deleted 0 documents.</str>
    <str name="Committed">2010-10-03 14:55:20</str>
    <str name="Optimized">2010-10-03 14:55:20</str>
    <str name="Total Documents Processed">1059322</str>
    <str name="Time taken ">0:27:20.325</str>
  </lst>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>

Jak widzimy indeksacja zakończyła się sukcesem.

W kolejnym odcinku spróbujemy dodać możliwość importowania przyrostowego.