Przykład

Popatrzmy na następujący przykład:

<dataConfig>
  <dataSource type="FileDataSource" />
  <document>
    <entity
      name="document"
      processor="FileListEntityProcessor"
      baseDir="/home/import/data/2011-06-27"
      fileName=".*\.xml
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:

<dataSource
  type="FileDataSource"
  basePath="/home/import/input"
  encoding="utf-8"/>
dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:

<dataConfig>
  <script><![CDATA[
    function CategoryPieces(row) {
      var pieces = row.get('category').split('/');
      var arr = new Array();
      for (var i=0; i < pieces.length; i++) {
        row.put('category_level_' + i, pieces[i].trim());
        arr[i] = pieces[i].trim();
      }
      row.put('category_level_max', (pieces.length - 1).toFixed());
      row.put('category', arr.join('/'));
      return row;
  }
  ]]></script>
  <dataSource type="FileDataSource" />
  <document>
    <entity
      name="document"
      processor="FileListEntityProcessor"
      baseDir="/home/import/data/2011-06-27"
      fileName=".*\.xml
Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
"
      recursive="false"
      rootEntity="false"
      dataSource="null">
      <entity
        processor="XPathEntityProcessor"
        url="
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
"

      recursive="false"

      rootEntity="false"

      dataSource="null">

      <entity

        processor="XPathEntityProcessor"

        transformer=”script:CategoryPieces”

        url="
Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
"

      recursive="false"

      rootEntity="false"

      dataSource="null">

      <entity

        processor="XPathEntityProcessor"

        url="
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>
Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
"

      recursive="false"

      rootEntity="false"

      dataSource="null">

      <entity

        processor="XPathEntityProcessor"

        url="
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
{document.fileAbsolutePath}"

        useSolrAddSchema="true"

        stream="true">

      </entity>

    </entity>

  </document>

</dataConfig>
Objaśnienie przykładu
W porównaniu z przykładami z wcześniejszych części pojawiło się wykorzystanie źródła danych typu FileDataSource. Przykład pełnego wywołania:


dodatkowe, nieobowiązkowe atrybuty są w zasadzie oczywiste:

basePath – podaje katalog względem którego będzie określane położenie plików podane w tagu „entity”
encoding – określa kodowanie plików (domyślnie: kodowanie domyślne systemu)

Po definicji źródła następuje definicja dokumentu z dwoma, zagnieżdżonymi opisami encji.
Zadaniem głównej encji jest wygenerowanie listy plików. Do tego celu wykorzystywany jest FileListEntityProcessor. Encja jest w zasadzie samowystarczalna i do jej działania nie jest potrzebne żadne źródło danych (dlatego: dataSource=”null”). Atrybuty wykorzystywane to:

fileName (wymagane) – wyrażenie regularne, określające które pliki należy pobrać
recursive – czy pliki szukane będą również w podkatalogach (domyślnie: nie)
rootEntity – określa czy dane z encji są traktowane jako źródło dokumentów. Ponieważ nie chcemy indeksować listy plików, które dostarcza encja, tylko zawartość dokumentów, to pole musi być ustawione na wartość „false”. Dzięki temu następna zdefiniowana encja automatycznie zostanie potraktowana jako główna i jej dane (dokumenty) zostaną zindeksowane.
baseDir (wymagane) katalog, w którym poszukiwane będą pliki
dataSource – w tym wypadku „null”, gdyż encja nie korzysta z żadnego źródła. (W zasadzie w solr > 1.3 parametr ten można po prostu pominąć)
excludes – wyrażenie regularne określające, które pliki pominąć przy wyszukiwaniu
newerThan – określa datę w formacie: YYYY-MM-dd HH:mm:ss Może to być również napis w pojedynczych cudzysłowach np. 'NOW – 7DAYS' lub dostępna zmienna zawierająca datę: ${nazwa}. Określa, że tylko nowsze pliki od tej daty będą brane po uwagę
olderThan – jw. tylko dla starszych plików
biggerThan – określa rozmiar pliku – tylko większe pliki będą brane pod uwagę
smallerThan – jw. dla mniejszych plików

Mając już listę plików, do akcji wchodzi kolejna, wewnętrzna encja – jej zadaniem jest już pobranie konkretnych danych, zawartych w plikach. Dane pobierane są z pliku podanego przez zewnętrzną encję za pomocą źródła danych. Typ procesora: XpathEntityProcessor używany do plików XML rozpoznaje następujące atrybuty:

