Plik solrconfig.xml jest kolejnym plikiem, który definiuje zachowanie Solr. W odróżnieniu od pliku opisującego strukturę indeksu, plik solrconfig.xml określa dostępne dla użytkownika funkcjonalności Solr. Tak samo, jak w przypadku pliku schema.xml można wyróżnić szereg standardowych błędów popełnianych przez osoby, które wdrażają Solr i nie mówię tu tylko o osobach, które mają niewielkie doświadczenie z Solr. W celu poznania niektórych z tych błędów zapraszam do dalszej lektury.
Na początek chciałem zaznaczyć, iż nie są to wszystkie możliwe do popełnienia błędy, jest to jedynie przykład tego, na co powinno się uważać podczas wdrażania Solr.
1. Ta funkcjonalność kiedyś na pewno mi się przyda
Podobnie jak w przypadku pliku schema.xml, tak samo w przypadku pliku solrconfig.xml sugeruję minimalizm. Jeżeli wiemy, że będziemy wykorzystywali w odpowiedzi tylko format JSON, to nie dorzucajmy do konfiguracji dodatkowych formatów odpowiedzi. Bardzo często spotykam się z sytuacjami, kiedy osoba konfigurująca wdrożenie Solr dorzuca wszystkie możliwe handlery, response writery i cały szereg dodatkowych funkcjonalności pomimo tego, że nie wie nawet do czego niektóre z nich służą. Pomimo tego, że wykorzystanie pamięci przez standardowe elementy konfiguracyjne nie jest duże, to utrzymywanie minimalistycznego pliku solrconfig.xml jest zdecydowanie łatwiejsze, niż takiego, który jest rozdmuchany do granic niemożliwości.
2. Po co mi cache ?
Przypadek ekstremalny, ale prawdziwy. Dostałem kiedyś pytanie, czy cache jest potrzebny, jeżeli aplikacja korzystająca z Solr i tak będzie wykorzystywać cache po swojej stronie. Moja odpowiedź oczywiście była twierdząca. Osoby nie znające Solr wyobrażają sobie cache, jako kolejny, czasami niepotrzebny, poziom zapamiętywania wyników wyszukiwania. Należy jednak pamiętać, że oprócz mechanizmu cacheowania opartego o protokół HTTP Solr posiada swój wewnętrzny cache – żeby być dokładniejszym, jest go kilka rodzajów. Dostosowując cache do swojego wdrożenia obserwujmy serwery testowe – jak rozkładają się trafienia, czy cache nie jest za mały, ale także czy nie jest za duży. Należy pamiętać, że konfiguracja cache Solr to nie jest proces jednorazowy i co jakiś czas należy się przyjrzeć działaniu i ewentualnie odpowiednio reagować.
3. Bo rozgrzewać trzeba umieć
Solr uruchamia się kilka minut, a replikacja trwa wieki, pomimo tego, że index jest stosunkowo mały. Pojawia się więc pytanie – dlaczego ? Spojrzenie do pliku solrconfig.xml i wszystko jasne – ogromna ilość zapytań rozgrzewających, zarówno tych uruchamianych przy starcie, jak i podczas rozgrzewania searchera po replikacji danych. Trzeba pamiętać, aby nie przesadzić z ilością zapytań, bo osiągniemy efekt odwrotny do zamierzonego – pomimo teoretycznie dobrego rozgrzania cache, Solr podczas procesu rozgrzewania będzie działał słabo lub w ogóle nie będzie działać.
4. Zapisze wszystko w konfiguracji handlera
Czasami spotykam się z podejściem, gdzie osoba korzystająca z Solr chciałaby zapisać wszystkie parametry zapytań, nawet te, które się zmieniają, w konfiguracji Solr. Powstaje wtedy wiele definicji handlerów, które różnią się od Siebie zestawem parametrów, a aplikacja musi „pamiętać”, który handler użyć do odpowiedniego zapytania. Oczywiście w przypadku, kiedy chcemy dodać kilka niezmiennych, bądź domyślnych parametrów do konfiguracji, takie podejście jest jak najbardziej prawidłowe. Natomiast, moim zdaniem, zupełnie bez sensu jest tworzenie kilkudziesięciu handlerów różniących się tylko niektórymi parametrami, bądź wartościami tych parametrów. Pozwólmy aplikacji korzystającej z Solr na trochę swobody i przenieśmy ciężar składania zapytań właśnie na nią.
5. Po co mi nowsza wersja
Podobnie jak w przypadku pliku opisującego strukturę indeksu, tak samo w przypadku solrconfig.xml warto poświęcić czas na spojrzenie co zmieniło się od momentu kiedy wdrażaliśmy ostatnią wersję. Jak wiadomo Solr rozwija się, a co za tym idzie zmienia się konfiguracja. Z doświadczenia wiem, że z różnych względów (np. napięte terminy, brak znajomości Solr), pliki konfiguracyjne Solr podczas aktualizacji są z reguły zostawiane w przysłowiowym spokoju. Powtórzę jeszcze raz – starajmy się uaktualniać pliki konfiguracyjne – poza czasem, jaki teoretycznie tracimy, reszta to już zysk.
6. Domyślna konfiguracja jest dla mojego wdrożenia na pewno optymalna
Tym razem najczęstszy błąd zostawiłem sobie na koniec. Jest to bardzo często powtarzający się błąd, na który zwracam uwagę nie tylko ja. Podkreślam to po raz kolejny – warto poświęcić chwilę czasu (czasami jest to dłuższa chwila) i dostosować pliki konfiguracyjne do naszych potrzeb. W dużej ilości przypadków, konfiguracja kórą sami przygotujemy będzie dużo bardziej optymalna dla naszego wdrożenia, niż konfiguracja stworzona za pomocą pliku konfiguracyjnego dostarczanego razem z Solr.
Na koniec
Tak samo jak w przypadku wpisu dotyczącego błędów w pliku schema.xml (http://solr.pl/2010/08/30/5-grzechow-podczas-projektowania-indeksu-solr/), polecam wpis „The Seven Deadly Sins of Solr”, który można przeczytać pod adresem: http://www.lucidimagination.com/blog/2010/01/21/the-seven-deadly-sins-of-solr/. Lektura warta poświęconego jej czasu.