schema – Solr.pl

Solr 4.2: Schema API

Rafał Kuć — Mon, 20 May 2013 10:11:50 +0000

Wraz z premierą Solr 4.2 dostaliśmy możliwość wykorzystania protokołu HTTP do pobierania informacji o strukturze indeksu Solr. Oczywiście, jeżeli ktoś potrzebował takiej funkcjonalności przez Solr 4.2 mógł pobrać plik schema.xml za pomocą odpowiedniego zapytania, przetworzyć go i wydobyć szukane informacje. Wraz z premierą Solr 4.2 dostaliśmy jednak bardzo wygodne narzędzie za pomocą którego jesteśmy w stanie wydobyć interesujące nas informacje bez konieczności przetwarzania całego pliku schema.xml.

Możliwości

Przyjrzymy się zatem nowemu API.

Zwracanie informacji w formacie XML

Bardzo dużo użytkowników Solr przyzwyczajonych jest do tego, iż dane z Solr zwracane są domyślnie w formacie XML, co nie jest prawdą w przypadku opisywanego API, którego domyślny format zwracanych danych to JSON. Jeżeli chcemy, aby powyżej opisane informacje zwracane były w formacie XML należy do każdego z wymienionych zapytań dodać parametr wt=xml, na przykład:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes?wt=xml'

Pobieranie zdefiniowanych pól

Zacznijmy od pobierania informacji na temat pól zdefiniowanych w indeksie. W tym celu udostępnione zostały dwie możliwości:

Pobieranie informacji na temat wszystkich pól
Pobieranie informacji na temat konkretnego pola

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fields'

W drugim przypadku wystarczy do powyższego zapytania dodać znak / oraz nazwę pola. Na przykład, aby pobrać dane na temat pola author należałoby wysłać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fields/author'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "fields":[{
      "name":"_version_",
      "type":"long",
      "indexed":true,
      "stored":true},
    {
      "name":"author",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"cat",
      "type":"string",
      "multiValued":true,
      "indexed":true,
      "stored":true},
    {
      "name":"category",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true,
      "uniqueKey":true},
    {
      "name":"url",
      "type":"text_general",
      "indexed":true,
      "stored":true},
    {
      "name":"weight",
      "type":"float",
      "indexed":true,
      "stored":true}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":0},
  "field":{
    "name":"author",
    "type":"text_general",
    "indexed":true,
    "stored":true}}

Pobieranie zdefiniowanych pól dynamicznych

Dokładnie tak samo, jak w powyższym przypadku wygląda sytuacja kiedy chcemy pobrać informacje na temat pól dynamicznych. Także i w tym przypadku mamy dwie możliwości:

Pobranie informacji na temat wszystkich pól dynamicznych
Pobranie informacji na temat konkretnego wzorca pola dynamicznego

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/dynamicfields'

W drugim przypadku, podobnie jak wcześniej, dodajemy znak /, a następnie wzorzec:

$curl 'http://localhost:8983/solr/collection1/schema/dynamicfields/random_*'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "dynamicfields":[{
      "name":"*_coordinate",
      "type":"tdouble",
      "indexed":true,
      "stored":false},
    {
      "name":"ignored_*",
      "type":"ignored",
      "multiValued":true},
    {
      "name":"random_*",
      "type":"random"},
    {
      "name":"*_p",
      "type":"location",
      "indexed":true,
      "stored":true},
    {
      "name":"*_c",
      "type":"currency",
      "indexed":true,
      "stored":true}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "dynamicfield":{
    "name":"random_*",
    "type":"random"}}

Pobieranie typów pól

Jak można się domyślać, podobnie jak w wyżej wymienionych przypadkach, tak samo w przypadku pobierania informacji na temat typów pól możemy dostać od Solr informacje na temat:

Wszystkich typów pól zdefiniowanych w pliku schema.xml
Pojedynczego zdefiniowanego typu

W pierwszym wypadku należy zadać następujące zapytanie:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes'

W drugim przypadku, na dokładnie takiej samej zasadzie dodajemy znak /, a następnie nazwę typu:

$curl 'http://localhost:8983/solr/collection1/schema/fieldtypes/text_gl'

Odpowiedź Solr na pierwsze zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":3},
  "fieldTypes":[{
      "name":"alphaOnlySort",
      "class":"solr.TextField",
      "sortMissingLast":true,
      "omitNorms":true,
      "analyzer":{
        "class":"solr.TokenizerChain",
        "tokenizer":{
          "class":"solr.KeywordTokenizerFactory"},
        "filters":[{
            "class":"solr.LowerCaseFilterFactory"},
          {
            "class":"solr.TrimFilterFactory"},
          {
            "class":"solr.PatternReplaceFilterFactory",
            "replace":"all",
            "replacement":"",
            "pattern":"([^a-z])"}]},
      "fields":[],
      "dynamicFields":[]},
    {
      "name":"boolean",
      "class":"solr.BoolField",
      "sortMissingLast":true,
      "fields":["inStock"],
      "dynamicFields":["*_bs",
        "*_b"]},
    {
      "name":"text_gl",
      "class":"solr.TextField",
      "positionIncrementGap":"100",
      "analyzer":{
        "class":"solr.TokenizerChain",
        "tokenizer":{
          "class":"solr.StandardTokenizerFactory"},
        "filters":[{
            "class":"solr.LowerCaseFilterFactory"},
          {
            "class":"solr.StopFilterFactory",
            "words":"lang/stopwords_gl.txt",
            "ignoreCase":"true",
            "enablePositionIncrements":"true"},
          {
            "class":"solr.GalicianStemFilterFactory"}]},
      "fields":[],
      "dynamicFields":[]},
    {
      "name":"tlong",
      "class":"solr.TrieLongField",
      "precisionStep":"8",
      "positionIncrementGap":"0",
      "fields":[],
      "dynamicFields":["*_tl"]}]}

Natomiast odpowiedź na zapytanie dotyczące pojedynczego pola wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2},
  "fieldType":{
    "name":"text_gl",
    "class":"solr.TextField",
    "positionIncrementGap":"100",
    "analyzer":{
      "class":"solr.TokenizerChain",
      "tokenizer":{
        "class":"solr.StandardTokenizerFactory"},
      "filters":[{
          "class":"solr.LowerCaseFilterFactory"},
        {
          "class":"solr.StopFilterFactory",
          "words":"lang/stopwords_gl.txt",
          "ignoreCase":"true",
          "enablePositionIncrements":"true"},
        {
          "class":"solr.GalicianStemFilterFactory"}]},
    "fields":[],
    "dynamicFields":[]}}

Jak widać ilość zwracanych informacji jest dość duża

Pobieranie informacji na temat sekcji copyField

Dodatkowo za pomocą opisywanego API jesteśmy w stanie pobrać informacje na temat sekcji copyField poprzez wysłanie następującego zapytania:

$curl 'http://localhost:8983/solr/collection1/schema/copyfields'

Odpowiedź na powyższe zapytanie jest następująca:

{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "copyfields":[{
      "source":"author",
      "dest":"text"},
    {
      "source":"cat",
      "dest":"text"},
    {
      "source":"content",
      "dest":"text"},
    {
      "source":"content_type",
      "dest":"text"},
    {
      "source":"description",
      "dest":"text"},
    {
      "source":"features",
      "dest":"text"},
    {
      "source":"author",
      "dest":"author_s",
      "destDynamicBase":"*_s"}]}

Przyszłość

W Solr 4.3 opisywane API zostało usprawnione oraz jest przygotowywane do umożliwienia zmian w strukturze indeksu za pomocą protokołu HTTP. Możemy zatem spodziewać się, iż w jednej z kolejnych wersji serwera wyszukiwania Solr otrzymamy możliwość łatwej zmiany struktury indeksu, przynajmniej takich, które nie będą powodować konfliktów z już zaindeksowanymi danymi.

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.

Aplikacja „sprzedaż samochodów” – Spatial Search, czyli wprowadzenie danych lokalizacyjnych (cz. 3)

Rafał Andrzejewski — Mon, 14 Mar 2011 08:13:38 +0000