url – namiary na dane wejściowe
useSolrAddSchema – informacja, że dane wejściowe są w postaci Solr XML.
stream – czy zastosować przetwarzanie strumieniowe. W przypadku dużych XML warto użyć stream=”true” co zmniejszy zapotrzebowanie na pamięć a czasem wręcz umożliwi import ;))

Dodatkowe parametry nie są przydatne w naszym przykładzie i opiszemy je przy innej okazji 
Ale po co to wszystko?
Przykład umożliwia on odczytanie wszystkich plików XML z wybranego katalogu. Jako format pliku używany tu jest dokładnie ten sam format jak przy „klasycznej” metodzie wysyłania dokumentów do SOLR przy pomocy HTTP POST. Dlaczego więc korzystać z tej metody?
Push i Pull
Pierwszym argumentem może być kontrola nad połączeniami między sewerem SOLR a systemem serwującym dane do importu. Gdy nie mamy pełnej kontroli nad źródłem danych, lepiej pobierać dane ze źródła, niż udostępniać dodatkowy serwis, który potencjalnie może stać się celem ataku.
Prototypowanie i testowanie zmian
Drugi argument, ważniejszy dla programisty: DIH umożliwia w prosty sposób manipulowanie treścią pobieranego dokumentu. Jest to bardzo sympatyczna cecha pozwalająca na np. dodania do dokumentu paru pól, bez konieczności przerabiania całego mechanizmu generującego pliki XML.
Jak to działa w praktyce? W moim wypadku postanowiono dodać możliwość bardziej zaawansowanego wyszukiwania i facetingu po drzewie kategorii. W dokumencie było już dostępne pole „category” przechowujące ścieżkę typu: „Samochody / Osobowe / Audi”. By umożliwić stworzenie nowych zapytań w indeksie powinny pojawić się dodatkowe pola mówiące o tym, jaka jest kategoria, na którym jest poziomie oraz ile jest wszystkich poziomów.
By dodać wymagane pola wykorzystaliśmy możliwość definiowania skryptów. Wcześniej zacytowany plik importu teraz wygląda tak:


Uwaga na zakończenie
Stosując DIH trzeba mieć świadomość, że działa on trochę inaczej. W szczególności próba wczytania wielu wartości do pola nie zaznaczonego w schema.xml jako „multiValued” w DIH zakończy się sukcesem – nadmiarowe wartości zostaną zignorowane. W przypadku „klasycznego” sposobu będzie zwrócony błąd.
]]>
					
					https://solr.pl/2011/08/16/automatycznie-zapisany-szkic/feed/
			0
		
		
			
		
		
		https://solr.pl/2011/04/04/indeksowanie-plikow-doc-pdf-itp-czyli-integracja-solr-z-tika/
					https://solr.pl/2011/04/04/indeksowanie-plikow-doc-pdf-itp-czyli-integracja-solr-z-tika/#respond
		
		
		Mon, 04 Apr 2011 17:38:41 +0000
				
		
		
		http://sematext.solr.pl/?p=229

					
										W poprzednim artykule podaliśmy podstawowe informację, jak umożliwić przeszukiwanie  zawartości plików binarnych, czyli m.in dokumentów MS Word, PDF czy LibreOffice. Dziś zrobimy to samo, wykorzystując Data Import Handler. Ponieważ parę dni temu pojawiła się nowa wersja serwera SOLR (3.1), poniższe wskazówki bazują na tej wersji. Do prezentacji wykorzystano aplikację „example” – wszystkie poniższe zmiany odnoszą się właśnie do tej aplikacji.


Założenia
Zakładamy, że dane dostępne są w formacie XML i zawierają podstawowe informacje o dokumencie oraz nazwę pliku w którym znajduje się treść dokumentu. Pliki znajdują się w zdefiniowanym katalogu. Przykładowy plik:

<?xml version="1.0" encoding="utf-8"?>
<albums>
    <album>
        <author>John F.</author>
        <title>Life in picture</title>
        <description>1.jpg</description>
    </album>
    <album>
        <author>Peter Z.</author>
        <title>Simple presentation</title>
        <description>2.pptx</description>
    </album>
</abums>
Jak widać dane charakteryzują się tym, że poszczególne elementy nie mają indywidualnego identyfikatora. Ale z tym też sobie poradzimy 

