Sphinx vs. MySql - Sök igenom lista över vänner (effektivitet/hastighet)

Ok, det är så jag ser det här fungera.

Jag har exakt samma problem med MongoDB. MongoDB "erbjuder" sökfunktioner men precis som MySQL bör du aldrig använda dem om du inte vill ha problem med IO, CPU och minne och tvingas använda mycket fler servrar för att hantera ditt index än du normalt skulle göra.

Hela idén med att använda Sphinx (eller annan sökteknik) är att sänka kostnaden per server genom att ha en presterande indexsökare.

Sphinx är dock ingen lagringsmotor. Det är inte lika enkelt att fråga exakta relationer över tabeller, de har åtgärdat detta lite med SphinxQL men på grund av arten av fulltextindex gör det fortfarande inte en integrerad koppling som du skulle få i MySQL.

Istället skulle jag lagra relationerna inom MySQL men ha ett index av "användare" inom Sphinx.

På min hemsida har jag personligen 2 index:

• main (inrymmer användare, videor, kanaler och spellistor)
• hjälp (hjälpsystemsökning)

Dessa delta uppdateras en gång i minuten. Eftersom realtidsindex fortfarande är lite experimentella ibland och jag personligen har sett problem med höga insättnings-/raderingshastigheter håller jag mig till deltauppdateringar. Så jag skulle använda ett deltaindex för att uppdatera de huvudsakliga sökbara objekten på min webbplats eftersom detta är mindre resurskrävande och mer prestanda än realtidsindex (från mina egna tester).

Notera för att bearbeta borttagningar och vad inte din Sphinx-samling genom delta behöver du en killlist och vissa filter för ditt deltaindex. Här är ett exempel från mitt index:

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
}

Detta bearbetar raderingar och tillägg en gång varje minut, vilket i stort sett är realtid för en riktig webbapp.

Så nu vet vi hur vi lagrar våra index. Jag måste prata om relationerna. Sphinx (även om den har SphinxQL) kommer inte att göra integrerade kopplingar över data så jag skulle personligen rekommendera att göra relationen utanför Sphinx, inte bara det utan som jag sa kommer den här relationstabellen att få hög belastning så detta är något som kan påverka Sfinxindex.

Jag skulle göra en fråga för att plocka ut alla ID och använda den uppsättningen av ID:s använda "filter" -metoden på Sphinx API för att filtrera ner huvudindexet till specifika dokument-ID. När detta är gjort kan du söka i Sphinx som vanligt. Detta är den mest effektiva metoden jag har hittat hittills för att hantera detta.

Det viktigaste att komma ihåg hela tiden är att Sphinx är en sökteknik medan MySQL är en lagringsteknik. Ha det i åtanke och du borde vara okej.

Redigera

Som @N.B sa (vilket jag förbisåg i mitt svar) Sphinx har SphinxSE. Även om den är primativ och fortfarande befinner sig i ett slags teststadium av utvecklingen (samma som realtidsindex) tillhandahåller den en faktisk lagring av MyISAM/InnoDB-typ till Sphinx. Det här är häftigt. Det finns dock varningar (som med allt annat):

• Språket är primativt
• Kombinationerna är primära

Men det kan/skulle göra jobbet du letar efter så se till att undersöka det.