Ilość ogłoszeń w naszej bazie rozrosła się do tego stopnia, że klienci zaproponowali dodanie nowej opcji przy filtrowaniu wyników wyszukiwania oraz nowej opcji sortowania. Mianowicie musimy dodać funkcjonalność, która pozwoli nam operować na danych związanych z lokalizacją auta w danym ogłoszeniu.

Analiza wymagań

Chcemy dodać dwie nowe funkcjonalności:

Zawężanie wyników wyszukiwania w taki sposób, aby możliwe było wyświetlenie tylko tych aut, które są położone nie dalej niż x kilometrów od określonego miejsca, gdzie x = 50,100,200,500,1000 km.
Sortowanie wyników wyszukiwania po odległości pomiędzy danym punktem, a lokalizacją auta z danego ogłoszenia.

W celu realizacji powyższych zadań, skorzystamy z funkcjonalności solr zwanej „Spatial Search”, która dostępna jest od wersji 3.1. Zmiany, które będziemy musieli wprowadzić, dotyczyć będą modyfikacji pliku schema.xml oraz danych wejściowych, do których dodamy informację o położeniu geograficznym każdego z aut. Na końcu zostanie nam już tylko odpowiednie złożenie zapytań.

Zmiany w schema.xml

Definicja nowych typów pól:
- pierwsza definicja to nic innego jak kolejny typ liczbowy – double:
- druga definicja zaś wykorzystuje specjalną klasę „solr.LatLonType”, która pozwoli nam na zaindeksowanie danych geograficznych wykorzystując pole dynamiczne o suffixie „_coordinate”:
Definicja nowych pól:
- pole, które będzie wykorzystywane do gromadzenia informacji o nazwie miejscowości, z którego pochodzi auto:
- pole „loc” posłuży nam do zaindeksowania danych lokalizacyjnych:
- pole dynamiczne będzie wykorzystywane wewnętrznie do gromadzenia informacji, które wprowadzimy do pola „loc”:

Analiza danych wejściowych

W celu prezentacji sposobu modyfikacji nowych danych, weźmy próbkę 5-ciu ogłoszeń z miast:

Koszalin
- szerokość geograficzna: 54.12
- długość geograficzna: 16.11
Białystok
- szerokość geograficzna: 53.08
- długość geograficzna: 23.09
Szczecin
- szerokość geograficzna: 53.25
- długość geograficzna: 14.35
Gdańsk
- szerokość geograficzna: 54.21
- długość geograficzna: 18.40
Warszawa
- szerokość geograficzna: 52.15
- długość geograficzna: 21.00

Dane lokalizacyjne wprowadzamy do pola „loc” wpisując szerokość geograficzną danego miasta oraz po przecinku jego długość. Nasze dane mogą wyglądać zatem tak:


   
      1
      Audi
      80
      2008
      9774
      2000
      92467
      green
      false
      Koszalin
      54.12,16.11
   
   
      2
      Audi
      A8
      2009
      9078
      1000
      31369
      black
      false
      Białystok
      53.08,23.09
   
   
      3
      Audi
      TT
      1997
      1109
      1299
      116987
      silver
      true
      Szczecin
      53.25,14.35
   
   
      4
      BMW
      Seria 7
      2007
      140000
      3000
      418000
      green
      false
      Gdańsk
      54.21,18.40
   
   
      5
      Chevrolet
      TrailBlazer
      2007
      140000
      3000
      418000
      green
      false
      Warszawa
      52.15,21.00

Tworzymy zapytania

Dane lokalizacyjne mamy w indeksie, zatem zostało nam już tylko złożyć odpowiednie zapytania, które zrealizują nasze nowe funkcjonalności. Załóżmy, że będziemy wyszukiwać ogłoszenia znajdując się w mieście Białystok, które jest położone w odległości ok. 200 km od miasta Warszawa, ok. 400 km od miasta Gdańsk, ok. 550 km od miasta Koszalin oraz ok. 650 km od miasta Szczecin.

W celu realizacji punktu 1 z analizy wymagań, dodajemy do żądania nowe zapytanie filtrujące:

...&fq={!geofilt sfield=loc}&pt=53.08,23.09&d=50

