Domyślna konfiguracja Sphinx wystarcza wielu na implementację różnych aplikacji w standardowych środowiskach serwerowych. Co jednak zrobić gdy rozmiar danych wśród których chcemy wyszukiwać jest ogromny?

Jeśli mamy kilkadziesiąć milionów rekordow a nawet kilkaset sprawa się komplikuje. Problemów jest wiele, wystarczy wspomnieć:

• limity nałożone na pojedyńczy index. Nie może on przekroczyć 4GB.
• problem reindeksacji danych. jeśli dane ulegają ciągłej zmianie to reindeksacja wszystkich danych w jednym indeksie spowoduje ciągłe dodatkowe/niepotrzebne obciążenia serwera
• problem z szybkościa i wydajnością wyszukiwania

Rozwiązaniem na powyższe problemy może być wykorzystanie wieloprocesorowego środowiska o ile takim dysponujemy.

Po kolei…

Mechanizm Sphinx został tak skonfigurowany że możemy skorzystać z rozproszonych indeksów.  Zamiast tworzyć jeden duży index możemy podzielić go na kilka mniejszych.  Dzięki temu rozwiązujemy od razu kilka problemów. Pierwszy to problem limitu 4GB na jeden index. Drugą nie mniej ważną rzeczą jest ułatwienie sobie procesu reindeksacji. Przy odpowiednio dobranym algorytmie dzielenia danych do każdego indexu można w łatwy sposób ograniczyć reindeksację tylko tych indeksów które są nam potrzebne. Algorytm powinien być uzależniony od rodzaju danych, czy dane są często modyfikowane czy też tylko narastają nowe dane. W ten sposób możemy ograniczyć proces reindeksacji do minimum.

Przy standardowej konfiguracji (zwykły indeks) mamy:

soruce source1 {   type = mysql   sql_query = SELECT id,subid,content FROM my_data    ... }  index index1 {   type = plain   source = source1   ... }

Jeśli chcemy zastosować indeksy rozproszone musimy stworzyć kilka indeksów:

source source1a {   type = mysql   sql_query = select id,subid, content,my_filter FROM my_data WHERE (my_filter = 1) }  source source1b {   type = mysql   sql_query = select id,subid, content,my_filter FROM my_data WHERE (my_filter = 2) }  source source1c {   type = mysql   sql_query = select id,subid, content,my_filter FROM my_data WHERE (my_filter = 3) }  source source1d {   type = mysql   sql_query = select id,subid, content,my_filter FROM my_data WHERE (my_filter = 4) }  index index1a {  type = plain  source = source1a }  index index1b {  type = plain  source = source1b }  index index1c {  type = plain  source = source1c }  index index1d {  type = plain  source = source1d }  index index1 {   type = distributed   local = index1a   local = index1b   local = index1c   local = index1d }

Możemy jeszcze pójść dalej. Jeśli dysponujemy odpowiednim sprzętem możemy rozdzielić indexy na różne procesory ustawiając w konfiguracji:

searchd {   dist_threads = 4 }

Wykorzystamy odpowiednio zasoby naszego serwera zarówno do reindeksacji jak i wyszukiwania.

Należy jednak z podziałem odpowiednio uważać. Zbyt duża liczba indeksów może doprowadzić do pogoroszenia wydajności wyszukiwania. Najbardziej odpowiednią ilością indeksów jest od 2-4. Niestety przy większej ilości danych trzeba zastosować większą ilość indeksów ze względu na ograniczenia wielkości indeksu co jednak możemy sobie zrekompensować optymalnym dołożeniem procesorów dla każdego indexu.

Przykładowo przy 5 indexach i dist_threads=2 indexy zostaną podzielone  w stosunku 3 i 2 na każdy procesor. Jeśli zmodyfikujemy dist_threads  na 5 to wtedy każdy index zostaine osobno obsłużony.

Warto jednak zauważyć jeszcze jedną kwestię. Zbyt duża liczba procesorów na jeden index nie spowoduje zwiększonej wydajności wyszukiwania danych. Wyniki wyszukiwania np. dla 3 indeksów przy zastosowaniu 4 lub 3 procesorów będą zbieżne.

Reasumując

Budując system wyszukiwawczy należy wziąć pod uwagę wszystkie aspekty: rozmiar danych, wielkość indeksów, sprzęt jakim dysponujemy. Nieodpowiedni podział danych może nie tylko nie spowodować poprawy wydajności systemu ale nawet ją obniżyć i gdy w przypadku małej liczby danych nie będzie to zauważalne to przy problemu dużych danych stanie się to znacząco widoczne.