Na początku zmodyfikujemy schemat, dodając definicję pola przechowującego zawartość pliku:

<field name="content" type="text" indexed="true" stored="true" multiValued="true"/>
a w solrconfig.xml dodajemy konfigurację handlera DIH:

   
<requestHandler name="/dataimport">
    <lst name="defaults">
        <str name="config">data-config.xml</str>
    </lst>
</requestHandler>
Ponieważ będziemy wykorzystywać entity processor zawarty w bibliotece extras (TikaEntityProcessor), zmodyfikujemy również linijkę ładującą bibiliotekę DIH:

 <lib dir="../../dist/" regex="apache-solr-dataimporthandler-.*\.jar" />
Kolejnym krokiem jest stworzenie pliku data-config.xml. W naszym przypadku:

<dataConfig>
    <script><![CDATA[
        id = 1;
        function GenerateId(row) {
            row.put('id', (id ++).toFixed());
            return row;
        }       
       ]]></script>
   <dataSource type="BinURLDataSource" name="data"/>
    <dataSource type="URLDataSource" baseUrl="http://localhost/tmp/bin/" name="main"/>
    <document>
        <entity name="rec" processor="XPathEntityProcessor" url="data.xml" forEach="/albums/album" dataSource="main" transformer="script:GenerateId">
            <field column="title" xpath="//title" />
            <field column="description" xpath="//description" />
            <entity processor="TikaEntityProcessor" url="http://localhost/tmp/bin/