gdzie:

sfield – nazwa pola, do którego wprowadzaliśmy nasze dane lokalizacyjne.
pt – współrzędne punktu startowego, w naszym wypadku są to współrzędne miasta Białystok.
d – dystans o jaki chcemy zawęzić wyniki wyszukiwania. Podstawiając kolejno wartości 50,100,200,500,1000 możemy zrealizować nasze wymagania.

Przykład:

Zapytanie:

q=*:*&fq={!geofilt sfield=loc}&pt=53.08,23.09&d=200

Wyniki wyszukiwania:


   
      Białystok
      black
      false
      1000
      2
      Audi
      31369
      A8
      9078.0
      2009
   
   
      Warszawa
      green
      false
      3000
      5
      Chevrolet 
      418000
      TrailBlazer
      140000.0
      2007

Świetnie, w wynikach nie mamy ogłoszeń z miast Koszalin, Gdańsk oraz Szczecin, gdyż te miasta leżą w odległości ponad 200 km od miasta Białystok.

W celu realizacji punktu 2 z analizy wymagań, wykorzystamy możliwość sortowania wyników wyszukiwania z użyciem funkcji geodist. Tworzymy następujące zapytanie:

...&sfield=loc&pt=53.08,23.09&sort=geodist()+desc

Przykład sortowania wyników wyszukiwania po odległości, rozpoczynając od miasta Białystok:

Zapytanie:

q=*:*&sfield=loc&pt=53.08,23.09&sort=geodist()+asc

Wyniki wyszukiwania:


   
      Białystok
      black
      false
      1000
      2
      Audi
      31369
      A8
      9078.0
      2009
   
   
      Warszawa
      green
      false
      3000
      5
      Chevrolet 
      418000
      TrailBlazer
      140000.0
      2007
   
   
      Gdańsk
      green
      false
      3000
      4
      BMW
      418000
      Seria 7
      140000.0
      2007
   
   
      Koszalin
      green
      false
      2000
      1
      Audi
      92467
      80
      9774.0
      2008
   
   
      Szczecin
      silver
      true
      1299
      3
      Audi
      116987
      TT
      1109.0
      1997

Zgadza się! Wymagania zostały zrealizowane.

Podsumowanie

Po raz kolejny udało nam się sprostać oczekiwaniom naszych klientów. Tym razem dodaliśmy funkcjonalności związane z lokalizacją geograficzną aut, które pozwolą użytkownikom na zawężanie oraz sortowanie wyników wyszukiwania wykorzystując odległości geograficzne. Pełen sukces.

Aplikacja „sprzedaż samochodów” – WordDelimiterFilter i PatternReplaceFilter, czyli na ratunek jakości wyników (cz. 2)

Rafał Kuć — Mon, 14 Feb 2011 08:03:28 +0000

W pierwszej części naszego cyklu stworzyliśmy pewną standardową strukturę indeksu, odpowiednio konfigurując plik schema.xml. Przy takiej konfiguracji, na pierwsze skargi klientów, dotyczących działania silnika wyszukiwawczego nie trzeba było długo czekać. Dlaczego wpisując w kryteria wyszukiwania frazę „audi a” nie otrzymuję ofert związanych z autami „Audi A6” lub „Audi A8” ? Wpisałem „Honda crv” – 0 wyników. „Suzuki maruti” – też nic. Czy takich ofert nie ma w bazie z ogłoszeniami ? Otóż są, ale konfiguracja typu pola, po którym wyszukujemy (pole „content” – typ „text”) uniemożliwia w obecnym stanie znalezienie tych ogłoszeń przy zastosowaniu powyższych zapytań. Na pomoc rusza nam chyba najbardziej popularny filtr – WordDelimiterFilter, oraz PatternReplaceFilter, których odpowiednia konfiguracja pozwoli sprostać naszym potrzebom.

Analiza wymagań

W celu dokonania analizy danych, które wchodzą w skład pola, po którym wyszukujemy, weźmy następującą próbkę, na której oprzemy naszą konfigurację:

Marka: Audi
Modele: 80, 90, A6, A8, TT

