开发者社区> 问答> 正文

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

近期业务需要,准备上全文检索功能。原始数据是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,杀也不是,不杀也不是……

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

展开
收起
troyzhao 2016-10-01 10:36:25 5040 0
2 条回答
写回答
取消 提交回答
  • 分批导入-更新-建索引?

    2019-07-17 20:13:15
    赞同 展开评论 打赏
  • 公益是一辈子的事, I am digoal, just do it. 阿里云数据库团队, 擅长PolarDB, PostgreSQL, DuckDB, ADB等, 长期致力于推动开源数据库技术、生态在中国的发展与开源产业人才培养. 曾荣获阿里巴巴麒麟布道师称号、2018届OSCAR开源尖峰人物.

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

    2019-07-17 20:13:15
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
2023云栖大会:PolarDB for AI 立即下载
2023云栖大会:AnalyticDB PostgreSQL 立即下载
2022云栖大会:打造世界级云原生数据库开源社区 立即下载