【问题标题】:Using sql_attr_multi in Sphinx Search在 Sphinx 搜索中使用 sql_attr_multi
【发布时间】:2013-02-09 03:08:29
【问题描述】:

我有一些非常大的表(约 30M 行),它们具有以下类似的结构:
- item_id - uint
- item_text - varchar(255)
- user_id - uint

没有key,可以找到item_id和item_text相同但user_id不同的记录:

item_id, item_text, user_id   
3, text1, 5  
3, text1, 7
4, text2, 5

我正在尝试从 MySQL 迁移到 Sphinx 进行文本搜索,那么我该如何翻译以下内容:
SELECT * FROM table WHERE user_id=123 AND item_text LIKE '%search_string%'。 ?!

在当前的 sphinx 配置设置下,索引器的磁盘空间不足:

source items
{
    ...
    sql_query_pre = SELECT @id := 0
    sql_query     = SELECT @id := @id + 1, item_id, item_text, user_id FROM items
    sql_attr_uint = user_id
    sql_attr_uint = item_id
}

index items_index
{
    source         = items
    path           = ...
    enable_star    = 1
    min_prefix_len = 0
    min_infix_len  = 3
    min_word_len   = 3
}

有没有办法使用 sql_attr_multi 来存储为每个 item_id 找到的 user_id 值?

谢谢!

【问题讨论】:

    标签: indexing full-text-search search-engine sphinx


    【解决方案1】:

    你可以的,

    source items {
        ...
        sql_query     = SELECT item_id, item_text, GROUP_CONCAT(user_id) AS user_id \
                         FROM items GROUP BY item_id ORDER BY NULL
        sql_attr_multi = uint user_id from field;
    }
    

    还要问自己,如果你真的min_infix_len?这极大地增加了磁盘大小(远远超过重复行)。或者试试 dict=keywords

    【讨论】:

    • 已经尝试过 GROUP_CONCAT 并且它有效 :) 我会再研究一下 min_ifix_len,因为它似乎占用了大量磁盘空间。谢谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-03-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多