Marka: BMW
Modele: M3, M5, Seria 7, Seria 8, X1, X3

Marka: Chevrolet
Modele: TrailBlazer

Marka: Citroen
Modele: C-Crosser, C3 Pluriel, C4 Picasso

Marka: Ford
Modele: C-MAX, S-MAX

Marka: Honda
Modele: Accord, CR-V, FR-V, HR-V

Marka: Kia
Modele: Cee’d

Marka: Suzuki
Modele: Alto/Maruti

Nazwy marek są prostymi słowami, z którymi aktualna konfiguracja (WhitespaceTokenizer + LowerCaseFilter) poradzi sobie bez problemu. Problem pojawia się przy modelach aut, które zawierają dodatkowe znaki oraz separatory, które często ignorujemy przy wyszukiwaniu. Pogrupujmy sobie powyższą próbkę ze względu na charakterystykę danych:

Nazwy modeli, które nie wymagają dodatkowych filtrów i obecna konfiguracja jest wystarczająca – 80, 90, TT, Seria 7, Seria 8, Accord
Nazwy modeli, których nazwy składają się z cyfr i liter, których to rozdzielenie jest pożądane – A6, A8, M3, M5, X1, X3, C3 Pluriel, C4 Picasso. Chcielibyśmy móc wyszukiwać powyższe modele wpisując tylko literę lub tylko cyfrę, ale również wpisując całą nazwę modelu.
Modele, które mają zmianę wielkości znaków w nazwie – TrailBlazer. Chcielibyśmy znaleźć taki model wpisując „trail”, „blazer”, „trailBlazer”, „trailblazer”.
Nazwy modeli, które zawierają separatory, które chcemy ignorować (wpisując nazwę modelu jako pełny wyraz – uwzględniając separator lub nie – oraz po częściach nazwy modelu, które taki separator generuje) – C-Crosser, C-MAX, S-MAX, CR-V, FR-V, HR-V, Alto/Maruti.
Przykład: chcielibyśmy znaleźć ogłoszenie z modelem „C-MAX” wpisująć frazy „c”, „max”, „c-max” „cmax”.
Celowo w punkcie 4 pominąłem model „Cee’d”. Ten model przy wyszukiwaniu chcielibyśmy traktować trochę inaczej, a mianowicie uniemożliwić znalezienie ogłoszenia przy wpisaniu „cee” lub „d”. Traktujemy nazwę „Cee’d” tylko i wyłącznie jako jeden wyraz, czyli realizujemy wyszukiwanie tylko dla przypadków „cee’d” oraz „ceed”.

Konfiguracja WordDelimiterFilter

Na podstawie opisanej charakterystyki dobierzmy takie wartości atrybutów filtra WordDelimiterFilter, aby wszystkie powyższe wymagania zostały spełnione:

WordDelimiterFilter jest w tym wypadku zbędny, do realizacji wymagań z pkt 1 wystarczy WhitespaceTokenizer + LowerCaseFilter.
W celu realizacji wymagań z pkt 2 należy zadbać o odpowiednie ustawienie następujących atrybutów:
- generateWordParts=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części słów
- generateNumberParts=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części liczbowych
- splitOnNumerics=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość rozdzielania literek od liczb
W celu realizacji wymagań z pkt 3, musimy ustawić następujące atrybuty:
- generateWordParts=”1″
- splitOnCaseChange=”1″ – wartość musi być ustawiona na „1”, jeżeli chcemy mieć możliwość generowania części słów przy przejściu z dużej litery na małą i odwrotnie
W celu realizacji wymagań z pkt 4, ustawiamy następujące atrybuty:
- generateWordParts=”1″
- catenateWords=”1″ – wartość musi być ustawiona na „1”, abyśmy mogli dodatkowo ignorować separatory, poprzez łączenie wyrazów, które są takim separatorem rozdzielone

Zatem konfiguracja naszego filtra wygląda następująco:

Dodatkowo okazuje się, że domyślna wartość atrybutów „splitOnNumerics” oraz „splitOnNumerics” to właśnie „1”. Pozostałe atrybuty, których nie wykorzystujemy (poza „stemEnglishPossessive”), mają domyślną wartość na „0”. Konfiguracja naszego filtra zatem upraszcza się do następującej postaci:

Co zrobić z punktem nr. 5 naszej charakterystyki danych? Ustaliliśmy, że nie chcielibyśmy dla tego przypadku traktować znaku ” ’ ” jako separatora, a tak właśnie by się stało przy powyższej konfiguracji. Może zatem użyć w filtrze opcji, która zachowa to słowo w stanie niezmienionym, czyli wykorzystać atrybut protected=”protwords.txt” i dodać słowo „Cee’d” do pliku protwords.txt? No tak, ale co z faktem, że chcemy móc wyszukać taki dokument, przy wpisaniu frazy „ceed” ? Najlepiej by było zająć się tym przypadkiem w oddzielnym filtrze, a do filtra WordDelimiterFilter wprowadzić wartość, której ten filtr nie będzie musiał już analizować.

Konfiguracja PatternReplaceFilter

Filtr PatternReplaceFilter zastosujemy przed filtrem WordDelimiterFilter. Za pomocą PatternReplaceFilter będziemy mogli po prostu wyciąć znak „'” z nazwy tego specyficznego modelu, zastępując go pustym znakiem. W ten sposób, do filtra WordDelimiterFilter trafi nam nazwa „Ceed”, która przy obecnej konfiguracji nie zastosuje na takiej wartości żadnej modyfikacji. Filtry będą miały taką samą konfigurację przy indeksowaniu jak i przy wyszukiwaniu, zatem użytkownik będzie w stanie znaleźć ogłoszenie z marką „Cee’d” przy wpisaniu frazy „cee’d” jak i „ceed”:

Wizualizacja działania nowej konfiguracji typu pola „text”

Podsumowując, nasz typ „text” zmienił się następująco:

Wykorzystajmy panel administracyjny solr, aby zobaczyć na przykładzie każdego z punktów, czy konfigurując nasz typ tak jak powyżej, otrzymamy to, czego oczekujemy:

(Model: „80”) Tak jak oczekiwaliśmy, wprowadzone filtry nie mają wpływu na dane charakterystyczne dla punktu 1.
(Model: „A8”) WordDelimiterFilter rozdzielił nam liczbę od wyrazu.
(Model: „TrailBlazer”)WordDelimiterFilter rozdzielił nam „trail” od „Blazer”. Dodatkowo mamy możliwość wyszukiwania po „trailblazer”. Super.
(Model: „CR-V”) WordDelimiterFilter rozdzielił nam wyraz po separatorze (w tym wypadku „-„). Dodatkowo mamy możliwość wyszukiwania po nazwie modelu nie uwzględniając separatora („crv”).
(Model: „Cee’d”) PatternReplaceFilter zamienił nam „Cee’d” na „Ceed” a WordDelimiterFilter zachował tę wartość. O to nam chodziło.

Podsumowanie

W drugiej części naszego cyklu użyliśmy dwóch nowych filtrów w celu poprawy jakości wyników wyszukiwania. Na przykładzie naszych „samochodowych” danych omówiliśmy użycie WordDelimiterFilter oraz PatternReplaceFilter. Poprawka wprowadzona, klient usatysfakcjonowany … ale na jak długo ?

Aplikacja „sprzedaż samochodów” – projektowanie schema.xml dla naszych potrzeb (cz. 1)

Rafał Andrzejewski — Mon, 31 Jan 2011 08:01:46 +0000

Podstawowym plikiem konfiguracyjnym solr, który jest niejako łącznikiem pomiędzy tym czego potrzebujemy, a tym co rozumie solr, jest plik schema.xml. Dobre zaprojektowanie schema.xml jest głównym czynnikiem warunkującym poprawne funkcjonowanie wyszukiwarki, która będzie w stanie zrealizować wszystkie wymagania, jakie przed nią stawiamy. Zacznijmy zatem kolejny cykl artykułów, poświęconych projektowaniu pliku schema.xml jak i również wszystkich składników wchodzących w skład zdefiniowanych przez nas typów pól.

