Sphinx - most gyorskereső Anatolij Larin

előző ◈ a következő

Ma már nehéz elképzelni, hogy nem egy jó hely a keresés funkciót. Ezzel nem csak keresni, de a támogatást a morfológia. A legtöbb esetben elég, hogy támogassa az orosz és angol nyelven.

Tehát, ha a fejlődő a következő projekt az volt, hogy a probléma. A táblák az adatbázisban nem kicsi (100 000 bejegyzés), plusz még meg kell keresni több, úgy, hogy a lehetőséghez hasonlóan a hagyományos „% query%” csepegtetünk magától.

Korábban használtam a kereső mnoGoSearch. de eszébe jutott hanyag API (néha skaladyvalos benyomást kelti, hogy ő írta az indiánok 5 osztály a plébániai iskola) csökkent, és ez a verzió.

Ennek eredményeként nem volt 2 lehetőség:

levelet keresés alapján építését a mutatók, és tárolja ezeket az indexeket, például BerkleyDB;
Nem újra feltalálni a kereket, és hogy az egyik leggyorsabban keresők - Sphinx.

Azért választottam a második lehetőséget :)

By the way, Sphinx - a projekt a honfitársunk, Andrey Aksenov. Érdemes megjegyezni, hogy Andrey elég időt és energiát, nem csak, hogy folyamatosan javítsa a projekt, hanem aktívan részt vesznek a felhasználók támogatása opreativno kérdések az angol és orosz nyelvű fórum. Mert hogy ő nagyon köszönöm!

És így, kezdjük gyakorolni. Mércét, és nem okoz semmilyen problémát.

Töltse az archívum a forrás (a legújabb verzió, mint az írás), csomagold ki és telepítsd:

# ./configure
# make
# Make install (a root)

Az alábbi 3 FreeBSD csapat kaptam a termék felhasználásra kész. De a Debian volt egy perc, hogy rendetlenség (bár az első alkalommal tartott fél órát :) és futtatni:

# Sudo aptitude install libmysql ++ - dev libmysqlclient15-dev checkinstall

akkor minden jól keresett.

edzés

Most már készen áll létrehozni az index (feltételezem, hogy van egy projekt, amely egy kész adatbázis). Adatbázisunk szerkezete a következő:

Mi meg fogja keresni a termék nevét, leírását és címkéit. Ezért szükséges, hogy hozzon létre egy indexet a következő területeken. Ehhez hozzon létre egy 2 / home / Larin / data / - itt tároljuk az index fájlokat, és / home / Larin / log / - azonnal naplózza és konfigurációs fájl /home/larin/sphinx.conf

Ez a konfiguráció, Sphinx kész a indexelése az adatokat egy óriási sebességgel :) További információ konfigurálásával jelentkezzen be a hivatalos honlapján a dokumentációk. Ez az angol, de a nehézségek nem okoz, mert meg van írva egyszerűen és kedvező áron.

morfológia

Spninx támogatja indexelés (és így a kereső), figyelembe véve a morfológia orosz és angol nyelven. Support morfológia megvalósítható kísérése.

Adódóan - a vezető folyamat izolálása szár egy szót a komplex szóalakok.

Itt vannak a vonalak a config felelős konfiguráció:

indexelés

Kezdje létrehozása az index:
# Indexelőt -config /home/larin/sphinx.conf -minden

Minden index jön létre! Keressünk!

kereső eszköz alkalmas hibakeresés és tesztelés az index teljesítményét. Használati példa:
# Keresés -config /home/larin/sphinx.conf keresési kifejezést

De az igazi munka, meg kell kezdeni a démon szfinx - searchd:
# Searchd -config /home/larin/sphinx.conf

Minden démon Sikeresen kezdődött (by the way, jól tennék hozzá, hogy az indítási :). és most már dolgozni vele a mi PHP-scriptek a hivatalos API-t. Sphinxapi.php szükséges könyvtár helyezkedik el a letöltött archív a api könyvtárba.