Generowanie identyfikatora rekordu - skrypty
Pierwszym ciekawym elementem jest wykorzystanie standardowo dostępnego ScriptTransformera w celu wygenerowania identyfikatorów dokumentów. Dzięki metodzie javascript „GenerateId” oraz odwołania do niej (transformer="script:GenerateId")każdy rekord będzie dodatkowo ponumerowany. Szczerze mówiąc nie jest to zbyt dobra metoda na radzenie sobie z brakiem identyfikatorów, bo nie pozwala na indeksowanie przyrostowe (nie jesteśmy w stanie rozróżnić poszczególnych wersji rekordu) – użyto jej tutaj tylko i wyłącznie w celu pokazania jak łatwo modyfikować poszczególne rekordy. Jeśli nie lubisz Javascriptu – możesz użyć dowolnego języka skryptowego wspieranego przez Java6.
Wykorzystanie wielu źródeł danych
Drugim ciekawym elementem jest wykorzystanie kilku źródeł danych. Ponieważ nasze metadane są dostępne w pliku XML, konieczne jest pobranie tego pliku. Postępujemy standardowo : definiujemy UrlDataSource a następnie przy pomocy processora XpathEntityProcessor analizujemy przychodzące dane. Ponieważ dodatkowo musimy pobrać binarne załączniki do każdego rekordu, definiujemy dodatkowe źródło:  BinURLDataSource oraz dodatkowe entity, korzystające z procesora  TikaEntityProcessor. Jeszcze tylko powiadomienie entity skąd pobrać plik (atrybut url z odwołaniem się do entity – rodzica) oraz powiadomienie z którego źródła skorzystać (atrybut dataSource). Całość dopełnia lista pól do zindeksowania (dodatkowy atrybut meta oznacza, że dane są pobierane z metadanych pliku).
Dostępne pola
Apache Tika pozwala na pobranie z dokumentu szeregu dodatkowych danych. W przykładzie powyżej skorzystaliśmy tylko z tytułu, autora i treści dokumentu. Pełne informacje o dostępnych polach są zawarte w interfejsach, które są implementowane przez klasę Metadata ( http://tika.apache.org/0.9/api/org/apache/tika/metadata/Metadata.html)a dokładnie w stałych definiowanych w tych interfejsach. W szczególności interesujące są DublinCore i MSOffice
Zakończenie
Po uruchomieniu solr i rozpoczęciu procesu importu (czyli wywołania adresu: http://localhost:8983/solr/dataimport?command=full-import) po krótkiej chwili dokumenty zostają wczytane co powinno być widoczne po zadaniu zapytania:http://localhost:8983/solr/select?q=*:*
{rec.description}" dataSource="data">
                <field column="text" name="content" />
                <field column="Author" name="author" meta="true" />
                <field column="title" name="title" meta="true" />
            </entity>
        </entity>
    </document>
</dataConfig>
Generowanie identyfikatora rekordu – skrypty
Pierwszym ciekawym elementem jest wykorzystanie standardowo dostępnego ScriptTransformera w celu wygenerowania identyfikatorów dokumentów. Dzięki metodzie javascript „GenerateId” oraz odwołania do niej (transformer=”script:GenerateId”)każdy rekord będzie dodatkowo ponumerowany. Szczerze mówiąc nie jest to zbyt dobra metoda na radzenie sobie z brakiem identyfikatorów, bo nie pozwala na indeksowanie przyrostowe (nie jesteśmy w stanie rozróżnić poszczególnych wersji rekordu) – użyto jej tutaj tylko i wyłącznie w celu pokazania jak łatwo modyfikować poszczególne rekordy. Jeśli nie lubisz Javascriptu – możesz użyć dowolnego języka skryptowego wspieranego przez Java6.
Wykorzystanie wielu źródeł danych
Drugim ciekawym elementem jest wykorzystanie kilku źródeł danych. Ponieważ nasze metadane są dostępne w pliku XML, konieczne jest pobranie tego pliku. Postępujemy standardowo : definiujemy UrlDataSource a następnie przy pomocy processora XpathEntityProcessor analizujemy przychodzące dane. Ponieważ dodatkowo musimy pobrać binarne załączniki do każdego rekordu, definiujemy dodatkowe źródło:  BinURLDataSource oraz dodatkowe entity, korzystające z procesora  TikaEntityProcessor. Jeszcze tylko powiadomienie entity skąd pobrać plik (atrybut url z odwołaniem się do entity – rodzica) oraz powiadomienie z którego źródła skorzystać (atrybut dataSource). Całość dopełnia lista pól do zindeksowania (dodatkowy atrybut meta oznacza, że dane są pobierane z metadanych pliku).
Dostępne pola
Apache Tika pozwala na pobranie z dokumentu szeregu dodatkowych danych. W przykładzie powyżej skorzystaliśmy tylko z tytułu, autora i treści dokumentu. Pełne informacje o dostępnych polach są zawarte w interfejsach, które są implementowane przez klasę Metadata ( http://tika.apache.org/0.9/api/org/apache/tika/metadata/Metadata.html)a dokładnie w stałych definiowanych w tych interfejsach. W szczególności interesujące są DublinCore i MSOffice
Zakończenie
Po uruchomieniu solr i rozpoczęciu procesu importu (czyli wywołania adresu: http://localhost:8983/solr/dataimport?command=full-import) po krótkiej chwili dokumenty zostają wczytane co powinno być widoczne po zadaniu zapytania:http://localhost:8983/solr/select?q=*:*
]]>
					
					https://solr.pl/2011/04/04/indeksowanie-plikow-doc-pdf-itp-czyli-integracja-solr-z-tika/feed/
			0
		
		
			
		
		
		https://solr.pl/2011/03/07/data-import-handler-xml-zagniezdzone-encje/
					https://solr.pl/2011/03/07/data-import-handler-xml-zagniezdzone-encje/#respond
		
		
		Mon, 07 Mar 2011 08:12:53 +0000
				
		
		
		
		
		http://sematext.solr.pl/?p=205

					
										Data Import Handler jest bardzo miłym i rozbudowanym narzędziem. Poniżej opis problemu (i rozwiązania) w którym spotkałem się ostatnio.


Opis Problemu
Do zaindeksowania jest pewna lista produktów. Produkty jednak mogą być łączone w grupy. Dodatkowo w grupie, w kolejnych elementach mogą być pominięte te dane, które w elemencie wcześniej zostały zdefiniowane. Przykładowa struktura (nieistotne informacje pominąłem dla czytelności):

<products>
  <product>
    <id>1</id>
    <name>Product 1</name>
  </product>
  <product>
    <id>2</id>
    <name>Product 2</name>
  </product>
  <group>
    <product>
      <id>3</id>
      <name>Product 3 and 4</name>
    </product>
    <product>
      <id>4</id>
    </product>
  </group>
</products>
Rozwiązanie
Rozwiązanie polega na zdefiniowaniu – jak zawszę – elementu „entity” w sposób następujący:

<entity processor="XPathEntityProcessor"
    forEach="/products/product | /products/group/product">
  <field column="id" xpath="//id" />
  <field column="name" xpath="//name" commonField="true" />
</entity>
Wyjaśnienie
Dzięki takiej konstrukcji „forEach” do przetworzenia dostaną się zarówno produkty nie należące do grupy, jak i te w grupach. Istotnym atrybutem pola jest „commonField”. Informuje on DIH, że jeśli w danym rekordzie nie jest zdefiniowane to pole, należy je pobrać z rekordu poprzedniego.
Podane rozwiązanie ma parę ograniczeń, np. pierwszy element w grupie powinien mieć zdefiniowane pole „name” oraz ważna jest kolejność produktów, natomiast w moim przypadku pokrywało się to dokładnie ze specyfikacją dostarczonego pliku importu.
]]>
					
					https://solr.pl/2011/03/07/data-import-handler-xml-zagniezdzone-encje/feed/
			0
		
		
			
		
		
		https://solr.pl/2011/01/03/data-import-handler-usuwanie-danych-z-indeksu/
					https://solr.pl/2011/01/03/data-import-handler-usuwanie-danych-z-indeksu/#respond
		
		
		Mon, 03 Jan 2011 07:58:02 +0000
				
		
		
		
		
		
		http://sematext.solr.pl/?p=171

					
										Usuwanie danych z indeksu przy wykorzystaniu indeksowania przyrostowego w DIH jest na wiki SOLR potraktowane szczątkowo, jako coś, co działa analogicznie do aktualizacji rekordów. Podobnie we wcześniejszym artykule użyłem tego skrótu, tym bardziej, że podany przeze mnie przykład z indeksowaniem zasobów wikipedii nie potrzebował usuwania danych.


