Sphinx vs. MySql – prohledávejte seznam přátel (efektivita/rychlost)

Dobře, takhle to vidím, že to funguje.

Mám úplně stejný problém s MongoDB. MongoDB „nabízí“ možnosti vyhledávání, ale stejně jako MySQL byste je nikdy neměli používat, pokud nechcete být udušeni problémy s IO, CPU a pamětí a nechcete být nuceni používat mnohem více serverů, aby se vypořádali s vaším indexem, než byste normálně používali.

Celá myšlenka, pokud používáte Sphinx (nebo jinou vyhledávací technologii) je snížit náklady na server tím, že budete mít výkonný indexový vyhledávač.

Sphinx však není úložištěm. Není tak jednoduché dotazovat se na přesné vztahy mezi tabulkami, trochu to napravili pomocí SphinxQL, ale kvůli povaze fulltextového indexu stále neprovádí integrální spojení, jako byste získali v MySQL.

Místo toho bych uložil vztahy v MySQL, ale měl bych index "uživatelů" v rámci Sphinx.

Osobně mám na svém webu 2 indexy:

• hlavní (umístí uživatele, videa, kanály a seznamy videí)
• nápověda (nápověda k vyhledávání systému)

Tyto jsou delta aktualizovány jednou za minutu. Vzhledem k tomu, že indexy v reálném čase jsou občas stále trochu experimentální a osobně jsem zaznamenal problémy s vysokou mírou vkládání/mazání, držím se delta aktualizací. Takže bych použil delta index k aktualizaci hlavních prohledávatelných objektů mého webu, protože je to méně náročné na zdroje a výkonnější než indexy v reálném čase (z mých vlastních testů).

Poznamenejte si, že chcete-li zpracovat mazání a co ne vaše sbírka Sphinx přes delta, budete potřebovat killlist a určité filtry pro váš delta index. Zde je příklad z mého indexu:

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
}

Toto zpracovává odstranění a přidání jednou za minutu, což je téměř v reálném čase pro skutečnou webovou aplikaci.

Nyní tedy víme, jak ukládat naše indexy. Musím si promluvit o vztazích. Sphinx (i když má SphinxQL) nebude provádět integrální spojení napříč daty, takže osobně bych doporučil udělat vztah mimo Sphinx, nejen to, ale jak jsem řekl, tato tabulka vztahů bude mít vysoké zatížení, takže to je něco, co by mohlo ovlivnit Index sfingy.

Udělal bych dotaz, abych vybral všechna id a pomocí této sady id bych použil metodu „filtru“ v rozhraní sphinx API k filtrování hlavního indexu až na konkrétní ID dokumentů. Jakmile to uděláte, můžete ve Sfingě normálně hledat. Toto je nejvýkonnější metoda, kterou jsem doposud našel, jak se s tím vypořádat.

Klíčová věc, kterou je třeba mít na paměti, je, že Sphinx je vyhledávací technologie, zatímco MySQL je technologie úložiště. Mějte to na paměti a měli byste být v pořádku.

Upravit

Jak řekl @N.B (což jsem ve své odpovědi přehlédl), Sphinx má SphinxSE. Přestože je primativní a stále v jakési testovací fázi svého vývoje (stejně jako indexy v reálném čase), poskytuje Sphinx skutečné úložiště typu MyISAM/InnoDB. To je úžasné. Existují však upozornění (jako u čehokoli):

• Jazyk je primativní
• Spojení jsou primativní

Nicméně to může/mohlo dělat práci, kterou hledáte, takže se na to určitě podívejte.