Parancsfájlpélda

Ez minden. És akkor ismét (mint jelen esetben az UML és a cache) Győződjön meg arról, hogy minden zseni egyszerű :)

Bocs, én mindent leírtak és az angol elment keresni egy durranás, és az orosz voobsche nem keres.
Dob: Notice: Undefined index: mérkőzésekkel /bhome/part3/03/avenirru/avenir.ru/www/test.php on line 37

Tudás 37. sor: if ($ eredmény is_array ($ result [ 'mérkőzést']))

azaz A tömb nem létezik, mert nem talál semmit (((
csavarmenetelemek aki szembesül nehézségekkel oroszul?

Itt vagyok észre
az indexelés a beállítások ismertetett ered kimenet: indexelés index „hírek” ...
ERROR: index 'hírek': sql_query_pre [0]: Ismeretlen rendszer változót 'names' (DSN = mysql: // avenir_ru: ***@baze.avenir.ru: 64000 / avenir_ru).
Összesen 0 Docs, 0 bájt
összesen 0,051 sec, 0,00 byte / sec, 0,00 docs / sec

Azt mondja, nem érti a sort: sql_query_pre = SET NEVEK cp1251

Mi a MySQL verzió?

Az 5-ös verzió, és tegye rájött a hiba megszűnt. De az orosz kereső nem megy, a jelenlegi angol

Itt van a config segítség helyes, mi a baj (táblázatok és adatbázisok utf8):
forrás hírek
type = mysql
sql_host = mysql.baze.avenir.ru
sql_user = avenir_ru
sql_pass = ******
sql_db = avenir_ru
sql_port = 64.547

sql_query_pre = SET CHARACTER_SET_RESULTS = utf8
sql_query_pre = SET NAMES utf8
sql_query_pre = SET CHARACTER SET utf8

sql_query = SELECT n.news_id, n.title, n.body SZÁRMAZÓ `news` n

sql_query_info = SELECT * FROM `news` WHERE` news_id` = $ id
sql_ranged_throttle = 0
>

index hírek
forrás = hírek
path = / bhome / part3 / 03 / avenirru / szfinx / sphinks / var / data / hírek
docinfo = extern
MLOCK = 0
morfológia = stem_ru, stem_en
min_word_len = 2
charset_type = utf-8
charset_table = 0..9, A..Z-> a..z, _, a..z, U + A8> U + B8, U + B8, U + C0..U + DF-> U + E0..U + FF, U + E0..U + FF
min_infix_len = 2
enable_star = 1
>

searchd
address = 127.0.0.1
port = 3312
log = /bhome/part3/03/avenirru/sphinx/sphinks/var/searchd.log
query_log = /bhome/part3/03/avenirru/sphinx/sphinks/var/query.log
read_timeout = 5
max_children = 30
pid_file = /bhome/part3/03/avenirru/sphinx/sphinks/var/searchd.pid
max_matches = 1000

// Most levezetni ezeket a termékeket fontossági sorrend szerint rendezve
$ Id_list = implode ( '', $ ids);
$ Sql = sprintf ( 'SELECT * FROM `product` WHERE` product_id` IN (% s) ORDER BY FIELD (` product_id`,% s)', $ id_list, $ id_list);

// Minden további teljesíti ezt a kérést, és élvezze az eredményt

és a lekérdezés által végrehajtott bármely Sphinx.

Ez a lekérdezés végre az osztály munkáját az adatbázis, jól, vagy egyszerűen csak a mysql_query () függvény)))

))) Köszönöm, hogy csak akkor, ha nem világos, hogy milyen sebesség növelése? Ha kiderül már végre 2 lekérdezés. Először Sphinx az indexet, majd egy másik, és mi vagyunk az adatbázisban?
Elnézést a buta kérdések.)))

A nyereség az, hogy a Szfinx, ellentétben MySQL néz való bejegyzés az index egy hatalmas sebesség és minden területén.
És mi csinálunk csak egy kérelmet (az egyik a IN), ami nagyon gyors. mert Keresés az elsődleges kulcsot a táblázatban. Hol látja a kérést 2.