Analiza wymagań

Wyobraźmy sobie, że chcemy wykorzystać silnik solr w celu dodania wyszukiwarki ogłoszeń samochodowych do naszego serwisu. Serwis nasz jest w tym momencie dosyć prymitywny i przetrzymuje podstawowe informacje opisujące właściwości każdego wystawionego na sprzedaż samochodu:

marka
model
rok produkcji
cena
pojemność
przebieg
kolor
czy uszkodzony

Chcielibyśmy w tym momencie zaprojektować najprostszy plik konfiguracyjny, który pomoże odpowiednio zaindeksować dane z powyższych pól. Zanim jednak przystąpimy do rzeźbienia pliku schema.xml, odpowiedzmy sobie na siedem podstawowych pytań, dotyczących każdego z tych pól:

1. Jaki typ ?

Ustalamy typ każdego pola:

marka – pole tekstowe
model – pole tekstowe
rok produkcji – pole liczbowe
cena – pole liczbowe, zmiennoprzecinkowe
pojemność – pole liczbowe
przebieg – pole liczbowe
kolor – pole tekstowe
czy uszkodzony – pole logiczne

Co nam to mówi ?

Będziemy potrzebowali definicji typów: string, boolean, int, float.

2. Czy po polu ma się odbywać wyszukiwanie ?

Ustalamy, z których pól będą wykorzystywane informacje, w celu znalezienia odpowiednich ogłoszeń samochodowych. W naszym serwisie będą to 3 pola: marka, model oraz rok produkcji.

Co nam to mówi ?

Pewnie będziemy potrzebowali kolejnego typu pola, który będzie poddawany działaniu różnych filtrów, zwiększających nasze szanse znalezienia interesującego nas dokumentu. Stworzymy sobie dodatkowe pole tego typu, po którym będziemy wyszukiwać i wrzucimy tam dane z wszystkich 3 powyższych pól.

3. Czy sortowalne lub grupowalne ?

Serwis nasz przewiduje sortowanie wyników wyszukiwania po polach: model, rok produkcji, cena oraz przebieg. Chcielibyśmy również móc grupować wyniki wyszukiwania (faceting) po polach marka, model, rok produkcji oraz kolor.

Co nam to mówi ?

Pola tekstowe, po których sortujemy lub grupujemy nie powinny być poddawane działaniu filtrów, które mogą nam rozdzielić na tokeny wartości w tych polach. Zależy nam jednak na tym, aby wszystkie wartości były zapisane małymi literami, tak aby wielkość liter nie wpływała na sortowanie czy też grupowanie. Będzie trzeba stworzyć nowy typ pola, który nam to umożliwi.

4. Czy wykorzystywane przy filtrowaniu ?

Na stronie wyszukiwania ogłoszeń chcemy mieć możliwość zawężenia wyników wyszukiwania, poprzez ustawianie zakresów na polach: rok produkcji, cena, pojemność oraz przebieg.

Co nam to mówi ?

Dobierzmy zatem takie typy dla tych pól, aby filtrowanie po zakresach było jak najbardziej wydajne.

5. Czy zostały mi pola, które nie zostały wymienione w punktach 2, 3 lub 4 ?

Okazuje się, że na polu „czy wymagane” nie będziemy przeprowadzać żadnych „operacji”.

Co nam to mówi ?

Ustawiamy atrybut „indexed” dla takiego pola na wartość false.

6.Czy wymagane ?

W naszym serwisie zakładamy, że polami wymaganymi dla każdego ogłoszenia będą pola marka, model oraz rok produkcji. Nie chcemy mieć dokumentów, które nie mają zdefiniowanych co najmniej tych trzech pól.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „required” na true.

7. Czy wartości pól mają być pobierane z indeksu w oryginalnym stanie?

Informację ze wszystkich pól chcielibyśmy wyciągnąć bezpośrednio z wyników wyszukiwania i zaprezentować klientowi serwisu.

Co nam to mówi ?

Przy definiowaniu tych pól musimy pamiętać o ustawieniu wartości atrybutu „stored” na true.

Dodajmy definicje typów pól