Mając pod ręką przykładowe dane z albumami i wykonawcami postanowiłem pokazać mój sposób postępowania w takich wypadkach. Dla uproszczenia i przejrzystości zakładam, że po pierwszym zaimportowaniu, danych może tylko ubywać.
Dane testowe
Moje dane testowe mieszczą się bazie PostgreSQL w tabeli zdefiniowanej następująco:
Table "public.albums"
Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
id     | integer | not null default nextval('albums_id_seq'::regclass)
name   | text    | not null
author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)
W tabeli znajduje się 825661 rekordów.
Instalacja testowa
Do testów użyłem instancji SOLR posiadającej następującą charakterystykę:
Definicja w schema.xml:
<fields>
<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="album" type="text" indexed="true" stored="true" multiValued="true"/>
<field name="author" type="text" indexed="true" stored="true" multiValued="true"/>
</fields>
<uniqueKey>id</uniqueKey>
<defaultSearchField>album</defaultSearchField>
Definicja DIH w solrconfig.xml:
<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">db-data-config.xml</str>
</lst>
</requestHandler>
I plik DIH db-data-config.xml:
<dataConfig>
<dataSource driver="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/shardtest" user="solr" password="secret" />
<document>
<entity name="album" query="SELECT * from albums">
<field column="id" name="id" />
<field column="name" name="album" />
<field column="author" name="author" />
</entity>
</document>
</dataConfig>
Przed naszym testem zaimportowałem wszystkie dane z tabeli albums.
Usuwanie danych
Patrząc na tabelę widać, że gdy usuniemy rekord, ginie on bez śladu i jedynym sposobem aktualizacji naszego indeksu byłoby porównanie identyfikatorów dokumentów w indeksie z identyfikatorami w bazie i wyrzucenie tych, które w bazie już nie istnieją. Wolne i niewygodne. Innym sposobem jest dodatnie kolumny deleted_at: zamiast kasowania fizycznie rekordu, uzupełniamy tylko tę kolumnę. DIH może wtedy pobrać wszystkie rekordy z ustawioną datą późniejszą od ostatniego indeksowania. Wadą tego rozwiązania może by konieczność modyfikacji aplikacji by uwzględniały tak „skasowane” rekordy.
Ja zastosuje inne rozwiązanie, przeźroczyste dla aplikacji. Tworzymy nową tabelę:
CREATE TABLE deletes
(
id serial NOT NULL,
deleted_id bigint,
deleted_at timestamp without time zone NOT NULL,
CONSTRAINT deletes_pk PRIMARY KEY (id)
);
Do tej tabeli automagicznie będziemy dopisywać identyfikatory tych elementów, które zostały usunięte z tabeli albums oraz informacje kiedy zostały usunięte.
Teraz dodamy jeszcze funkcję:
CREATE OR REPLACE FUNCTION insert_after_delete()
RETURNS trigger AS
$BODY$BEGIN
IF tg_op = 'DELETE' THEN
INSERT INTO deletes(deleted_id, deleted_at)
VALUES (old.id, now());
RETURN old;
END IF;
END$BODY$
LANGUAGE plpgsql VOLATILE;
oraz trigger:
CREATE TRIGGER deleted_trg
BEFORE DELETE
ON albums
FOR EACH ROW
EXECUTE PROCEDURE insert_after_delete();
Sprawdzamy działanie
Zgodnie z planem, każdy usunięty wpis w tabeli albums powinien skutkować uzupełnieniem tabeli
deletes. Sprawdźmy więc. Usuwamy parę rekordów:
=> DELETE FROM albums where id < 37;
DELETE 2
=> SELECT * from deletes;
id | deleted_id |         deleted_at
----+------------+----------------------------
26 |         35 | 2010-12-23 13:53:18.034612
27 |         36 | 2010-12-23 13:53:18.034612
(2 rows)
Czyli baza działa.
Uzupełniamy plik konfiguracyjny DIH tak, by entity było zdefiniowane następująco:
<entity name="album" query="SELECT * from albums"
  deletedPkQuery="SELECT deleted_id as id FROM deletes WHERE deleted_at > '$'{dataimporter.last_index_time}'">
