filtr – Solr.pl

Solr: tworzenie własnego filtra

Rafał Kuć — Mon, 14 May 2012 21:30:18 +0000

Czasami to co oferują Lucene i Solr mogą okazać się niewystarczające. Wtedy musimy sami rozszerzyć możliwości w/w i przygotować kawałek własnego kodu. W dzisiejszym wpisie postaram się pokazać, jak przygotować własny filtr i jak użyć go w Solr.

Wersja Solr

Poniższy tutorial dotyczy Solr 3.6. Uaktualniona wersja tego tutoriala pojawi się w momencie premiery Solr 4.0.

Założenia

Na potrzeby tego wpisu załóżmy, iż potrzebujemy filtra, który umożliwi nam odwrócenie dowolnego napisu. Zatem, jeżeli na wejściu dostajemy napis „solr.pl”, to na wyjściu chcemy otrzymać „lp.rlos”. Nie jest to może najtrudniejszy przykład funkcjonalności, ale na potrzeby wpisu wystarczy. We wpisie pomijam kwestie przygotowania sobie środowiska, kompilacji kodu, budowania biblioteki i tym podobnych.

Informacja dodatkowa

Kod, który będzie pokazany został stworzony, aby mógł działać w oparciu o Solr w wersji 3.6, ale nie powinno być problemów, aby został wykorzystany z Solr 4, aczkolwiek może być konieczna lekka modyfikacja kodu (jeżeli zmieni się coś w przyszłości w chwili wypuszczenia Solr).

Czego potrzebujemy

Aby nasz filtr mógł zostać wykorzystany w Solr potrzebujemy dwóch klas. Po pierwsze potrzebujemy implementacji właściwego filtra, która będzie realizować właściwą funkcjonalność. Po drugie konieczna będzie implementacji fabryki filtrów, która będzie odpowiedzialna za tworzenie i inicjalizację naszych filtrów. Zatem do dzieła.

Filtr

Aby zaimplementować nasz filtr skorzystamy z klasy TokenFilter z pakietu org.apache.lucene.analysis i rozszerzymy ją nadpisując metodę incrementToken. Metoda ta zwraca wartość typu boolean. Założenie jest takie, że jeżeli w strumieniu jest jeszcze token do dalszego przetwarzania metoda powinna zwrócić wartość true, jeżeli natomiast nie zostało już nic do przetworzenia metoda zwraca false. Implementacja filtra mogłaby wyglądać następująco:

package pl.solr.analysis;

import java.io.IOException;

import org.apache.lucene.analysis.TokenFilter;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;

public final class ReverseFilter extends TokenFilter {
  private CharTermAttribute charTermAttr;

  protected ReverseFilter(TokenStream ts) {
    super(ts);
    this.charTermAttr = addAttribute(CharTermAttribute.class);
  }

  @Override
  public boolean incrementToken() throws IOException {
    if (!input.incrementToken()) {
      return false;
    }

    int length = charTermAttr.length();
    char[] buffer = charTermAttr.buffer();
    char[] newBuffer = new char[length];
    for (int i = 0; i < length; i++) {
      newBuffer[i] = buffer[length - 1 - i];
    }
    charTermAttr.setEmpty();
    charTermAttr.copyBuffer(newBuffer, 0, newBuffer.length);
    return true;
  }
}

Wyjaśnienia niektórych elementów implementacji

Kilka słów wyjaśnienia, do implementacji pokazanej powyżej:

Linia 9 – klasa, która rozszerza klasę TokenFilter powinna być oznaczona jako final (wymagania stawiane przez Lucene).
Linia 10 – atrybut strumienia tokenów, który umożliwia pobranie oraz modyfikację tekstu z jakiego składa się dany term. Nasz filtr jest w stanie wykorzystywać wiele atrybutów strumienia, np. pozycję tokena w strumieniu, czy payload’ami. Listę klas implementujących interfejs Attribute można znaleźć w dokumentacji API Lucene (np. http://lucene.apache.org/core/3_6_0/api/all/org/apache/lucene/util/Attribute.html).
Linie 12 – 15 – konstruktor przyjmujący jako argument strumień tokenów oraz dodający (linia 14) do naszego filtra odpowiedni atrybut strumienia tokenów.
Linie 18 – 30 – implementacja metody incrementToken realizującej właściwe odwracanie napisów.
Linie 19 – 21 – sprawdzenie, czy został jakiś token w strumieniu i jeżeli nie został, to zwrócenie wartości false.
Linia 23 – pobranie właściwej wielkości bufora, którego zawartość to napis, który chcemy odwrócić.
Linia 24 – pobranie bufora, którego zawartość to napis który chcemy odwrócić. Tekst termu przechowywany jest jako tablica typu char i dlatego najbardziej wydajnym rozwiązaniem jest właśnie operacja na tej tablicy, a nie na obiekcie typu String.
Linie 25 – 28 – stworzenie nowego bufora oraz odwracanie aktualnego.
Linia 29 – oczyszczenie oryginalnego bufora (konieczne w przypadku korzystania z metod append).
Linia 30 – skopiowanie zmian z powrotem do bufora, czyli tak naprawdę zamienienie tego, który pobraliśmy w linii 23, na ten, który został już przetworzony.
Linia 31 – zwrócenie wartości true, aby poinformować, iż w buforze jest token do dalszego przetwarzania.

Fabryka

Tak jak wspomniałem wcześniej, aby móc skorzystać z naszego, wyżej zaimplementowanego filtra, konieczna jest implementacja fabryki. Ze względu na to, że nie mamy żadnych specjalnych opcji konfiguracyjnych, sama implementacja będzie dość prosta i zostanie oparta o klasę BaseTokenFilterFactory z pakietu org.apache.solr.analysis. Sama implementacja mogłaby wyglądać następująco:

package pl.solr.analysis;

import org.apache.lucene.analysis.TokenStream;
import org.apache.solr.analysis.BaseTokenFilterFactory;

public class ReverseFilterFactory extends BaseTokenFilterFactory {
  @Override
  public TokenStream create(TokenStream ts) {
    return new ReverseFilter(ts);
  }
}

Jak widać sama implementacja jest prosta i wymaga od nas nadpisania metody create w której tworzymy nasz filtr i zwracamy go. Nic bardziej prostego.

Konfiguracja

Po skompilowaniu i przygotowaniu biblioteki w formacie jar, kopiujemy ją do katalogu, gdzie Solr będzie ją widział. Możemy to uzyskać np. tworząc katalog lib w katalogu domowym Solr, a następnie dodać odpowiedni wpis do pliku solrconfig.xml, np. taki:

Następnie zmieniamy plik schema.xml dodając nasz filtr do jednego z typów, na przykład w następujący sposób:

Warto zauważyć, iż w w atrybucie class znacznika filter podajemy pełną nazwę pakietu oraz nazwę klasy implementującej fabrykę, a nie implementującą filtr. To ważne, inaczej Solr nie będzie w stanie stworzyć filtra.

Działanie

Poniżej zrzut ekranu z panelu administracyjnego Solr ilustrujący działanie filtra:

Podsumowanie

Jak widać na powyższym przykładzie, implementacja własnego filtra nie jest rzeczą bardzo skomplikowaną. Oczywiście, po raz kolejny podkreślę, iż pokazany przykład jest bardzo prosty, dlatego też sama implementacja należy do prostych. Mam nadzieję, iż po przeczytaniu tego artykułu tworzenie własnych filtrów do Solr będzie łatwiejsze

Solr filtry: PatternReplaceCharFilter

Marek Rogoziński — Mon, 09 May 2011 17:45:06 +0000

Kontynuując przeglad filtrów dostępnych w Solr dziś przyglądamy się pracy PatternReplaceCharFilter.

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.:

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:

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.

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.

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.

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.

Kilka słów o optymalizacji – filter cache

Rafał Kuć — Mon, 07 Feb 2011 08:02:49 +0000

Dzisiejszy wpis poświęcony został jednemu z typów cache w Solr – filter cache. Postaram się przedstawić do czego służy, jak go skonfigurować i jak go optymalnie wykorzystywać. Zapraszam do lektury.

Co przechowuje

Zacznijmy od środka. FilterCache przechowuje nieuporządkowany zbiór identyfikatorów dokumentów. Oczywiście nie są to identyfikatory zdefiniowanie w pliku schema.xml jako unikalny klucz, a wewnętrzne identyfikatory dokumentów używane przez Lucene i Solr – warto o tym pamiętać.

Do czego służy

Głównym zadaniem filterCache jest przechowywanie wyników związanych z wykorzystaniem filtrów. Aczkolwiek nie jest to jego jedyne zastosowanie. Oprócz tego cache ten może służyć jako pomoc przy facetingu (w przypadku korzystania z metody TermEnum) oraz do sortowania w przypadku określenia opcji na true w pliku solrconfig.xml.

Definicja

Standardowa definicja filterCache wygląda następująco:

Dostępne są następujące opcje konfiguracyjne:

class – klasa odpowiadająca za implementację. Do filterCache polecam korzystanie z solr.FastLRUCache, który charakteryzuje się większą wydajnością w przypadku większej ilości operacji GET, niż PUT.
size – maksymalna ilość wpisów jaka może znaleźć się w cache’u.
initialSize – początkowa wielkość cache’u.
autowarmCount – ilość wpisów jaka będzie przepisywana podczas rozgrzewania ze starego cache’u do nowego.
minSize – wartość określająca do jakiej ilości wpisów Solr będzie próbował redukować cache w przypadku pełnego uzupełnienia.
acceptableSize – jeżeli Solr nie będzie w stanie sprowadzić ilości wpisów do tej określonej za pomocą parametru minSize, to wartość acceptableSize będzie tą, do której będzie dążył jako kolejnej.
cleanupThread – wartość domyślna to false. W przypadku ustawienia na true do czyszczenia cache’u będzie wykorzystywany oddzielny wątek.

W większości przypadków wykorzystanie parametrów size, initialSize oraz autowarmCount jest w zupełności wystarczające.

Jak skonfigurować

Wielkość cache’u powinna być określana na podstawie zapytań, które wysyłane są do Solr. Maksymalna wielkość filterCache powinna być przynajmniej tak duża jak ilość filtrów (wraz z wartościami) jaką wykorzystujemy. Oznacza to, że jeżeli nasza aplikacja charakteryzuje się, w zadanym okresie czasu, wykorzystaniem np. 2000 różnych filtrów (parametrów fq wraz z wartościami), to parametr size powinien być ustawiony na wartości minimum 2000.

Efektywne wykorzystanie

Jednak samo skonfigurowanie cache’u to nie koniec – ważne, aby zapytania potrafiły to wykorzystać. Weźmy na przykład zapytanie:

q=nazwa:solr+AND+kategoria:ksiazka+AND+dzial:ksiazki

Na pierwszy rzut oka zapytanie jest jak najbardziej poprawne. Jest z nim jednak jeden problem – nie korzysta z filterCache. Całe zapytanie zostanie obsłużone przez queryResultCache i stworzy w nim pojedynczy wpis. Zmodyfikujemy je trochę i zadajmy je w następujący sposób.

q=nazwa:solr&fq=kategoria:ksiazka&fq=dzial:ksiazki

Co się stanie teraz ? Tak jak w poprzednim wypadku, stworzony zostanie jeden wpis w queryResultCache oraz dwa wpisy w filterCache. Dlaczego jest to ważne ? Weźmy kolejne zapytanie:

q=nazwa:lucene&fq=kategoria:ksiazka&fq=dzial:ksiazki

To zapytanie stworzyłoby kolejny wpis w queryResultCache oraz wykorzystałoby dwa już istniejące w filterCache wpisy, a tym samym Solr skróciłbym czas wykonania zapytaniai oszczędziłby operacji I/O na indeksie.

Jeżeli natomiast wykonalibyśmy zapytanie w postaci:

q=nazwa:lucene+AND+kategoria:ksiazka+AND+dzial:ksiazki

Solr nie byłby w stanie wykorzystać żadnych informacji z cache’u i musiałby w celu zalezienia wyników pobierać wszystkie informacje z indeksu Lucene.

Kilka słów na koniec

Jak widać, samo skonfigurowanie cache’u w poprawny sposób nie gwarantuje tego, że Solr będzie w stanie go wykorzystać. To od tego jak zadajemy zapytania zależy, jak wydajny w docelowym wdrożeniu będzie Solr. Warto o tym pamiętać podczas planowania wdrożenia.

Co to jest schema ?

Rafał Kuć — Mon, 16 Aug 2010 14:07:45 +0000

Jednym z plików konfiguracyjnych opisujących każde wdrożenie Solr jest plik schema.xml. Opisuje on jedną z najważniejszych rzeczy dotyczącą wdrożenia – strukturę indeksu. Informacje zawarte w tym pliku pozwalają kontrolować, jak zachowuje się Solr podczas indeksowania danych, czy też zadawania zapytań do odpowiednich pól. Schema.xml to jednak nie tylko sama struktura indeksu, to także szczegółowe informacje o typach danych, które mają duży wpływ na zachowanie Solr, a z reguły są traktowane po macoszemu. Tym wpisem postaram się przybliżyć składowe pliku schema.xml.

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:

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:

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:

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:

oraz

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:

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:

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:

Pola statyczne
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:

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:

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:

id

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:

content

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:

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:

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.