海量不可变文档库用ElasticSearch作为主数据库是否可行？

这个场景下把Elasticsearch作为除RTF源文件外的元数据、全文提取内容的主存储，是完全合理的选型，没必要额外引入其他数据库做冗余存储，徒增运维复杂度。

• 你的文档属于不可变内容，只有删除操作、每日新增量极低，刚好避开了ES最突出的短板：频繁更新带来的段合并开销、冗余脏数据问题。数据写入后几乎没有写入侧的运维压力，稳定性和性能表现都会很好。
• 你的核心需求是全文检索，ES原生的倒排索引、多语言分词、多条件组合检索能力就是为这类场景设计的，不需要额外做组件适配，整条数据链路最短，出问题的概率最低。
• 低写入、无更新的负载下，只要做好初始分片规划，单ES集群支撑PB级的元数据+提取后全文内容存储都没有稳定性问题，自带的多副本机制足够保障数据可靠性。
• 你已经单独存储了RTF源文件，就算遇到极端情况ES索引损坏，直接从源文件重新做一次全量提取建索引就能恢复，不存在不可逆的数据丢失风险，完全满足主存储的可靠性要求。

• 坚持现在的方案，不要把RTF源文件存入ES，ES中只存结构化元数据、从RTF提取的纯文本检索内容、对应源文件的存储路径标识即可，避免索引体积无意义膨胀。
• 提前根据总数据量规划分片数，单分片大小控制在30G-50G区间即可，因为后续新增量极低，分片数一次规划到位就不需要后续调整，不要设置过多分片浪费集群资源。
• 存量数据全部导入完成后，直接对索引执行force_merge操作把段数压缩到1，能大幅提升检索性能，也能彻底消除后续段合并的资源占用——毕竟后续几乎没有写入，做完强制合并后集群基本不会出现无意义的资源波动。
• 删除操作尽量攒批处理，不要高频做单条硬删除；如果文档是按固定批次归档的，可以直接按批次拆分索引，需要删整批文档时直接删除对应索引，比单条删除效率高得多，也不会产生大量删除标记拖慢检索速度。
• 集群至少配置1个副本，定期做索引快照备份。虽然有源文件可以重建索引，但快照能在故障时快速恢复服务，省去重新做全量文本提取、建索引的时间成本。

内容的提问来源于stack exchange，提问作者Serhii Mirko