Дельта-индекс сфинкса игнорирует основной индекс - PullRequest
Новая
       1

Дельта-индекс сфинкса игнорирует основной индекс

0 голосов
/ 24 сентября 2011

У меня действительно странная проблема, когда по каким-то причинам мои индексы просто не функционируют должным образом.

Я создал полностью рабочий дельта-индекс в Sphinx с полными заданиями cron, чтобы поддерживать его в форме ивсе в порядке.

Затем я подхожу к запросу в PHP с: 

class sphinx_searcher{

function __construct(){

    $config = array('host'=>'localhost', 'port'=>9312);

    $this->sphinx = new SphinxClient();
    $this->sphinx->SetServer ( $config['host'], $config['port'] );
    $this->sphinx->SetConnectTimeout ( 1 );
}

function query(){

    $this->sphinx->SetSortMode(SPH_SORT_RELEVANCE);
    $this->sphinx->SetLimits(0, 20); // Testing first page
    $this->sphinx->SetRankingMode(SPH_RANK_PROXIMITY_BM25);
    $this->sphinx->SetArrayResult ( true );
    $res = $this->sphinx->Query("040*", "media media_delta");

    if($res)
        return $res;
    else
        return $this->sphinx->GetLastError();

}
}

По какой-то причине он принимает тот или иной индекс (пока только последний).

Когда я запрашиваю только по медиа, я получаю документы с идентификатором 1 и 2, но когда я запрашиваю по обоим, я получаю только документ с идентификатором 3, который находится в дельта-индексе.

Вот моя конфигурация источника данных: 

source media
{
type            = mysql
sql_query_pre       = SET NAMES utf8
sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(id) FROM documents
sql_query = \
    SELECT id, deleted, _id, uid, listing, title, description, tags, author_name, playlist, UNIX_TIMESTAMP(date_uploaded) AS date_uploaded \
    FROM documents \
    WHERE id<=( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )

sql_field_string = tags
sql_field_string = description
sql_field_string = author_name
sql_field_string = title
sql_attr_uint = deleted
sql_attr_string = _id
sql_attr_string = uid
sql_attr_string = listing
sql_attr_uint = playlist
sql_attr_timestamp = date_uploaded
sql_ranged_throttle = 0
sql_query_info = SELECT * FROM media WHERE id=$id
sql_query_killlist = SELECT id FROM documents WHERE deleted = 0

}


source media_delta : media
{
sql_query_pre = SET NAMES utf8
sql_query = \
    SELECT id, deleted,  _id, uid, listing, title, description, tags, author_name, playlist, UNIX_TIMESTAMP(date_uploaded) AS date_uploaded \
    FROM documents \
    WHERE id>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
}

Вот мой индексный конфиг: 

index media
{
source          = media
path            = /home/sam/sphinx/var/data/media
docinfo         = extern
mlock           = 0
morphology      = stem_en, stem_ru, soundex
min_word_len        = 1
charset_type        = sbcs
min_infix_len       = 2
infix_fields        = title, tags 
enable_star     = 1
expand_keywords     = 1
html_strip      = 0
index_exact_words   = 1
}

index media_delta : media
{
source = media_delta
path = /home/sam/sphinx/var/data/media_delta
}

Я действительно смущен тем, что я ошибся, и я надеюсь, что кто-то здесь может помочь мне выяснить, что не так?

РЕДАКТИРОВАТЬ:

Не использовать все индексы: 

array(9) { ["error"]=> string(0) "" ["warning"]=> string(0) "" ["status"]=> int(0) ["fields"]=> array(4) { [0]=> string(5) "title" [1]=> string(11) "description" [2]=> string(4) "tags" [3]=> string(11) "author_name" } ["attrs"]=> array(10) { ["deleted"]=> int(1) ["_id"]=> int(7) ["uid"]=> int(7) ["listing"]=> int(7) ["title"]=> int(7) ["description"]=> int(7) ["tags"]=> int(7) ["author_name"]=> int(7) ["playlist"]=> int(1) ["date_uploaded"]=> int(2) } ["total"]=> string(1) "0" ["total_found"]=> string(1) "0" ["time"]=> string(5) "0.000" ["words"]=> array(1) { ["040*"]=> array(2) { ["docs"]=> string(1) "2" ["hits"]=> string(1) "2" } } }

Спасибо,

1 Ответ

3 голосов
/ 25 сентября 2011

Проработав несколько вариантов, обнаружил проблему, 

sql_query_killlist = SELECT id FROM documents WHERE deleted = 0

Это говорит о том, что любой документ с "удаленным = 0" исчезнет. То есть будет "убит".

Я полагаю, что в этом контексте его запутанное «попадание» все еще считается в массиве «слов». Несмотря на то, что позже был убит. (массив слов - это необработанное число перед любой фильтрацией - оно прямо из индекса - поэтому любой setFilter (или в этом случае список уничтожений) сделает его завышенным)

Так что измените его на 

WHERE deleted = 1

:)

Всегда самое неожиданное из вещей!

...