Ok, tak to widzę.
Mam dokładnie ten sam problem z MongoDB. MongoDB "oferuje" możliwości wyszukiwania, ale podobnie jak MySQL, nigdy nie powinieneś ich używać, chyba że chcesz być zadławiony problemami z IO, procesorem i pamięcią i być zmuszonym do używania znacznie większej liczby serwerów do obsługi indeksu niż zwykle.
Cała idea korzystania ze Sphinxa (lub innej technologii wyszukiwania) polega na obniżeniu kosztu na serwer dzięki wydajnej wyszukiwarce indeksów.
Sphinx nie jest jednak silnikiem pamięci masowej. Zapytanie o dokładne relacje między tabelami nie jest tak proste, naprawiono to trochę za pomocą SphinxQL, ale ze względu na naturę indeksu pełnotekstowego nadal nie wykonuje on integralnego złączenia, jak w przypadku MySQL.
Zamiast tego przechowywałbym relacje w MySQL, ale miałbym indeks „użytkowników” w Sphinx.
W mojej witrynie osobiście mam 2 indeksy:
- główny (domy użytkowników, filmy, kanały i listy odtwarzania)
- pomoc (wyszukiwanie systemu pomocy)
Są to zmiany delta aktualizowane co minutę. Ponieważ indeksy czasu rzeczywistego są czasami nieco eksperymentalne i osobiście widziałem problemy z wysokimi współczynnikami wstawiania/usuwania, trzymam się aktualizacji delta. Dlatego użyłbym indeksu delta do aktualizacji głównych obiektów, które można przeszukiwać w mojej witrynie, ponieważ wymaga to mniej zasobów i jest bardziej wydajne niż indeksy czasu rzeczywistego (z moich własnych testów).
Zwróć uwagę, że aby przetwarzać usunięcia, a co nie swoją kolekcję Sfinksa przez deltę, będziesz potrzebować listy zabójstw i pewnych filtrów dla swojego indeksu delta. Oto przykład z mojego indeksu:
source main_delta : main
{
sql_query_pre = SET NAMES utf8
sql_query_pre =
sql_query = \
SELECT id, deleted, _id, uid, listing, title, description, category, tags, author_name, duration, rating, views, type, adult, videos, UNIX_TIMESTAMP(date_uploaded) AS date_uploaded \
FROM documents \
WHERE id>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 ) OR update_time >( SELECT last_index_time FROM sph_counter WHERE counter_id=1 )
sql_query_killlist = SELECT id FROM documents WHERE update_time>=( SELECT last_index_time FROM sph_counter WHERE counter_id=1 ) OR deleted = 1
}
Przetwarza to usuwanie i dodawanie raz na minutę, co w przypadku prawdziwej aplikacji internetowej odbywa się prawie w czasie rzeczywistym.
Więc teraz wiemy, jak przechowywać nasze indeksy. Muszę porozmawiać o związkach. Sphinx (mimo, że ma SphinxQL) nie będzie wykonywał złączeń integralnych na danych, więc osobiście polecam tworzenie relacji poza Sphinxem, nie tylko to, ale jak już powiedziałem, ta tabela relacji będzie mocno obciążona, więc jest to coś, co może wpłynąć na Indeks Sfinksa.
Zrobiłbym zapytanie, aby wybrać wszystkie identyfikatory i używając tego zestawu identyfikatorów, użyj metody „filtru” w interfejsie API sfinksa, aby przefiltrować główny indeks do określonych identyfikatorów dokumentów. Gdy to zrobisz, możesz normalnie wyszukiwać w Sphinx. Jest to najskuteczniejsza metoda radzenia sobie z tym, jaką znalazłem do tej pory.
Kluczową rzeczą do zapamiętania jest to, że Sphinx to technologia wyszukiwania, podczas gdy MySQL to technologia przechowywania. Pamiętaj o tym i powinieneś być w porządku.
Edytuj
Jak powiedział @N.B (co przeoczyłem w mojej odpowiedzi), Sphinx ma SphinxSE. Chociaż jest prymitywny i nadal znajduje się w fazie testowania (tak samo jak indeksy czasu rzeczywistego), zapewnia on Sphinxowi rzeczywiste miejsce przechowywania typu MyISAM/InnoDB. To jest niesamowite. Istnieją jednak zastrzeżenia (jak w przypadku wszystkiego):
- Język jest prymitywny
- Złączenia są pierwotne
Jednak może / może wykonać pracę, której szukasz, więc pamiętaj, aby się temu przyjrzeć.
