Osobiście, jestem zwolennikiem rozwiązań, które mają jak najmniejszą szansę powodować problemy – po prostu lubię w nocy spać. Do takich rozwiązań zaliczam usunięcie indeksu po modyfikacji jego struktury, a następnie pełną indeksację danych. Zdaję sobie jednak sprawę, że nie zawsze takie rozwiązanie jest akceptowalne. Kiedy zatem nie jesteśmy zmuszeni do usunięcia indeksu, a kiedy nie usunięcie indeksu naraża nas na ewentualne problemy z poprawnym działaniem Solr ?

Odpowiedź na pytanie zależy od tego, co zmieniliśmy w strukturze indeksu. Zmiany takie, można podzielić na trzy obszary obejmujące większość ze zmian jakie możemy dokonać w strukturze indeksu:

• Dodanie/usunięcie nowego pola
• Modyfikacja podobieństwa (Similarity)
• Modyfikacja typu pola

Dodanie/usunięcie nowego pola

W przypadku pierwszego typu modyfikacji sprawa jest dość prosta – jeżeli dodamy do schema.xml (bądź usuniemy) nowe pole, nie ma konieczności usuwania całego indeksu przed ponowną indeksacją. Solr poradzi sobie z dodaniem nowego pola, do aktualnego indeksu. Oczywiście, należy sobie zdawać sprawę, iż dokumenty, które nie będą po tej operacji ponownie zaindeksowane nie będą automatycznie uaktualnione.

Modyfikacja podobieństwa

W drugim przypadku, czyli przy ewentualnej zmianie klasy odpowiedzialnej za Similarity także nie musimy usuwać indeksu po zmianie schema.xml. Jednak w odróżnieniu od poprzedniego przykładu, do poprawnego wyliczania współczynnika score, a tym samym do poprawnego sortowania będzie konieczna ponowna indeksacja wszystkich dokumentów wcześniej obecnych w indeksie.

Modyfikacja typu pola

Zatrzymajmy się na trzecim przypadku. Załóżmy, że modyfikujemy nieznacznie pole w indeksie z prozaicznej przyczyny – przestaje interesować nas normalizacja jego długości. Ustawiamy sobie omitNorms=”true” (zakładam, iż wcześniej było omitNorms=”false”). Indeksujemy ponownie wszystkie dokumenty, Lucene łączy nam indeksy i co się okazuje – dalej w połączonych segmentach mamy dalej znormalizowane informacje o długości pola. Coś poszło nie tak. To jest właśnie ten przypadek kiedy konieczne jest usunięcie indeksu po zmianie jego struktury, a przed pełną indeksacją. Na pierwszy rzut oka wygląda, iż jest to bardzo mała zmiana, jednak zastanawiając się dalej, mamy takie, a nie inne skutki. Warto pamiętać, iż niektóre z właściwości pól są nadpisywane przez inne, tak jak w przypadku normalizacji długości – jeżeli w jednym segmencie pole będzie posiadało normalizację, a w drugim nie, to po połączeniu segmentów otrzymamy jeden, w którym to pole będzie posiadało normalizację.

Co to ?

CheckIndex jest narzędziem dostępnym w bibliotece Lucene, które pozwala sprawdzić i stworzyć nowe pliki segmentów, które nie zawierają problematycznych wpisów. Oznacza to, że narzędzie to, przy niewielkich stratach własnych jest w stanie naprawić zepsuty indeks, a tym samym uchronić nas przed koniecznością odtwarzania kopii zapasowej (oczywiście o ile ją mamy) lub też indeksowania pełnego wszystkich dokumentów, które przechowywaliśmy w Solr.

Od czego zacząć ?

Należy pamiętać, iż zgodnie tym co znajdujemy w Javadoc’ach, narzędzie to jest dalej eksperymentalne i może się zmienić. Dlatego, przed uruchomieniem powinniśmy stworzyć kopię indeksu. Dodatkowo, warto wiedzieć, iż narzędzie analizuje indeks bajt po bajcie, a tym samym w przypadku dużych indeksów czas analizy i naprawy może być duży. Ważne jest, aby nie uruchamiać narzędzia z opcją -fix w chwili kiedy korzysta z niego Solr lub inna aplikacja oparta o bibliotekę Lucene. Na koniec, należy zdawać sobie sprawę, iż uruchomienie narzędzia w trybie naprawiającym indeks może spowodować usunięcie z tegoż dokumentów, które zapisane są w problematycznych obszarach indeksu.

