[转载] DB 与 Elasticsearch 混合之应用系统场景分析探讨

作者介绍

李猛,Elastic Stack深度用户,通过Elastic工程师认证,2012年接触Elasticsearch,对Elastic Stack技术栈开发、架构、运维等方面有深入体验,实践过多种大中型项目;为企业提供Elastic Stack咨询培训以及调优实施;多年实战经验,爱捣腾各种技术产品,擅长大数据,机器学习,系统架构。

名词解释

image.png

DB:database,泛指关系型数据库,具有严格事务隔离机制的数据类库产品,如 mysql、sqlserver、postgresql、oracle、db2 等,db-engine 综合排名前面的全部是关系型数据库;

ES:Elasticsearch,最好的开源搜索引擎产品,NoSQL 非关系型数据库,不具备严格事务隔离机制,当前 db-engine 综合排名第七;

应用:本文泛指业务应用系统,是 OLTP 场景,非 OLAP 场景,大量运用事务型数据库产品的业务系统;

索引:在关系型数据库中是指数据检索的算法,在 Elasticsearch 是指数据存储的虚拟空间概念,类同数据库中的表。

背景需求

• 为什么单一 DB 不能满足应用系统?
• 为什么单一 ES 不能满足应用系统?
• 为什么要使用 DB 结合 ES 混用的模式?

而不是结合其它 NoSQL?比如 MongoDB?下面从技术层面与业务层面分析探讨。

技术层面

image.png

DB 局限性

关系型数据库索引基于最左优先原则,索引要按照查询需求顺序提前创建,不具备任意字段组合索引能力比如 某 xxx 表有 30 个字段,若要求依据任意字段组合条件查询,此时关系型数据库显然无法满足这种灵活需求,包括当下很受欢迎的 NoSQL 明星产品 Mongodb 也不能满足。

关系型数据库支持有限度的关联查询,一般在业务应用系统中,关联表会控制在 2~3 个表(个人观点:有 3 个表关联的业务场景需要由技术架构师评估是否容许,开发工程师只容许 2 个表关联),且单表的数据量是要平衡考虑才可以,跨同构数据库源关联就更加不容许。

那跨异构数据库源呢?不是不容许,实在是有心无力。关系型数据库普遍采用 B+ 树数据结构实现索引查询,面对超大数据量处理有天然的瓶颈,数据量超过百万千万级,复杂点的查询,性能下降很快,甚至无法运行。

关系型数据库虽然也支持主从同步,支持读写分离,但集群是一种松散式的架构,集群节点感知能力脆弱,不成体系,弹性扩展能力不行。

ES 互补性

Elasticsearch 基于 Lucene 核心库构建,以倒排索引算法为基础,集成多种高效算法。Elasticsearch 默认为所有字段创建索引,任索引字段可组合使用,且查询效率相当高,相比关系型数据库索更加高效灵活。在业务系统中,有很多场景都需要这种任意字段组合查询的能力,简称通用搜索。

Elasticsearch 的数据模型采用的是 Free Scheme 模式,以 JSON 主体,数据字段可以灵活添加,字段层级位置也可以灵活设置 ,关系数据库中需要多表关联查询,在 Elasticsearch 中可以通过反范式的关联能力,将多个业务表数据合并到一个索引中,采用对象嵌套的方式。

Elasticsearch 天然分布式设计,副本与分片机制使得集群具备弹性扩展能力,可以应付超大的数据量查询,在单索引数据量十亿级也可以在亚秒内响应查询。

Elasticsearch 的索引支持弹性搜索,可以指定一个索引搜索,也可以指定多个索引搜索,搜索结果由 ES 提供过滤合并,这就为业务系统提供了很灵活的操作空间,特别是在实时数据与历史数据方面,统一查询条件语法皆可执行。

Elasticsearch 支持数据字段与索引字段分离,默认情况下,数据字段与索引字段是同时启用,实际在业务业务场景中,数据表中很多字段无需检索,只是为了存储数据,在查询时方便取回;很多检索字段也无需存储原始数据,只是检索过滤使用。

DB 不等于 ES

关系数据库定位全能型产品,强事务机制,数据写入性能一般,数据查询能力一般。Elasticsearch 定位查询分析型产品,弱事务机制,查询性能非常不错。DB 与 ES 各有优势劣势,不能等同取代。

业务层面

image.png

业务领域复杂度

在进入互联网/移动互联网/物联网之后,业务系统数据量的几何倍数增长,传统应当策略当然是采用分库分表机制,包括物理层面分库分表,逻辑层面分区等。非重要数据可以采用非关系型数据库存储,重要的业务数据一定是采用关系数据库存储,比如物流速运行业的客户订单数据,不容许有丢失出错。