Dzięki temu przy imporcie przyrostowym DIH użyje atrybutu deletedPkQuery by pobrać identyfikatory tych dokumentów, które należy usunąć.
Sprytny czytelnik pewnie zacznie się zastanawiać, czy na pewno potrzebna jest nam kolumna z datą usunięcia rekordu. Przecież możemy usunąć wszystkie rekordy znalezione w tabeli deleted a następnie skasować zawartość tej tabeli. Teoretycznie to prawda, ale w przypadku problemu z serwerem indeksującym SOLR w naszym wypadku łatwo zastąpić go innym – jego stopień synchronizacji z bazą nie jest bardzo istotny – po prostu za następnym importem przyrostowym nastąpi synchronizacja z bazą. W opcji z kasowaniem zawartości deletes takie możliwości nie ma.
Wykonujemy teraz import przyrostowy wywołując adres: /solr/dataimport?command=delta-import
W logach powinna pojawić się linia podobna do tej:
INFO: {delete=[35, 36],optimize=} 0 2
Co oznacza, że DIH poprawnie usunął z indeksu te dokumenty, które usunęliśmy wcześniej z bazy.
]]>
					
					https://solr.pl/2011/01/03/data-import-handler-usuwanie-danych-z-indeksu/feed/
			0
		
		
			
		
		
		https://solr.pl/2010/12/27/data-import-handler-sharding/
					https://solr.pl/2010/12/27/data-import-handler-sharding/#respond
		
		
		Mon, 27 Dec 2010 07:57:08 +0000
				
		
		
		
		
		http://sematext.solr.pl/?p=169

					
										Nasza czytelniczka (pozdrawiamy!) zgłosiła się do nas z problemem dotyczącym współpracy DIH z shardingiem. Wiki projektu SOLR pokazuje moim zdaniem rozwiązanie tej kwestii, ale czyni to trochę na około i przy okazji.


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

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

W opisywanym przypadku mamy jeden zbiór danych i chcemy stworzyć wiele zbiorów (tzw. shardów) po stronie SOLR.
Kiedy stosować sharding?
Bardzo ważna kwestia: po co? W moim mniemaniu sharding bywa zbyt często nadużywany generując mnóstwo dodatkowych komplikacji i ograniczeń. Główny powód to duży wolumen danych, które powodują, że indeks SOLR nie mieści się w obrębie jednej maszyny. Jeśli tak nie jest – często oznacza to, że sharding jest zbędny. Kolejny powód to wydajność. Jednak sharding może tutaj pomóc tylko wtedy, gdy inne optymalizacje zawiodą a zapytania są na tyle skomplikowane, że sam narzut shardingu (przekazania zapytania do poszczególnych shardów i łączenie ich odpowiedzi) jest mniejszy niż zysk możliwy do uzyskania.
Dane testowe
Zakładamy jednak, że sharding jest nam potrzebny. W przykładzie poniżej użyłem danych z musicbrainz tworząc prostą tabelę postgresową:

Table "public.albums"
 Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
 id     | integer | not null default nextval('albums_id_seq'::regclass)
 name   | text    | not null
 author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)