Jak uruchamiać ?

W celu uruchomienia narzędzia przechodzimy do katalogu, gdzie znajdują się pliki biblioteki Lucene i uruchamiamy następujące polecenie:

java -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex SCIEZKA_DO_INDEKSU -fix

W moim wypadku wyglądało to następująco:

java -cp lucene-core-2.9.3.jar -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex E:\\Solr\\solr\\data\\index\\ -fix

Po pewnym czasie dostałem następujące informacje:

Opening index @ E:\Solr\solr\data\index\

Segments file=segments_2 numSegments=1 version=FORMAT_DIAGNOSTICS [Lucene 2.9]
1 of 1: name=_0 docCount=19
compound=false
hasProx=true
numFiles=11
size (MB)=0,018
diagnostics = {os.version=6.1, os=Windows 7, lucene.version=2.9.3 951790 - 2010-06-06 01:30:55, source=flush, os.arch=x86, java.version=1.6.0_23, java.vendor=Sun Microsystems Inc.}
no deletions
test: open reader.........OK
test: fields..............OK [15 fields]
test: field norms.........OK [15 fields]
test: terms, freq, prox...OK [900 terms; 1517 terms/docs pairs; 1707 tokens]
test: stored fields.......OK [232 total field count; avg 12,211 fields per doc]
test: term vectors........OK [3 total vector count; avg 0,158 term/freq vector fields per doc]

No problems were detected with this index.

Co oznacza, że indeks był poprawny i nie było konieczności przeprowadzania żadnych czynności naprawczych. Dodatkowo, można się dowiedzieć kilku ciekawych rzeczy na temat indeksu

Zepsuty indeks

A co dzieje się w przypadku zepsutego indeksu ? Jest tylko jeden sposób – sprawdźmy. W tym celu uszkodziłem jeden z plików indeksu i uruchomiłem narzędzie CheckIndex. Poniżej cytuje, co zobaczyłem na konsoli:

Opening index @ E:\Solr\solr\data\index\

Segments file=segments_2 numSegments=1 version=FORMAT_DIAGNOSTICS [Lucene 2.9]
1 of 1: name=_0 docCount=19
compound=false
hasProx=true
numFiles=11
size (MB)=0,018
diagnostics = {os.version=6.1, os=Windows 7, lucene.version=2.9.3 951790 - 2010-06-06 01:30:55, source=flush, os.arch=x86, java.version=1.6.0_23, java.vendor=Sun Microsystems Inc.}
no deletions
test: open reader.........FAILED
WARNING: fixIndex() would remove reference to this segment; full exception:
org.apache.lucene.index.CorruptIndexException: did not read all bytes from file "_0.fnm": read 150 vs size 152
at org.apache.lucene.index.FieldInfos.read(FieldInfos.java:370)
at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:71)
at org.apache.lucene.index.SegmentReader$CoreReaders.<init>(SegmentReader.java:119)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:652)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:605)
at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:491)
at org.apache.lucene.index.CheckIndex.main(CheckIndex.java:903)

WARNING: 1 broken segments (containing 19 documents) detected
WARNING: 19 documents will be lost

NOTE: will write new segments file in 5 seconds; this will remove 19 docs from the index. THIS IS YOUR LAST CHANCE TO CTRL+C!
5...
4...
3...
2...
1...
Writing...
OK
Wrote new segments file "segments_3"

Jak widać, wszystkie 19 dokumentów, które znajdowały się w indeksie zostały usunięte. Jest to ekstremalny przypadek, ale warto sobie zdawać sprawę, że to narzędzie może tak zadziałać.

Na koniec

Pamiętając o podstawowych założeniach związanych z używaniem narzędzia CheckIndex może się okazać, że przyjdzie taki moment, kiedy ułatwi nam ono ponowne uruchomienie Solr w przypadku awarii związanej z indeksem, a tym samym unikniemy rwania włosów z głowy i pytań „Kiedy był zrobiony ostatni backup ?”.