Odpowiedzieliśmy już sobie na nasze niezbędne pytanie, wyciągnęliśmy wnioski, więc czas wprowadzić je w życie. Dodajmy do schemy typy pól:

Dodajemy zwykły typ string, który nie jest poddawany żadnej analizie, przyda się np. jako typ dla pola reprezentującego unikalny identyfikator dokumentu.

Dodajemy typ boolean.

Dodajemy typy dla pól liczbowych. Pamiętamy, że zależy nam na typach, które zagwarantują nam szybsze wykonywanie zapytań po zakresach. Skorzystajmy zatem z typów tint oraz tfloat:

Stwórzmy teraz typ tekstowy, który będzie wykorzystywany przez pole zbiorcze po którym będziemy wyszukiwać. Załóżmy prosty typ, który rozdzieli nam wszystkie tokeny po białych znakach, po czym zamieni wszystkie litery na małe.

Potrzebujemy jeszcze typu dla pól, które będą sortowalne/grupowalne:

KeywordTokenizer tak naprawdę nie tokenizuje wartości którą dostaje na wejściu, czyli niezmieniona wartość zostanie poddana działaniu filtra LowerCaseFilterFactory po czym filtr TrimFilterFactory zadba o to, aby zostały usunięte wszelkie białe znaki, znajdujące się na początku lub na końcu wartości.

Dodajmy definicje pól

Identyfikator dokumentu:

Marka oraz model:

Nasuwa się pytanie, dlaczego atrybuty indexed dla pól marka oraz model są ustawione na false? Przecież są to pola, które wykorzystywane są przy wyszukiwaniu, sortowaniu i grupowaniu. Zgadza się. Jednakże w celach wyszukiwania przekopiujemy wartości z tych pól do pola zbiorczego, a w celach sortowania/grupowania przekopiujemy wartości z tych pól do pól o typie „lowercase”.
Pola, do których będziemy kopiować wartości marek oraz modeli samochodów, a które to będą wykorzystywane do sortowania/grupowania po tych polach:

Pole zbiorcze, do którego będą kopiowane wartości z pól, po których chcemy wyszukiwać. Jako że do tego pola kopiujemy wartości z więcej niż jednego pola, musimy ustawić wartość atrybutu „multiValued” na true:

Rok produkcji:

Cena:

Pojemność:

Przebieg:

Kolor:

Pamiętamy o wartości false dla atrybutu „indexed” dla pola „Czy uszkodzony”:

Zostało nam przekopiować wartości z pól, po których wyszukujemy do jednego pola zbiorczego:

… i ponownie pola marki i modelu do pól, po których będziemy sortować:

Czy coś jeszcze do schemy?

Uzupełnijmy scheme jeszcze o 3 elementy:
Klucz unikalny dokumentu

id

Domyślne pole, po którym wyszukujemy

content

Domyślny operator, wykorzystywany przez parser zapytań do solr. Ustawmy go na wartość „AND”.

Mamy zatem gotowy plik konfiguracyjny schema.xml! Zobaczmy jak wygląda w całej okazałości:

Podsumowując

W dzisiejszym wpisie udało nam się stworzyć plik schema.xml, który pomoże nam tak zaindeksować dane, abyśmy mogli zrealizować funkcjonalności wyszukiwania ogłoszeń naszego serwisu sprzedaży samochodów. Chcielibyśmy jednak rozwijać nasz serwis, co będzie się wiązało z dodatkowymi zmianami w pliku konfiguracyjnym … i nie tylko. W następnych artykułach z cyklu „sprzedaż samochodów” będziemy realizować nowe wymagania oraz wprowadzać kolejne modyfikacje.

5 grzechów podczas projektowania indeksu Solr

Rafał Kuć — Mon, 30 Aug 2010 13:04:31 +0000

Zgodnie z obietnicą złożoną we wpisie na temat pliku schema.xml prezentujemy dzisiaj wpis dotyczący najczęściej popełnianych błędów podczas projektowania indeksu Solr, czyli podczas tworzenia i modyfikowania pliku schema.xml dla naszego wdrożenia. Zapraszam do dalszej lektury.

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.

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.