业务系统是否真的需要 Elasticsearch?

[changdy]

前段时间做系统查询优化 , 通过 binlog-kafka 把数据同步到了另一个数据库中 . 技术选型的时候团队内有领导推荐 es , 但是仔细分析之后感觉真正适合 es 的场景并不是很多.但是各种公众号上提到 es 的频率又非常高 , 所以想和大家探讨下 es 的用途 . 由于我没有很深入的使用 , 部分总结可能并不准确 , 还望各位彦祖们多多指点

• 模糊查询

在分词查询这一块 , es 是绝对的王者 . 但是仔细想下 , 对于普通的业务系统 , 是否真的需要全模糊查询 ? 比如说对于手机号和订单号 , 可以创建倒序索引 , 优化成右模糊 . 而对于一般的 cms , 可以通过创建标签和分类的方法进行初筛 , 之后即便是全模糊 , 对于普通网站来说也是可以接受的 . 当然对于知乎这类内容平台肯定是需要搜索系统 , 但 es 好像也无法满足知乎的搜索要求

• 日志查询

大部分日志组件都是用 es 进行存储 , 提高了查询速度 . 但其实我们也可以尝试结构化日志 , 把一条日志解析为操作人 , 操作类型 , 操作对象 id , 操作结果 , 项目名称 , 日志级别 , traceId 等 , 比如"用户 A 购买了商品 c"就可以结构成{"user":"A","type":"pay","target":"c"...} , 结构化之后我们就可以放入到关系型数据库中 . 实际上已经有些日志系统已经开始选用 clickhouse 存储结构化日志 , 可以用低于 es 的成本存储数据 ,并提高几倍的查询速度 , 甚至还可以进行日志分析

• OLAP

针对 olap 领域,es 的竞争对手就更多了 比如上文提到的 clickhouse,还有 Hadoop,Greenplum.我这方面涉猎不多,就不展开了

• 多字段联合查询

引用自 记十亿级 Es 数据迁移 mongodb 成本节省及性能优化实践

有些业务场景，查询条件是由用户触发，查询条件不固定，可能存在多个字段的随机组合查询。mongodb 和 mysql 等数据库，都需要手动创建索引，由于 8 字段以上的随机组合查询情况种类太多，因此很难手动建索引覆盖所有场景.

首先这种情况的确是成立的 , 但实际场景中 , 有些查询条件是非常低频的 , 我们可以先对常用的查询条件创建组合索引 , 之后再根据耗时情况创建索引

所以想了好久 , 感觉对于非 cms 的系统 ,好像 es 还真的不是必须要用的业务组件. 有点困惑,希望彦祖们帮忙分析.

[youngce]

es 除了在一些搜索业务里面是最佳实践以外，很多其他场景下 es 基本都可以随便替换

[fuxkcsdn]

最后一条创建组合索引的问题
数据量足够多的情况下，索引也没用，和 es 的查询速度不在一个量级，再加上并发查询的话（同一个索引，不同查询条件），mysql 直接就 cpu 100%了

[westoy]

既然那么多场景可用可不用的， 最终结合在一起可能还得上， 那为什么不放弃挣扎早点上呢......

[zen1]

CRM 系统，针对每个业务对象，用户可以新建自定义字段，筛选的时候可以用其自己创建的自定义字段进行筛选，而且针对不通租户自定义字段是不同的，这样靠监控慢查询然后建索引应该是解决不了的。

[laozhoubuluo]

1. 不一定，很多时候就是要求全文搜索的，尤其是数仓场景。比如我听说近期出售的空调因为天气太热大量出现不制冷的情况，那么我就要在评价文本里面按时间段进行模糊搜索分析数据了。这种情况下用 MySQL 跑 LIKE 查询肯定是不行的。
2. 理论来说可以，但如果历史系统日志不规范的话改造成完全结构化日志有难度。而且替代系统的生态不如 ES 。
3. OLAP 我也不熟悉，不过很少听说用 ES 做的，感觉不是主要使用场景。
4. 这种在类电商场景里面太多了，而且很多情况下是不能接受一个复杂查询下去整个数据库卡住数秒甚至数十秒的。数仓多等等也没关系，用户搜索个东西卡二十秒怕不是再也不来了。

另外 ES 的确不是必选，全文搜索、日志检索也有其他的替代方案，但 ES 生态明显比替代方案好很多。

[lambdaq]

es 屌炸天。geo 系列平替 postgis 没问题。还有 ML 系列也超好用。

[FYFX]