W chwili obecnej, opisywane narzędzia dostępne są jedynie w branchu o nazwie branch_3x repozytorium SVN, jednak planowana jest migracja tych funkcjonalności także do wersji 4.x.

Ale o co chodzi ?

Korzystając z technik kończenia wyszukiwania po z góry ustalonym czasie, nie oglądając się na ilość wyników wyszukiwania, trafiamy w pewnym momencie na problem jakości wyników wyszukiwania. Zamiast otrzymywania najlepszych, w kontekście danego wyszukiwania, wyników otrzymujemy je w sposób losowy. Oznacza to, że nie jesteśmy w stanie zapewnić, iż użytkownik korzystający z systemu dostanie najlepiej dopasowane wyniki. Oczywiście dalej mówimy o sytuacji, kiedy kończymy wyszukiwanie po z góry ustalonym czasie i nie dajemy Solr możliwości zebrania wszystkich dokumentów pasujących do zapytania.

Po co mi to ?

Kiedy kończenie wyszukiwania po z góry ustalonym czasie może być przydatne ? Istnieje wiele zastosowań takiego wyszukiwania. Wyobraźmy sobie, że nasze wdrożenie składa się z wielu oddzielnych shardów, które operują na dużej ilości danych każdy. W przypadku zadania zapytania, każdy z shardów musi być odpytany o odpowiednie dokumenty, następnie wszystkie wyniki muszą być złożone razem i wyświetlone użytkownikowi końcowemu (oczywiście nie musi być to człowiek, może być to aplikacja). Co jednak, jeżeli każdy z shardów potrzebuje bardzo długiego czasu na przetworzenie wszystkich wyników wyszukiwania, a nas interesują np. tylko te dodane w ostatnim czasie (np. w ostatnim tygodniu). Tutaj właśnie mamy możliwość wcześniejszego zakończenia wyszukiwanie – zakładając, że bardziej interesują nas dokumenty dodane poprzedniego dnia, niż dwa tygodnie wcześniej.

Jak to zrealizować ?

Powyższy przykład pokazuje, przypadek kiedy możemy zastosować wyszukiwanie zakończone po określonym z góry czasie. Jednak zastanawiając się dalej trafiamy na pewien problem – aby posortować wyniki wyszukiwania Solr musi pobrać je wszystkie. Czyli stosując w zapytaniu parametr sort=added+desc, aby uzyskać poprawnie posortowane dokumenty i tak każdy z shardów musiałby zwrócić wszystkie wyniki wyszukiwania (oczywiście wszystkie w rozumieniu pojedynczego indeksu), czyli nici z wcześniejszego zakończenia wyszukiwania ? Nie do końca. Tutaj właśnie z pomocą przychodzi nam narzędzie IndexSorter, które do tej pory dostępne było tylko w projekcie Nutch, a od niedawna dostępne jest także w Lucene i Solr. Dzięki temu narzędziu możemy posortować wstępnie indeks według odpowiadającego nam parametru. Zatem sortując indeks malejąco po dacie dodania dokumentu, Solr pobierałby najpierw dokumenty, które zostały dodanie najpóźniej, a tym samym mielibyśmy możliwość zakończenia wyszukiwania po z góry ustalonym czasie.

Korzystanie z IndexSorter

Co zrobić, aby skorzystać z narzędzia IndexSorter ? Prawdę powiedziawszy, nie jest to nic skomplikowanego. Należy jednak pamiętać, że w momencie publikacji tego wpisu narzędzie to dostępne jest tylko w branchu o nazwie branch_3x. Aby posortować indeks na podstawie jakiegoś pola należy wywołać następującą komendę z linii poleceń (oczywiście pamiętając o odpowiednim umiejscowieniu biblioteki lucene-misc-3.1.jar z klasą IndexSorter – po wybudowaniu projektu znajdziemy ją w katalogu lucene/build/contrib/misc):

java IndexSorter KATALOG_ŹRÓDŁOWY KATALOG_DOCELOWY NAZWA_POLA

Poszczególne parametry oznaczają:

• KATALOG_ŹRÓDŁOWY – katalog z indeksem który chcemy posortować,
• KATALOG_DOCELOWY – katalog, gdzie zostanie zapisany posortowany indeks,
• NAZWA_POLA – pole, po jakim zostanie posortowany indeks.

Jeżeli wszystko przebiegło poprawnie to na ekranie powinniśmy dostać informację w stylu:

IndexSorter: done, 896 total milliseconds

Na koniec

Moim zdaniem Lucene i Solr dostały właśnie bardzo ciekawą funkcjonalność, która może być wykorzystana wszędzie tam, gdzie ilość danych jest bardzo duża, czas odpowiedzi nie może przekroczyć pewnej granicy, a wyniki poza pierwszymi (pierwszych 100, czy 1000) nie są znaczące. Wszystkich bardziej zainteresowanych tematem sortowania indeksu oraz technikami dzielenia indeksu zapraszam do obejrzenia slajdów z prezentacji pod tytułem „Munching and Crunching: Lucene Index Post-Processing” (slajdy) prowadzonej Andrzeja Białeckiego na konferencji Lucene Eurocon 2010, który omawiał te tematy.

Plik schema.xml składa się z kilku części:

• wersji,
• definicji typów,
• definicji pól,
• sekcji copyField,
• dodatkowych definicji.

Wersja

Pierwszą rzeczą na jaką natrafimy w pliku schema.xml jest wersja. Jest to informacja o tym jak Solr ma traktować niektóre z atrybutów w pliku schema.xml. Definicja ta wygląda następująco:

<schema name="example" version="1.3">

Należy pamiętać, iż nie jest to definicja wersji z punktu widzenia naszego projektu. W tym momencie Solr obsługuje 4 wersje pliku schema.xml:

• 1.0 – nie istniał atrybut multiValued, wszystkie pola były domyślnie wielowartościowe.
• 1.1 – wprowadzono atrybut multiValued, domyślna wartość atrybutu to false.
• 1.2 – wprowadzono atrybut omitTermFreqAndPositions, domyślna wartość to true dla wszystkich pól, oprócz pól tekstowych.
• 1.3 – usunięto opcjonalną możliwość kompresji pól.

Definicje typów

Definicje typów można logicznie podzielić na dwie oddzielne sekcje – typy proste i typy złożone. Typy proste w przeciwieństwie do typów złożonych nie posiadają zdefiniowanych filtrów i tokenizera.

Typy proste

Kolejnymi definicjami, na jakie trafimy w pliku schema.xml są definicje typów z których składać się będzie nasz indeks. Każdy z typów opisany jest szeregiem atrybutów, które opisują zachowanie danego typu. Na początek kilka atrybutów, które opisują każdy typ:

• name – nazwa typu, atrybut wymagany,
• class – klasa, która odpowiada za implementację typu. Warto pamiętać, że klasy standardowo dostarczane z Solr będą miały nazwy z przedrostkiem 'solr’.

Oprócz dwóch wymienionych powyżej, typy mogą mieć jeszcze następujące atrybuty opcjonalne:

• sortMissingLast – atrybut określający, jak mają być traktowane wartości w polu opartym o ten typ podczas sortowania. W przypadku ustawienia na wartość true na końcu listy wyników zawsze będą dokumenty nie posiadające wartości w polach oparty o dany typ – bez względu na to, czy sortujemy rosnąco, czy malejąco. Domyślna wartość atrybutu to false. Atrybut może być stosowany, tylko w przypadku typów, które przez Lucene traktowane są jako string.
• sortMissingFirst – atrybut określający, jak mają być traktowane wartości w polu opartym o ten typ podczas sortowania. W przypadku ustawienia na wartość true na początku listy wyników zawsze będą dokumenty nie posiadające wartości w polach oparty o dany typ – bez względu na to, czy sortujemy rosnąco, czy malejąco. Domyślna wartość atrybutu to false. Atrybut może być stosowany, tylko w przypadku typów, które przez Lucene traktowane są jako string.
• omitNorms – atrybut określający, czy podczas analizy mają być wyliczane normalizacje.
• omitTermFreqAndPositions – atrybut określający, czy podczas analizy ma być pomijane wyliczanie częstotliwości poszczególnych termów oraz ich pozycji w dokumencie.
• indexed – atrybut określający, czy pola oparte o ten typ mają przechowywać oryginalne wartości.
• positionIncrementGap – co ile pozycji (a dokładniej pozycji tokenów w strumieniu tokenów) ma być wyliczane trafienie.

