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

<fieldType name="textCharNorm" class="solr.TextField">
  <analyzer>
    <charFilter class="solr.PatternReplaceCharFilterFactory" …/>
    <charFilter class="solr.MappingCharFilterFactory" mapping="mapping-ISOLatin1Accent.txt"/>
    <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  </analyzer>
</fieldType>

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:

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="#TAG" />

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.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="#TAG" replacement="[CENZORED]"/>

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.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="(\\d+-*\\d+)+" replacement="*"/>

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.

<charFilter class="solr.PatternReplaceCharFilterFactory" pattern="(.)\\1" replacement="$1"/>

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.

Co przechowuje

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

Do czego służy

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

Definicja

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

<filterCache
      class="solr.FastLRUCache"
      size="16384"
      initialSize="4096"
      autowarmCount="4096" />

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

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

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

Jak skonfigurować

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

Efektywne wykorzystanie

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

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

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

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

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

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

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

Jeżeli natomiast wykonalibyśmy zapytanie w postaci:

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

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

Kilka słów na koniec

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

Czy zastanawialiście się co powoduje, że wyszukiwarka w serwisie jest uważana za dobrą? By odpowiedzieć na to pytanie, należy się zastanowić, jak wygląda typowy proces znajdowania przez klienta pożądanej przez niego informacji. I czy jest coś takiego, jak typowy proces.

W projektach, w których udało mi się uczestniczyć dobrze sprawdzał się model mówiący o podziale na następujące fazy:

• wyszukiwanie
• redefinicja zapytania
• filtracja
• sortowanie
• przeglądanie wyników

Nie wszystkie te fazy muszą wystąpić, ich kolejność czasem będzie inna, czasem też poszczególne fazy będą występować wielokrotnie. Również w zależności od produktu, posiadanych danych i ich ilości nie wszystkie z nich system musi udostępniać.

1. Wyszukiwanie

Tu użytkownik może wykazać się największą inwencją wpisując w pole (albo wiele pól) frazę wyszukiwania. I jest to jednocześnie krytyczny moment, w którym często nowy użytkownik podejmuje decyzję: zostać czy znaleźć inny, lepszy serwis. Na co zwykle zwracamy uwagę:

• czytelność wyników i sensowność doboru wyświetlanych informacji – celem użytkownika jest znalezienie konkretnego elementu lub grupy elementów spełniających kryteria (często mętne i niekonkretne) wyszukiwania. Dlatego musi mieć możliwość wstępnego odrzucenia tych elementów, które mu z jakiś powodów nie pasują. Błędem jest brak podstawowych dla użytkownika informacji (np. serwis z ogłoszeniami sprzedaży mieszkań, który nie pokazuje na liście wyników metrażu ani lokalizacji! )
• liczba znalezionych wyników – jeśli wyników jest mało, może to np. sugerować ograniczony asortyment w sklepie
• przystawanie wyników do frazy wyszukiwania – jeśli w sklepie komputerowym na hasło: „notebook” na pierwsza strona zawiera tylko pokrowce na notebooki, może to sugerować, że firma sprzedaje tylko akcesoria
• możliwości nawigacji i łatwość dokonania wyboru – jeśli wyników wyszukiwania jest dużo, zostawienie użytkownikowi możliwości tylko zmiany zapytania albo męczącego przebijania się przez strony wyników nie jest dobrym pomysłem.

2. Redefinicja zapytania

W zależności od uzyskanych wyników wyszukiwania, zwykle od pierwszego wrażenia jakości tych wyników, użytkownik może zdecydować się powtórzyć wyszukiwanie. Im więcej faz redefinicji, tym gorsze wrażenie klienta i większa szansa na opuszczenie sklepu. Zwłaszcza, jeśli użytkownik, w jego mniemaniu wpisał bardzo ogólną frazę, a nie dostał żadnych wyników.

3. Filtracja

Rodzaj zwróconych wyników jest w porządku, pytanie, jak teraz użytkownik może ograniczyć ich liczbę do tych, które są szczególnie interesujące (czyli odrzucić te mniej ciekawe). W tym celu umożliwia się dalsze nawigowanie po wynikach wyszukiwania w oparciu o filtry. Tutaj zwykle zwracamy uwagę na:

• łatwość dodawania i usuwania filtru – zakładając, że użytkownik ma jedynie ogólne pojęcie czego szuka, należy się spodziewać, że będzie on wielokrotnie zmieniał kryteria wyszukiwania – niedopuszczalne są ścieżki nawigacji, gdzie jedyną metodą powrotu do wcześniej odfiltrowanych elementów jest przycisk „powrót” w przeglądarce, lub rozpoczęcie kolejnego wyszukiwania.
• zależność filtrów od rodzaju wyszukiwania – szukając nowego komputera interesujący jest inny zestaw parametrów niż wybierając książkę. Chociaż brzmi to jak oczywistość, zbyt często można spotkać sytuacje, gdzie zmiana asortymentu sklepu nie pociąga za sobą zmian definicji filtrów, lub zestaw filtrów jest narzucony „z góry”. W efekcie pojawiają się opcje typu „kolor opon”.
• podanie liczb określających liczbę wyników po zastosowaniu filtra – niedoceniana funkcjonalność, jednak pozwala na wybieranie przez użytkownika optymalnego sposobu filtrowania: jeśli koniecznie w notebooku muszę mieć wbudowaną kamerę, to filtr „Z wbudowaną kamerą (3)” od razu sugeruje, że wybór koloru będzie mniej ważny i nie ma sobie co nim zawracać głowy.

4. Sortowanie

Pozwala się zająć klientowi przeglądaniem wyników w najwygodniejszej kolejności (np. od najtańszych produktów). W praktyce liczba opcji jest mocno ograniczona, np. Pomysł sortowania po cechach produktu może konfliktować z filtrowaniem.

5. Przeglądanie Wyników

Tutaj użytkownik już zapoznaje się z wybranymi produktami. Z punktu widzenia wyszukiwania to już dość nudny temat Warto jednak pamiętać o wygodnym powrocie do listy wyników: tu błędem jest np. automatyczny powrót na pierwszą stronę wyników, albo zmuszanie użytkownika do przewijania strony w poszukiwaniu ostatnio oglądanego elementu.