知识卡片
排除高成本字段不索引,通过独立查询路径支撑那一小部分需求
内容
在寻求”能不能减少索引体积”这个问题时,最理想但成本最高的办法是逐个字段审视业务需求,把不需要的field从索引里去掉——这需要对业务有非常深入的理解,短期内很难做到立竿见影。作者给出了一个更取巧但同样有效的判断标准:如果某个字段本身在索引体积里占比极大(案例中description这个内容字段占了索引的一大半),而针对这个字段的查询在整体查询量里只占很小比例,那么完全可以把这整个字段排除在索引之外——文档体积直接减半,整个集群规模也随之减半,内存、硬盘、SSD、主机数量、快照存储乃至各种操作耗时都大幅节省,查询速度自然也跟着提升。对于那一小部分确实需要查询这个被排除字段的请求,不需要为了迁就它们而把整个字段重新纳入主索引,而是可以复用[[Routing是查询性能优化的”王道”:把查询流量按维度拆分到独立小集群]]的思路,把这类查询单独引导到一个专门支持这个字段的独立集群或索引去处理——用一个体量小得多、专门服务少数查询模式的旁路系统去承接长尾需求,主路径不再为了兼顾所有可能的查询而背负不必要的负担。这个案例给出了一条评估”要不要把某类数据/能力放进主系统”的实用判断标准:不必追求让主系统覆盖所有查询场景,而是识别出”体积占比大但查询占比小”的这类数据,把它们剥离到专门的旁路里去,用主系统的轻量化换取绝大多数请求的性能提升。
参考来源
- 位置:《高可用架构(第1卷)》第2章《高可用架构原理与分布式实践》"2.8 亿级规模的Elasticsearch优化实战"节,"2.8.2 查询性能(Query Performance)"(源文件:_epub-src/OEBPS/Text/Chapter2_8_3.xhtml)
- 结论依据:原文说明"根据我们信息的特点,内容(field:description)占了索引的一大半,那我们就不把description索引进ES,doc小了一倍,集群也小了一倍……在上面的实例中,我们可以把查询引入不同集群,自然也可以把询所占比例非常小,我们是可以这样做的",直接支撑本卡片结论。
- 原始内容:根据我们信息的特点,内容(field:description)占了索引的一大半,那我们就不把description索引进ES,doc小了一倍,集群也小了一倍,所用的资源(Memory、HD、SSD、Host、snapshot存储,还有时间)大大节省,查询速度自然也更快……在上面的实例中,我们可以把查询引入不同集群。