我目前在PostgreSQL中有一个全文搜索查询(见下文),它扫描一个包含150万行的表,找到所有符合“所有”条款以及“任意”条款的项目。
对于结果很少的查询,查询正确且以平庸的速度(~2-3秒)执行。并且以超过100,000次匹配(约15-100秒)的结果以极快的速度
查询首先按术语类型(所有术语匹配,然后匹配任何术语)对结果进行排序,然后通过ts_rank_cd相关性计算对结果进行子订单。 (以及更简单的变体,它按已知的可以索引的列(如持续时间)排序)
SELECT
*,
ts_rank_cd(textsearchable, query_any_terms) AS relevance,
textsearchable @@ query_all_terms AS all_terms,
sum(1) over (PARTITION BY textsearchable @@ query_all_terms) AS match_method_total,
sum(1) over () AS all_matched_total
FROM
videos,
to_tsquery(?) AS query_any_terms,
to_tsquery(?) AS query_all_terms
WHERE
website IN (?)
AND textsearchable @@ query_any_terms
AND duration_in_seconds >= ?
AND duration_in_seconds <= ?
ORDER BY
all_terms DESC,
relevance DESC
LIMIT ?
OFFSET ?
所有相关列都已编入索引,系统监控显示内存和CPU未充分利用,瓶颈似乎是磁盘IO。
服务器是Ubuntu Server 10.04。可以根据需要动态地通过后端轻松增加内存和CPU功率,以满足解决方案。
目前,数据库在生产时是静态的,并且在生产服务器上不会发生对数据库的写入。因此,如果有益的话,可以完全准确地生成保持准确的指数。
任何有助于找到任何改进途径的帮助都将不胜感激。可根据要求及时提供补充信息。
答案 0 :(得分:1)
使用tmpfs将DB加载到RAM中,查询时间大大提高(即从~100秒秒到~2秒)。
请参阅: http://www.slideshare.net/pgconf/five-steps-perform2009