Indexelésekor? Mivel ez a folyamat fut sokkal ritkábban, mint a referenciák a keresést. Van néhány oldal Újraindexelés fut naponta csak egyszer)

Pol_uha. hogy még mindig nem érti?

És ha szükséges mezőket a táblázatban már indexelve, miért Sphinx egyszerűen csak nem veszi ki őket, és nem jelenik meg, és még mindig van, hogy a kérelmet az adatbázisba?
Nagyon köszönöm, szuper blog. Olvassa el más cikkek.)))

A Szfinx index az adathordozón tárolt helyett magát az adatot. Látod a különbséget?

Örülök, hogy a blog olyan, mint segítség)

Értsd)))
Vagy segíthet ebben a feladatban:
Van egy táblázat a nevét az állatok és id városban, ahol ezek találhatók)))
Indexelt tábla 2 rendre: ezt és ezt.
A férfi hozott egy teknős vagy teknősbéka Moszkva Moszkva, stb
hogyan lehet belőle közötti kölcsönhatás ezeket a 2 táblát? Ie Minden teknősök és ellenőrzött id városok, ahol élnek, és összehasonlítjuk az id a városok az asztalhoz, ahol a nevek, és összehasonlítjuk a 2. szó, ebben az esetben a „Moszkva”?
Bagoly. ))))

És így van 2 táblázatok:
város [town_id, town_title] és
állati [animal_id, animal_title, town_id]

Ennek megfelelően szükséges, hogy összekapcsolják őket, hogy megteremtse a megfelelő index. mert Meg fogjuk vizsgálni az állatok az elsődleges kulcsot a lekérdezés eredményét fogjuk animal_id.
kapjuk:
sql_query = SELECT animal_id, animal_title, town_title FROM `animal` egy bal JOIN` town` t ON a.town_id = t.town_id

Mind))) Most, az index lesz építve: a keresés végzik a város nevét és a kis állatokat.

ZY LEFT JOIN készül arra az esetre, ha ez egyáltalán nem kis állatok miatt a városi életet.

Szia))) veszekedni megint. És nem figyelmeztet érdekében, hogy az abszolút Sphinx keresése. Ie amikor beírja a „Black víziló”
Nem adta az összes rekordot, amikor azt mondja, „fekete” és a „víziló” külön, de csak akkor, ha van egy mondat teljesen?

A probléma az, hogy a szokásos MySQL keresés nagyon lassú.

Kérés érkezik a következő fajok:

Ie használt like '% ...%'. A dokumentáció mondja, hogy amikor használni, mint a „% ...%” indexek nem működnek, és használják néhány „Turbo Boyer-Moore algoritmus” (állítólag).
Úgy működik, nagyon lassan. Én még soha nem várta a végén a keresés, még a két entitás.

Keresés a szerződés alapján - a keresést a három. Úgy döntött, hogy a Szfinx. SphinxQL mert könnyebb neki, hogy másolja.

Most, ha jól értem, meg kell tennünk három forrásból:
1.) Keleten. ügyfelek.
2.) Keleten. TC.
3.) Keleten. szerződéseket.

És három mutatók:
1.) az ügyfélnek szüksége egy indexe 1.
2.) A tartón van egy TS, azaz TC szüksége egy index az 1 és 2.
3.) A szerződés 1, 2, 3.

A probléma abban rejlik, hogy egyrészt a magam, nem várja meg a végét index létrehozása, legalábbis az ügyfelek (a táblázatban, de csak egy

15500 rekord).
Test index táblázat létrehozása 149 bejegyzés.
Miért ilyen sokáig? Mit csinálok rosszul?
Másodszor, szeretnék az adatok fogadására, és nincs azonosító.
Talán ez történhet Sphinx (hogy például egy kérést, hogy MySQL)?

előző ◈ a következő