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.