W tabeli znajduje się 825661 rekordów. Podkreślam tutaj, że zarówno struktura jak i ilość danych jest na tyle małe, że praktyczna przydatność shardingu jest tu pomijalna.
Instalacja testowa
Do testów użyjemy trzech instancji SOLR. Wszystkie instancje są identyczne, różnica jest związana tylko z numerem portów (8983, 7872, 6761) – testy będą wykonywane na jednej fizycznej maszynie.
Definicja w schema.xml:

<fields>
 <field name="id" type="string" indexed="true" stored="true" required="true" />
 <field name="album" type="text" indexed="true" stored="true" multiValued="true"/>
 <field name="author" type="text" indexed="true" stored="true" multiValued="true"/>
</fields>
<uniqueKey>id</uniqueKey>
<defaultSearchField>album</defaultSearchField>
Definicja DIH w solrconfig.xml:

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

<dataConfig>
 <dataSource driver="org.postgresql.Driver" url="jdbc:postgresql://localhost:5432/shardtest" user="solr" password="secret" />
 <document>
  <entity name="album" query="SELECT * from albums">
   <field column="id" name="id" />
   <field column="name" name="album" />
   <field column="author" name="author" />
  </entity>
 </document>
</dataConfig>
W tym momencie każda instancja jest w stanie dokonać pełnego importu danych.
Zestawiamy sharding
Naszym celem jest takie zmodyfikowanie konfiguracji DIH by każda instancja indeksowała tylko „swoją” część danych. Najprościej zrobić to modyfikując zapytanie pobierające dane np w ten sposób:
SELECT * from albums where id % LICZBA_INSTANCJI = NUMER_INSTANCJI
gdzie:

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

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

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

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

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

Sprawdzamy działanie
Po uruchomieniu wszystkich instancji SOLR na każdej wywołujemy adres:
/solr/dataimport?command=full-import
Po zakończeniu pracy DIH i wywołaniu:
 /solr/dataimport?command=status
dostajemy w odpowiedzi od instancji odpowiednio:

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

Wykonując prostą operację dodawania widzimy, że we wszystkich instancjach łącznie mamy 825661 dokumentów, czyli tyle ile powinno tam być 