Warto pamiętać, iż w przypadku domyślnego ustawienia atrybutów sortMissingLast i sortMissingFirst Lucene będzie stosować zachowanie polegające na umieszczeniu dokumentów z pustymi wartościami na początku w przypadku sortowania rosnącego, a na końcu listy wyników w przypadku sortowania malejącego.

Kolejną opcją typów prostych, jednak dotyczącą tylko nowych typów liczbowych (typy Trie*Field), jest następujący atrybut:

• precisionStep – atrybut określający ilość bitów precyzji. Im większa ilość bitów, tym szybsze zapytania oparte o przedziały liczbowe. Wiąże się to jednak także ze wzrostem wielkości indeksu, jako, że indeksowanych jest więcej wartości. Ustawienie wartości atrybutu na 0 wyłącza funkcjonalność indeksowania na różnych precyzjach.

Przykładem zdefiniowanego typu prostego może być na przykład:

<fieldType name="string" class="solr.StrField" sortMissingLast="true" omitNorms="true"/>

Typy złożone

Oprócz typów prostych, plik schema.xml może zawierać typy składające się z tokenizera oraz filtrów. Tokenizer odpowiada za podzielenie zawartości pola na tokeny, natomiast filtry odpowiadają za dalszą analizę. Na przykład typ, który odpowiada za przechowywanie tekstów w języku polskim, mogłoby składać się z tokenizera odpowiadającego za dzielenie słów na podstawie białych znaków oraz kropek i przecinków, a przykładowe filtry mogłyby odpowiadać za sprowadzanie powstałych tokenów do małych liter, dalsze dzielenie tokenów (np. na podstawie myślników), a następnie sprowadzanie tokenów do formy podstawowej.

Typy złożone, tak jak typy proste, mają swoją nazwę (atrybut name) oraz klasę która odpowiada za implementację (atrybut class). Mogą się także charakteryzować innymi atrybutami opisanymi w przypadku typów prostych (na tych samych zasadach). Dodatkowo jednak typy złożone mogą posiadać definicję tokenizera oraz filtrów, które mają być wykorzystane na etapie indeksowania, jak i na etapie zadawania zapytań. Jak zapewne większość wie, dla danego etapu (indeksowanie, bądź zadawanie zapytań) może być zdefiniowany szereg filtrów oraz tylko i wyłącznie jeden tokenizer. Przykładowo, tak wygląda definicja typu tekstowego w przykładowej instalacji dostarczanej razem z Solr:

<fieldType name="text" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="true">
   <analyzer type="index">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
      <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
   </analyzer>
   <analyzer type="query">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
      <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
   </analyzer>
</fieldType>

Warto zauważyć dodatkowy atrybut dla pola tekstowego:

• autoGeneratePhraseQueries

Atrybut odpowiada za to, jak zachowują się filtry przy rozdzielaniu tokenów. Niektóre z filtrów (taki, jak np. WordDelimiterFilter) pozwala na dzielenie słów np. za pomocą znaku myślnika. Ustawienie atrybutu na wartość true (wartość domyślna) powoduje automatyczne generowanie zapytań o frazę, czyli tzw. PhraseQueries. Oznacza to, że np. dla słowa „wi-fi”, które zostanie rozbite przez filtr WordDelimiterFilter na słowa „wi” oraz „fi” zostanie wygenerowane zapytanie pole:"wi fi", a nie zapytanie pole:wi OR pole:fi. Należy jednak pamiętać, iż atrybut ten potrafi gubić się w przypadku pól, które mają zdefiniowany tokenizer dzielący słowa inaczej, niż po białych znakach.

Wracając do definicji typu. Jak widać, przykład który podałem ma dwie główne sekcje:

<analyzer type="index">

oraz

<analyzer type="query">

