Elasticsearch使用经验和云上竞品对比 - 知乎
过去三十年,我们从企业应用开始,经历了 PC 互联网、移动互联网的爆发式发展,到如今的产业互联网。在这些不同时代,一直变化的是应用形态,不变的是核心数据的价值。
对于核心数据的存储,一般都是选择数据库存储,从互联网初期开始,开源关系型数据库 MySQL 成长成为了数据库存储的第一选择,关系型数据库解决了数据的快速建模,高可靠存储和快速查询,但是关系数据库中的高效查询主要依赖二级索引,如果出现索引无法命中的情况就会出现慢查询,降低客户体验。
由于本身索引的实现,这种慢查询在数据库自身中无法彻底解决,只能去优化自身索引结构或者依赖其他系统来实现查询加速,以便减少慢查询对产品能力和可用性的影响。
下面我们以一个社交网络的场景案例来看看如何使用多种方式实现数据库查询加速。
比如在一个社交类型的应用中,需要存储每个用户的状态信息,比如ID、昵称、当前位置、是否在线、手机号码、好友数、签名、隐私特征、标签等。这类数据具有下列典型特征:
针对上述的这些要求,一般的架构都是引入搜索系统,比如 Solr、ES 或者自研的搜索系统来实现查询加速:
这种架构使用 MySQL 存储数据,然后使用 Canal 实时同步 MySQL的数据到下游的 ES 中,Canal 作为通道,ES 作为数据查询加速系统。另外,LogStash 也能同步数据,但是是批量方式,做不到实时同步。
这种可以基本满足上述的需求,但是存在两个问题,一是:
二是在ES侧会存在一些痛点:
传统架构中都会使用 Elasticsearch 做数据查询加速,如果是阿里云的客户,那么这个时候就会多一种选择,使用具有类似功能的数据库替换 ES,比如 Tablestore。Tablestore 是阿里云自研的一款 Serverless 云原生分布式数据库。使用 Tablestore 后,则架构如下:
使用 Tablestore 作为查询加速系统后,则 MySQL 数据可以通过 Canal 实时同步到 Tablestore。之前的一些问题就会迎刃而解:
上述架构主要演示了 Tablestore 作为数据库查询加速系统的方案,如果客户的某些场景不需要事务等关系型数据库的功能,则可以直接使用 Tablestore 作为存储和查询系统。
介绍完使用新系统的架构后,接下来,我们详细对比下 Tablestore 和 ES 在各方面的能力。
在这一节,我们将 Tablestore 和 Elasticsearch 放在一起从多个方面做个对比:
类别 | Elasticsearch | Tablestore | 备注 |
---|---|---|---|
功能 | 1. 任意列自由组合查询 2. 任意列排序3. 全文检索4. 地理位置查询5. 模糊查询6. 统计聚合:Aggregations7. scroll |
1. 任意列自由组合查询 2. 任意列排序3. 全文检索4. 地理位置查询5. 模糊查询6. 统计聚合:Min、Max、Sum和GroupBy等8. ParallelScan 高并发圈选 |
在数据库查询加速场景中,两者的功能满足度基本接近,都可以满足这一场景需求。 |
易用性 | 1. API:Java、Go 等多种 SDK。 2. SQL:开源版不支持(商业版提供简单 SQL 翻译) |
1. API:Java、Go 等多种 SDK 2. SQL:兼容 MySQL 的 SQL 引擎 |
|
成本 | 10 亿订单场景的配置: 1):3台8核16GB的数据节点。2):3台1核2GB的管控节点。3):550GB的存储空间(考虑到后台任务和Log等消耗)。总费用是:5715.12 元/月 |
10 亿订单场景的配置: 1)380GB存储空间2)3 VCU总费用是:3700 元/月。比 Elasticsearch 便宜 35% |
10 亿订单场景: 存储:380GB写入:2000 行/s 查询:200 QPS统计聚合:20 QPS |
运维性 | 需要客户自己负责集群的运维工作: 一:常规线上运维操作:1.1:容量规划和水位管理1.2:索引和集群扩容1.3:版本升级二:线上报警或故障处理:2.1:集群OOM或雪崩2.2:读写性能抖动或持续下降2.3:数据或流量负载不均2.4:索引请求间相互影响,比如离线业务影响在线业务等2.5:磁盘IO、CPU、Net、Full GC 等疑难杂症进程 Crash 和集群重启2.6:ES 或 JVM bug 导致的数据丢失、数据损坏等三:其他:3.1:版本 bug 只能期待新版本能修复3.2:新版本性能下降只能回滚或扩容更多机器 |
零运维 | Tablestore 通过以下措施来保证系统的高可用性: 1)几百项的细粒度 Metric 指标协助性能瓶颈和资源异常等可以快速定位和解决。2)水位系统、软硬件管理平台等系统保证版本平滑升级和容量规划。3)负载均衡系统、自动化运维系统保证常见稳定性问题可以分钟级别自动处理。4)索引画像、标签和分池隔离能力保证不同类型请求之间互相不影响。5)资深云计算、分布式引擎专家 7*24 小时稳定性护航。6)高效的版本迭代速度可以快速修复线上bug、加速功能演进和性能优化生效。 |
零运维的好处是研发可以将全部精力投入在研发上。
上面解释了使用 Tablestore 代替 ES 作为数据库查询加速的优化方案,接下来我们通过一篇实践文章手把手带领大家去感受下如何使用 Tablestore 加速 MySQL的查询,详见文章《车联网场景数据查询加速实践》
上面从架构和实践两个方面介绍了如何使用 Tablestore 来实现查询加速的能力。使用 Tablestore 作为数据查询加速系统并不是最新推出的功能而是已经在业界使用非常频繁和成熟的方案了,接下来会介绍一些典型案例。
某大型互联网公司旗下拥有十几款 App,这些App 都需要维护一个设备表,设备表里面保存了每个设备上安装的App的版本、上次登录时间、用户ID、登录时长等信息,这些信息在用户每次登录时和使用过程中需要不停更新状态。总共的规模有几百亿。查询的时候需要根据运营的特定条件圈选用户,最多可能需要从 10 亿用户中选择出 1 亿用户,这个圈选过程需要越快越好。这种设备圈选系统底层使用了 Tablestore 存储,可以支持每秒 50 万行的 Update 操作,圈选的时候可以支持每秒 1000万行的吞吐能力,完全可以满足业务方的需求。
某短视频类企业拥有一款直播功能,直播的时候需要时刻监测客户端的直播状态,比如是否有卡顿,声音大小、延迟等等,这些直播状态需要每秒更新,而且规模和终端数成正比,最高有上千万,同时,需要时刻统计各种异常终端的数量和地理位置,当发生大面积故障的时候可以第一时间发现和定位问题。这种直播状态的存储和查询就是基于 Tablestore 实现,支持高吞吐更新,上千万规模,毫秒级统计聚合查询能力。
某著名公司存储了全网的各种域名和 IP 的状态信息,这些信息当发生变化的时候就需要更新,规模在百亿以上,查询的时候需要根据特定属性去查询,同时也存在圈选具备某一列特征的域名或ip的功能需求。客户经过多轮选型后,最终选择使用 Tablestore 存储和查询,上线后的体验远超预期。
某 IOT 公司旗下各类产品覆盖了几百亿的设备,这些设备的状态都存储在设备状态表中,这张设备状态表需要频繁高效的更新,同时规模在百亿以上,查询的时候每个设备可能需要直方图统计,百分位、最大值、最小值、平均值等统计聚合能力,有时候也需要按照某个特征找出相关的所有设备的能力。最终客户经过多轮测试和验证,最终选择了 Tablestore 作为数据查询加速系统,从最早的 ES 迁移到了 Tablestore,使用过程总可用性和易用性等都比之前得到了大幅提升。
上面介绍了 Tablestore 作为数据查询加速系统相对于 ES 系统的优势,以及一些成熟案例。ES 是一款非常优秀的开源搜索系统,短短几年时间内就把老一代开源搜索系统 Solr 远远甩在了后面,现在选型搜索系统基本就不用考虑 Solr 了,Solr已趋近淘汰边缘。当前 ES 发展重心在日志、监控、安全、企业搜索等场景方面,在数据库查询加速上的进展相对较慢,如果是数据库查询加速场景,使用 Tablestore 会相对更有优势。
如果看完这篇文章,读者的应用系统中也存在一些数据库查询加速的场景,但是目前使用 ES 存在各种问题,而且很难解决,影响线上业务,则可以选择尝试下 Tablestore,相信肯定会带来不一样的感受。