在使用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做中文分词扩展

1. 坑

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，杀也不是，不杀也不是……

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