Wykonajmy jeszcze zapytanie o wszystkie dokumenty, z wykorzystaniem shardingu wywołując na dowolnej instancji:
/solr/select/?q=*:*&shards=localhost:6761/solr,localhost:7872/solr,localhost:8983/solr
Wynik:  825661.
To działa! 
]]>
					
					https://solr.pl/2010/12/27/data-import-handler-sharding/feed/
			0
		
		
			
		
		
		https://solr.pl/2010/10/11/data-import-handler-import-danych-z-baz-sql-cz-1/
					https://solr.pl/2010/10/11/data-import-handler-import-danych-z-baz-sql-cz-1/#respond
		
		
		Mon, 11 Oct 2010 04:54:16 +0000
				
		
		
		
		
		http://sematext.solr.pl/?p=40

					
										W artykule o sposobach importu danych (http://solr.pl/2010/09/06/solr-importowanie-danych/) wspomniałem o Data Import Handler (DIH). Podstawową zaletą tego sposobu importowania jest brak konieczności tworzenia dodatkowego oprogramowania oraz szybka integracja ze źródłem danych. Ta druga zaleta wymaga jednak wprawy i praktyki. W tym wpisie przedstawię podstawy integracji DIH ze źródłem danych SQL.


W przykładach użyta została baza PostgeSQL zawierająca dane polskiej wikipedii. Testowa instancja solr została zdefiniowana jako rdzeń „wikipedia” i dostępna była pod adresem:
http://localhost:8983/solr/wikipedia/admin/
Konfiguracja solrconfig.xml
Konfiguracja sprowadza się do dodania dodatkowego requestHandlera. Parametr: config określa plik konfiguracyjny, w którym znajduje się definicja źródła danych.

 <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
  <lst name="defaults">
   <str name="config">db-data-config.xml</str>
  </lst>
</requestHandler>
Dzięki takiej definicji zyskujemy możliwość wywoływania adresu HTTP obsługującego import:

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

(dla mojej konfiguracji pełen adres to: http://localhost:8983/solr/wikipedia/dataimport)
Powyżej widzimy dwie możliwości importowania danych: import pełny i przyrostowy.
Pełny import danych polega na każdorazowym wczytaniu wszystkich danych, które powinny znaleźć się w indeksie, podczas gdy import przyrostowy oznacza tylko dodanie i aktualizację w indeksie tych danych, które zmieniły się od ostatniego indeksowania. Pełny import zwykle trwa znacznie dłużej stąd prosty wniosek: jeśli czas pełnego indeksowania nie jest dla nas problemem – prawdopodobnie nie warto zawracać sobie głowy konfiguracją indeksowania przyrostowego, zwłaszcza, że nakłada ono  dodatkowe wymagania na strukturę źródła danych.
Warto zaznaczyć, że pełny import domyślnie rozpoczyna się od usunięcia istniejącego indeksu.  Istnieje możliwość uniknięcia takiego zachowania poprzez dodanie  parametru: clean=false.
Konfiguracja źródła danych
Konfiguracja polega na zdefiniowaniu zapytań pozwalających solr na pobieranie danych do indeksowania i zawiera się w pliku określonym przy definicji handlera (u nas:  db-data-config.xml) W tym wpisie zaczniemy od zdefiniowania pełnego importu. Następnie, w kolejnej części artykułu rozbudujemy go o możliwość importowania przyrostowego.
Pełny import

<dataConfig>
  <dataSource driver="org.postgresql.Driver"
     url="jdbc:postgresql://localhost:5432/wikipedia"
     user="wikipedia"
     password="secret" />
  <document>
    <entity name="page" query="SELECT page_id, page_title from page">
      <field column="page_id" name="id" />
      <field column="page_title" name="name" />
      <entity name="revision" query="select rev_id from revision where rev_page=${page.page_id}">
        <entity name="pagecontent" query="select old_text from pagecontent where old_id=${revision.rev_id}">
          <field column="old_text" name="text" />
        </entity>
      </entity>
   </entity>
  </document>
</dataConfig>
Jak widzimy definicja źródła składa się z opisu sposobu połączenia do baz danych oraz opisu indeksowanego dokumentu. Import następuje zgodnie z następującym algorytmem:

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

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

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">idle</str>
  <str name="importResponse"/>
  <lst name="statusMessages"/>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>
Uwagę zwraca wpis: status: idle. Oznacza to, że nasz importer jest gotowy do pracy. W innym przypadku (np. Błąd poprawności XML konfiguracyjnego) dostaniemy opis wyjątku. Niestety na tym etapie nie są wykrywane jeszcze błędy związane np. z niewłaściwą definicją połączenia do bazy lub braku sterownika JDBC.
Wchodzimy więc na stronę: http://localhost:8983/solr/wikipedia/dataimport?command=full-import
To co powinniśmy otrzymać, to podobny jak wyżej XML. Jednak po ponownym wejściu na stronę: http://localhost:8983/solr/wikipedia/dataimport dostajemy już inny wynik.

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">busy</str>
  <str name="importResponse">A command is still running...</str>
  <lst name="statusMessages">
    <str name="Time Elapsed">0:1:15.460</str>
    <str name="Total Requests made to DataSource">39547</str>
    <str name="Total Rows Fetched">59319</str>
    <str name="Total Documents Processed">19772</str>
    <str name="Total Documents Skipped">0</str>
    <str name="Full Dump Started">2010-10-03 14:28:00</str>
  </lst>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>
Czyli importer pracuje.
Po pewnym czasie, zależnym od ilości indeksowanych danych i szybkości komputera otrzymamy:

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="initArgs">
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
  </lst>
  <str name="status">idle</str>
  <str name="importResponse"/>
  <lst name="statusMessages">
    <str name="Total Requests made to DataSource">2118645</str>
    <str name="Total Rows Fetched">3177966</str>
    <str name="Total Documents Skipped">0</str>
    <str name="Full Dump Started">2010-10-03 14:28:00</str>
    <str name="">Indexing completed. Added/Updated: 1059322 documents. Deleted 0 documents.</str>
    <str name="Committed">2010-10-03 14:55:20</str>
    <str name="Optimized">2010-10-03 14:55:20</str>
    <str name="Total Documents Processed">1059322</str>
    <str name="Time taken ">0:27:20.325</str>
  </lst>
  <str name="WARNING">This response format is experimental.  It is likely to change in the future.</str>
</response>
Jak widzimy indeksacja zakończyła się sukcesem.
W kolejnym odcinku spróbujemy dodać możliwość importowania przyrostowego.
]]>
					
					https://solr.pl/2010/10/11/data-import-handler-import-danych-z-baz-sql-cz-1/feed/
			0