面对复杂业务系统需求,当下最流行的解决方式是采用微服务架构模式,微服务不仅仅局限上层应用服务,更深层次的是底层数据服务(微服务不在本次讨论之内),基于领域模型思维拆分分解。应用服务拆分成大大小小数个,可以几十个几百个,也可以更多,数据服务也拆分成大大小小数个。

业务查询复杂度

分库分表解决了数据的存储问题,但需要做合并查询却是个很麻烦的事,业务系统的查询条件一般是动态的,无法固定,更加不可能在分库分表时按照所有动态条件设计,这似乎代价太大。一般会选择更强大的查询数据库,比如 Elasticsearch 就非常合适。

微服务架构模式解决了业务系统的单一耦合问题,但业务系统的查询复杂度确实提高不少,复杂点的应用服务执行一次查询,需要融合多个领域数据服务才能完成,特别是核心领域数据服务,几乎贯穿一个系统所有方面,比如物流速运行业订单领域。

DB 与 ES 结合

业务数据存储由关系型数据库负责,有强事务隔离机制,保障数据不丢失、不串乱、不覆盖,实时可靠。
业务数据查询由 Elasticsearch 负责,分库分表的数据合并同步到 ES 索引;跨领域库表数据合并到同步 ES 索引,这样就可以高效查询。

DB 与 ES 结合问题

image.png

关于DB与Elasticsearch混合主要有以下两个问题:同步实时性、数据一致性,本文不探讨此问题,后续会有专题讲述如何解决。

混合场景

前面已经论证了关系型数据库与 Elasticsearch 混合使用的必要性,接下来是探讨混合场景下的业务场景数据模型映射。

单数据表 ->单索引

image.png

1)一对一映射关系,关系数据库有多少个表,Elasticsearch 就有多少个索引;

2)关系数据库提供原始数据源,Elasticsearch 替代数据库成为查询引擎,替代列表查询场景;

3)单数据表为水平分库分表设计,需要借助Elasticsearch 合并查询,如图:电商行业订单场景,日均订单量超过百万千万级,后端业务系统有需求合并查询;

4)单数据表业务查询组合条件多,数据库索引查询能力局限,需要借助 Elasticsearch 全字段索引查询能力,主要替代列表查询场景。如:电商行业商品搜索场景,商品基础字段超过几十个,几乎全部都可以组合搜索。

单数据表 ->多索引

image.png

1)一对多映射关系,单数据表映射到多个索引中;
2)单数据表即作为 A索引的主体对象,一对一映射;
3)单数据表也作为 B索引的子对象,嵌入到主体对象下面;
4)基于微服务架构设计,在业务系统中,业务系统划分多个子领域,子领域也可以继续细分,如电商行业,订单领域与商品领域,订单表需要映射到订单索引,也需要与商品索引映射。

多数据表 ->多索引

image.png

1)多对多映射关系,多个数据表映射到多个索引,复杂度高;
2)一个中型以上的业务系统,会划分成多个领域,单领域会持续细分为多个子领域,领域之间会形成网状关系,业务数据相互关联;
3)数据库表关联查询效率低,跨库查询能力局限,需要借助 Elasticsearch 合并;
4)按照领域需求不同,合并为不同的索引文件,各索引应用会有差异,部分是通用型的,面向多个领域公用;部分是特殊型的,面向单个领域专用。

多源数据表 ->多索引

image.png

1)多源多表,多对多映射关系,数据表与索引之间的映射关系是交叉型的,复杂度最高;
2)一个大中型业务系统,不同的业务场景会采用不同的数据存储系统;
3)关系型数据库多样化,如 A 项目采用 MySQL,B 项目采用 PostgreSQL,C 项目选用 SQLServer,业务系统通用型的查询几乎不能实现;
4)非关系型数据库多样化,如 A 项目采用键值类型的 Redis,B 项目选用文档型的 MongoDB,业务系统同样也不能实现通用型查询;
5)基于异构数据源通用查询的场景需求,同样需要借助 Elasticsearch 合并数据实现

结语

Elasticsearch 虽然早期定位是搜索引擎类产品,后期定位数据分析类产品,属于 NoSQL 阵营,且不支持严格事务隔离机制,但由于其先进的特性,在应用系统中也是可以大规模使用,能有效弥补了关系型数据库的不足。

本文主旨探讨了 DB 与 ES 混合的需求背景与应用场景,目的不是评选 DB 与 ES 谁更优劣,是要学会掌握 DB 与 ES 平衡,更加灵活的运用到应用系统中去, 满足不同的应用场景需求,解决业务需求问题才是评判的标准。

作者:李猛
来源:云栖社区
原文链接:developer.aliyun.com/article/76276...

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!