Pierwsza z sekcji odpowiada za definicję typu, która będzie użyta w przypadku indeksowania dokumentów, druga sekcja odpowiada za definicję typu używaną w przypadku zapytań do pól opartych o ten typ. Warto wiedzieć, że jeżeli chcemy korzystać z tej samej definicji dla indeksowania i zadawania zapytań, możemy zrezygnować z obu sekcji. Wtedy nasza definicja typu wyglądałaby na przykład następująco:

<fieldType name="text" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="true">
   <tokenizer class="solr.WhitespaceTokenizerFactory"/>
   <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
   <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
   <filter class="solr.LowerCaseFilterFactory"/>
   <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
   <filter class="solr.PorterStemFilterFactory"/>
</fieldType>

Jak już wspomniałem w definicji każdego typu złożonego występuje jeden tokenizer oraz szereg filtrów (choć nie koniecznie). Nie będę opisywał poszczególnych opcji każdego z filtrów oraz tokenizerów dostępnych standardowo z Solr. Informacje te dostępne są pod następującym adresem: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters.

Na koniec chciałem dodać ważną rzecz. Począwszy od Solr 1.4 tokenizer nie musi być pierwszym mechanizmem jaki zajmuje się analizą danego pola – zostały wprowadzone nowe filtry tzw. Char Filters, które operują na nietokenizowanym jeszcze polu i dopiero później przekazują wynik do tokenizera. Warto o tym wiedzieć, ponieważ może się to kiedyś przydać.

Typy wielowymiarowe

Na koniec zostawiłem sobie mały dodatek – opis nowości w Solr 1.4 – pól wielowymiarowych, czyli pól składających się z szeregu innych pól. Ogólnie można powiedzieć, iż założenie tego typu pól było proste – umożliwić przechowywanie w Solr par, trójek, czy większej ilości powiązanych ze sobą danych, takich jak na przykład współrzędne geograficzne punktu. W praktyce realizowane jest to za pomocą pól dynamicznych, jednak pozwolę sobie nie wgłębiać się w szczegóły implementacji. Przykładowa definicja typu, składającego się z dwóch pól:

<fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/>

Oprócz standardowych atrybutów name oraz class pojawiają się dwa nowe:

• dimension – ilość wymiarów (atrybut wykorzystywany przez klasę solr.PointType).
• subFieldSuffix – przyrostek, jaki będzie dodawany do pól dynamicznych wchodzących w skład pola. Ważne aby pamiętać, iż tak zdefiniowane pole stworzy trzy pola w indeksie – pole oparte o typ location oraz dwa pola dynamiczne.

Definicje pól

Definicje pól to kolejna sekcja w pliku schema.xml, to sekcja, która teoretycznie powinna interesować nas najbardziej podczas projektowania indeksu Solr. Z reguły znajdziemy tutaj dwa rodzaje definicji pól:

1. Pola statyczne
2. Pola dynamiczne

