Sphinx vs. MySql - Søg gennem listen over venner (effektivitet/hastighed)

Ok, det er sådan jeg ser det fungere.

Jeg har nøjagtig det samme problem med MongoDB. MongoDB "tilbyder" søgefunktioner, men ligesom MySQL bør du aldrig bruge dem, medmindre du ønsker at blive kvalt med IO, CPU og hukommelsesproblemer og blive tvunget til at bruge mange flere servere til at klare dit indeks, end du normalt ville.

Hele ideen, hvis du bruger Sphinx (eller en anden søgeteknologi) er at sænke omkostningerne pr. server ved at have en effektiv indekssøger.

Sphinx er dog ikke en lagermotor. Det er ikke så nemt at forespørge på nøjagtige relationer på tværs af tabeller, de har afhjulpet dette lidt med SphinxQL, men på grund af arten af ​​fuldtekstindekset laver det stadig ikke en integreret join, som du ville få i MySQL.

I stedet ville jeg gemme relationerne i MySQL, men have et indeks over "brugere" i Sphinx.

På min hjemmeside har jeg personligt 2 indekser:

• main (husker brugere, videoer, kanaler og afspilningslister)
• hjælp (hjælp systemsøgning)

Disse delta-opdateres en gang hvert minut. Da realtidsindekser stadig er lidt eksperimentelle til tider, og jeg personligt har set problemer med høje indsættelses-/sletningshastigheder, holder jeg mig til delta-opdateringer. Så jeg ville bruge et deltaindeks til at opdatere de vigtigste søgbare objekter på mit websted, da dette er mindre ressourcekrævende og mere effektivt end realtidsindekser (fra mine egne tests).

Bemærk, for at behandle sletninger, og hvad ikke din Sphinx-samling gennem delta skal du bruge en killlist og visse filtre til dit deltaindeks. Her er et eksempel fra mit indeks:

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
}

Dette behandler sletninger og tilføjelser én gang hvert minut, hvilket stort set er realtid for en rigtig webapp.

Så nu ved vi, hvordan vi gemmer vores indekser. Jeg har brug for at tale om relationerne. Sphinx (selvom den har SphinxQL) vil ikke lave integrerede joinforbindelser på tværs af data, så jeg vil personligt anbefale at gøre forholdet uden for Sphinx, ikke kun det, men som sagt vil denne relationstabel få høj belastning, så dette er noget, der kan påvirke Sphinx-indeks.

Jeg ville lave en forespørgsel for at udvælge alle id'er og bruge det sæt af id'er, bruge "filter"-metoden på sphinx API til at filtrere hovedindekset ned til specifikke dokument-id'er. Når dette er gjort, kan du søge i Sphinx som normalt. Dette er den mest effektive metode, jeg har fundet til dato til at håndtere dette.

Den vigtigste ting at huske på til enhver tid er, at Sphinx er en søgeteknologi, mens MySQL er en lagringsteknologi. Husk det, og du burde være okay.

Rediger

Som @N.B sagde (som jeg overså i mit svar) har Sphinx SphinxSE. Selvom det er primativt og stadig er i et teststadium af dets udvikling (samme som realtidsindekser), giver det en faktisk MyISAM/InnoDB-type lagring til Sphinx. Det her er fedt. Der er dog forbehold (som med alt muligt):

• Sproget er primært
• Forbindelserne er primære

Men det kan/kunne gøre det job, du leder efter, så sørg for at undersøge det.