在使用PostgreSQL作为千万级文档的全文检索方案时,遇到性能瓶颈-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

在使用PostgreSQL作为千万级文档的全文检索方案时,遇到性能瓶颈

troyzhao 2016-10-01 10:36:25 3277

近期业务需要,准备上全文检索功能。原始数据是2000W+的txt文件,每个文件里面一段文字,平均单个文件大小100k吧。

考虑到对PG的熟悉,也知道它支持全文检索,所以也没多想,就开始往里面导数据……建索引……搜索……掉坑……!!!

——————————————————下面是如何掉坑的——————————————————————

  1. 硬件配置:

阿里云ECS,2CPU/8G内存,自己安装的PG(注意:不是那个独立的RDS产品)

  1. PG版本9.4,参数如下:

fsync off
shared_buffers 1GB
work_mem 10MB
effective_cache_size 2GB
maintenance_work_mem 512MB
checkpoint_segments 32
checkpoint_completion_target 0.9
wal_buffer 8MB
commit_delay 10
commit_siblings 4

  1. 表结构:

CREATE TABLE sys_document
(
id serial NOT NULL, -- 自增主键
doc_content_plain character varying, -- 文本原文
doc_content_plain_tsvector tsvector, -- 文本的搜索分词
doc_content_bin bytea, -- 文本的二进制原文
href character varying, -- 设计用来网络访问的url
created_at timestamp without time zone -- 创建时间
)

  1. 全文检索的相关扩展

采用了zhparser做中文分词扩展

5.1 任何更新操作都如同100岁老太太一样慢

例如:UPDATE sys_document SET href = ''; (6个小时)

例如:UPDATE sys_document SET doc_content_plain_tsvector = to_tsvector('testzhcfg', doc_content_plain character); (跑了2天,被残忍地杀掉)

例如:CREATE INDEX sys_document_doc_content_plain_tsvector_idx ON sys_document USING gin(to_tsvector('testzhcfg', doc_content_plain character)); (3天了,还在跑)

5.2 磁盘占用只增不减

眼睁睁地看着data目录的磁盘占用量,从400G->401G->450G->490G->500G->还在增加。因为VACUUM一执行也没结果了,所以没法VACUUM,连普通VACCUM都不可以,更别说VACCUM FULL了

  1. 悲催的下场

现在,我望着这黑黑的控制台上的进程ID,杀也不是,不杀也不是……

高人来指点一下,这是哪里不对呀?难不成,这方案不通?那只好悲催的浪费了一周时间

弹性计算 自然语言处理 关系型数据库 PostgreSQL 索引 RDS
分享到
取消 提交回答
全部回答(2)
  • 武安君
    2019-07-17 20:13:15

    分批导入-更新-建索引?

    0 0
  • 德哥
    2019-07-17 20:13:15

    2000万全量更新,肯定慢的。 建议你导进去的时候就处理好。 如果要更新也应该是带条件的更新,全量更新不如新建一张表来得快。

    0 0
添加回答
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题