Добре, ето как виждам това да работи.
Имам абсолютно същия проблем с MongoDB. MongoDB „предлага“ възможности за търсене, но точно както MySQL, никога не трябва да ги използвате, освен ако не искате да бъдете задушени от проблеми с IO, CPU и памет и да бъдете принудени да използвате много повече сървъри, за да се справите с вашия индекс, отколкото обикновено.
Цялата идея, ако използвате Sphinx (или друга технология за търсене), е да намалите цената на сървър, като имате ефективен инструмент за търсене на индекси.
Sphinx обаче не е двигател за съхранение. Не е толкова лесно да се потърсят точни връзки между таблици, те поправиха това малко със SphinxQL, но поради естеството на пълния текстов индекс той все още не прави интегрално присъединяване, както бихте получили в MySQL.
Вместо това бих съхранявал връзките в MySQL, но имам индекс на „потребители“ в Sphinx.
В моя уебсайт аз лично имам 2 индекса:
- основен (помещава потребители, видеоклипове, канали и плейлисти)
- помощ (търсене в системата за помощ)
Те се актуализират делта веднъж всяка минута. Тъй като индексите в реално време все още са малко експериментални на моменти и аз лично съм виждал проблеми с високата честота на вмъкване/изтриване, спазвам делта актуализации. Така че бих използвал делта индекс, за да актуализирам основните обекти за търсене на моя сайт, тъй като това е по-малко ресурсоемко и по-ефективно от индексите в реално време (от моите собствени тестове).
Имайте предвид, че за да обработвате изтривания и какво ли не вашата колекция Sphinx чрез делта, ще ви трябва списък за убийства и определени филтри за вашия делта индекс. Ето един пример от моя индекс:
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
}
Това обработва изтривания и добавяния веднъж на минута, което е почти в реално време за истинско уеб приложение.
Така че сега знаем как да съхраняваме нашите индекси. Трябва да говоря за взаимоотношенията. Sphinx (въпреки че има SphinxQL) няма да прави интегрални обединявания между данните, така че аз лично бих препоръчал да правите връзката извън Sphinx, не само това, но както казах, тази таблица на връзките ще получи голямо натоварване, така че това е нещо, което може да повлияе на Индекс на сфинкса.
Бих направил заявка, за да избера всички идентификатори и като използвам този набор от идентификатори, използвам метода "filter" на API на sphinx, за да филтрирам основния индекс до конкретни идентификатори на документи. След като това стане, можете да търсите в Sphinx както обикновено. Това е най-ефективният метод, който открих до момента за справяне с това.
Ключовото нещо, което трябва да помните по всяко време, е, че Sphinx е технология за търсене, докато MySQL е технология за съхранение. Имайте това предвид и трябва да сте добре.
Редактиране
Както каза @N.B (което пропуснах в отговора си), Sphinx има SphinxSE. Въпреки че е първичен и все още е в етап на тестване на своето развитие (също като индексите в реално време), той предоставя действително хранилище от MyISAM/InnoDB на Sphinx. Това е страхотно. Въпреки това има предупреждения (както при всяко нещо):
- Езикът е първичен
- Съединяванията са първични
Въпреки това може/може да свърши работата, която търсите, така че не забравяйте да го разгледате.