Pola te są różnie traktowane przez Solr. Pierwszy typ pól, to pola, które dostępne są pod jedną nazwą. Pola dynamiczne, jako nazwę mają proste wyrażenie regularne (nazwa zaczynająca się lub kończąca się znakiem '*’). Należy pamiętać, iż Solr najpierw wybiera pole statyczne, a dopiero później pola dynamiczne. Dodatkowo w przypadku nazwy pola, która pasuje do więcej, niż jednej definicji, wybrane zostanie pole z dłuższą definicją nazwy.

Wracając do definicji pól (zarówno statycznych, jak i dynamicznych), składają się one z następujących atrybutów:

• name – nazwa pola (atrybut wymagany).
• type – typ pola, czyli jeden z typów zdefiniowanych wcześniej (atrybut wymagany).
• indexed – czy pole ma być indeksowane (ustawiamy na wartość true, jeżeli chcemy wyszukiwać lub sortować po tym polu).
• stored – czy mają być przechowywane oryginalne wartości (ustawiamy na wartość true, jeżeli chcemy pobierać oryginalną wartość przekazaną do tego pola).
• omitNorms – czy ma być pomijane wyliczanie norm dla tego pola (ustawiamy na wartość true dla pól, dla których będziemy stosować wyszukiwanie pełnotekstowe).
• termVectors – ustawiamy na wartość true w przypadku kiedy chcemy przechowywać tzw. wektor termów. Domyślna wartość parametru, to wartość false. Niektóre funkcjonalności wymagają ustawienia tego parametru na true (np. MoreLikeThis, czy FastVectorHighlighting).
• termPositions – ustawiamy na wartość true, jeżeli chcemy aby wraz z wektorem przechowywane były pozycje termów. Ustawienie na wartość true spowoduje wzrost wielkości indeksu.
• termOffsets – ustawiamy na wartość true, jeżeli chcemy aby wraz z wektorem termów przechowywane były przesunięcia. Ustawienie na wartość true spowoduje wzrost wielkości indeksu.
• default – domyślna wartość jaka ma zostać nadana polu, jeżeli w dokumencie nie było podanej żadnej wartości.

Poniżej przykładowe definicje pól:

<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="includes" type="text" indexed="true" stored="true" termVectors="true" termPositions="true" termOffsets="true" />
<field name="timestamp" type="date" indexed="true" stored="true" default="NOW" multiValued="false"/>
<dynamicField name="*_i" type="int" indexed="true" stored="true"/>

Na koniec jeszcze dodatkowa informacja o której warto pamiętać. Oprócz atrybutów wymienionych powyżej przy definicji pola możemy nadpisywać atrybuty jakie zostały zdefiniowane dla typu (np. czy pole ma być wielowartościowe – z powyższego przykładu pole o nazwie timestamp). Czasami taka funkcjonalność może się przydać, jeżeli potrzebujemy specyficznego pola, którego typ różni się nieznacznie od innego typu (tak jak w przykładzie – tylko atrybutem multiValued). Oczywiście należy pamiętać o ograniczeniach nakładanych na poszczególne atrybuty związane z typami.

Sekcja copyField

W skrócie sekcja odpowiadająca za kopiowanie zawartości pól do innych pól. Definiujemy z jakiego pola ma być skopiowana zawartość oraz do jakiego pola. Należy pamiętać, iż kopiowana jest zawartość przed analizą, czy wartość jaka przychodzi w danych. Przykład definicji copyField:

<copyField source="category" dest="text"/>

W gwoli ścisłości, występujące atrybuty oznaczają:

• source – pole źródłowe,
• dest – pole docelowe.

Dodatkowe definicje

1. Zdefiniowanie unikalnego klucza

Definicja unikalnego klucza, dzięki któremu możliwe będzie jednoznaczne zidentyfikowanie dokumentu. Zdefiniowanie unikalnego klucza nie jest konieczne, ale jest zalecane. Przykładowa definicja:

<uniqueKey>id</uniqueKey>

2. Zdefiniowanie domyślnego pola wyszukiwania

Sekcja odpowiadająca za zdefiniowanie domyślnego pola, w którym Solr ma wyszukiwać w przypadku kiedy nie zostało podane żadne pole. Przykładowa definicja:

<defaultSearchField>content</defaultSearchField>

3. Zdefiniowanie domyślnego operatora logicznego

Sekcja odpowiadająca za definicje domyślnego operatora logicznego, który będzie używany, jeżeli nie zostanie podany żaden operator logiczny. Przykładowa definicja wygląda w następujący sposób:

<solrQueryParser defaultOperator="OR"/>

Możliwe wartości to: OR oraz AND.

4. Zdefiniowanie podobieństwa

Na koniec zostaje nam zdefiniowanie podobieństwa, jakie będziemy wykorzystywać. Jest to raczej temat na inny wpis, należy jednak wiedzieć, iż w razie konieczności mamy możliwość zmiany domyślnego podobieństwa (aktualnie w trunku Solr są już dwie klasy obsługujące podobieństwo). Przykładowa definicja wygląda następująco:

<similarity class="pl.solr.similarity.CustomSimilarity" />

Kilka słów na koniec

Powyżej przedstawione informacje powinny dać pewien wgląd na temat jakim jest plik schema.xml oraz za co odpowiadają poszczególne sekcje w tym pliku. W niedługim czasie postaram się napisać, czego wystrzegać się podczas projektowania indeksu.