1. 日志用关系型数据库是在日志数据量很小的情况下吧，要是你日志一天涨几个 G ，关系型数据库基本就没法用了
2. ES 用于 OLAP 其实挺菜的，但现有的 OLAP 又基本没法较好的支持在线服务，大部分在 QPS 100 左右响应时长已经无法接受了，在需要简单 OLAP 场景并需要在线服务支持的情况下 ES 还是挺有用的
3. 还有就是 ES 的空间索引其实挺好用的，GIS 相关的业务就能用的上

[shuimugan]

一开始我也想踢掉 es （ 2c4g 3 节点，580 元 /月），因为我们业务就一个 2c4g 的 PostgreSQ （一主一从，480 元 /月），一张单表同步到 es 做检索，我想 PostgreSQL 搞全文检索问题应该不大。

场景就一个单表（目前千万级，一年内会亿级）的多字段（ 27 个字段）的由用户发起的不确定条件的联合查询 + 几个字段单方向排序。

一开始我验证的是 PostgreSQL 全文检索，腾讯云升级到 4c8g 的一个月才 980 元，开 zhparser 扩展的确很快，几毫秒就搜出来了，但是任意几个字段组合检索就慢得要死（几百毫秒到 1 秒多），更别说 count 一下条数或者 odery by 了。

而在 es 里，2c4g ，检索速度非常稳定，任意字段组合检索都是十几毫秒，于是我打消了踢掉 es 的念头。

[jfds]

CRM 系统用的比较多吧，超多组合的查询条件，不可能全建索引的，影响 mysql 写性能

[yangyaofei]

@shuimugan 请问, PostgreSQL 到 ES 的同步用的是什么, 现在用的 pgsync

[lovephpframework]

实测 es 挺香的,4 亿的数据,3 节点可以在 2 秒内返回结果,每个节点都是 32g 内存,数据量小的话,就没啥必要了

[victorc]

用 es 主要是省事，no schema 架构，方便拓展，开发运维成本都比较低，但是安全漏洞风险很高

[yjhatfdu2]

@shuimugan 这种情况 pg 下可以用 gin 把所有字段做联合索引，这样可以任意组合等值查询

[yjhatfdu2]

@FYFX ES 数据量大了存储开销上升很快，单节点单 index 过亿性能很低，相比较而言 clickhouse 虽然是关系型数据库，但是超大数据量性能要高很多

[dwlovelife]

电商领域，如果没有专门做搜索的部门，ES 可以直接上

[changdy]

@shuimugan 和你遇到的场景类似 , 数据量也接近 . 也考虑过 es .但最后还是选择了 pg .主要是 pg 自带分区表 . 使用 es 的话就必须手动维护分区表 , 会麻烦一些 . 你当初有考虑过 分库分表 或者分区表吗?


@yjhatfdu2 是把几个字段一起放到一起 创建一个 gin 联合索引吗 ? 另外如果中间有时间类型,需要范围查找怎么办呢?

[changdy]

@victorc no schema 但是 还是有 mapping 需要配置的.
@lovephpframework 这个看具体的查询条件吧.如果是比较好的索引 其他数据库 做起来也不一定会差.
@westoy 这个说起来 倒也算是一个理由 .下面的另一个同学也提到了 es 生态比较好

[fuxkcsdn]

@changdy 范围查询无解，但 es 的范围查询速度可以吊打 mysql 和 pgsql ，查询速度根本不在一个数量级

[shuimugan]

@yangyaofei 没有用工具，自己写了几十行 nodejs 的代码就搞定了。

@changdy 完全没考虑，按我的估算数据量到 10 亿，磁盘占用也不到 500G ，在云厂商那里磁盘拉一下进度条扩容就完事了。而且云厂商对 pg 的分布式不太友好，想引导你去它魔改的云原生的版本，贼贵，还不如后面自己用 citus 扩展自建

[changdy]

除了模糊查询外 ,也有很多人提到了 `多字段联合查询` 这一点 . mysql 对这个的支持的确比较差劲 ,pg 会稍微好一些.
针对这种情况的其他解法 ,估计也就是分库分表以及替换成分布式数据库了.


但是国内讨论比较多的不和云服务厂商绑定在一起的原生分布式即时查询数据库除了 es 也就 mongodb 了吧? 不知道 mongodb 的查询效率如何.

另外不知道如果是针对固定的查询条件 , 联合索引能覆盖的时候效率会不会比 es 高一些 ? 以我司为例 , 查询条件是非常不均匀的.

周末有空的话 看看能不能进行一次深度测试..