DB与ES混合之应用系统场景分析探讨

00mysql

名词解释web


db-engine 当前综合排名算法

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

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

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

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

01数据结构

背景需求架构


为何单一 DB 不能知足应用系统?
为何单一 ES 不能知足应用系统?
为何要使用 DB 结合 ES 混用的模式?oracle

而不是结合其它 NoSQL?好比 MongoDB?

下面从技术层面与业务层面分析探讨。

技术层面

DB 与 ES 的技术特性说明

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 各有优点劣势,不能等同取代。

业务层面

DB 与 ES 业务背景说明

业务领域复杂度    

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


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

业务查询复杂度    

分库分表解决了数据的存储问题,但须要作合并查询倒是个很麻烦的事,业务系统的查询条件通常是动态的,没法固定,更加不可能在分库分表时按照全部动态条件设计,这彷佛代价太大。通常会选择更强大的查询数据库,好比 Elasticsearch 就很是合适。


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

DB 与 ES 结合    

业务数据存储由关系型数据库负责,有强事务隔离机制,保障数据不丢失、不串乱、不覆盖,实时可靠。

业务数据查询由 Elasticsearch 负责,分库分表的数据合并同步到 ES 索引;跨领域库表数据合并到同步 ES 索引,这样就能够高效查询。

DB与ES结合问题    

DB 与 ES 结合的问题

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

02

混合场景


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

单数据表->单索引

单数据表映射到单一索引

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

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

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

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

单数据表->多索引

单数据表映射到多个索引

  • 一对多映射关系,单数据表映射到多个索引中;

  • 单数据表即做为 A索引的主体对象,一对一映射;

  • 单数据表也做为 B索引的子对象,嵌入到主体对象下面;

  • 基于微服务架构设计,在业务系统中,业务系统划分多个子领域,子领域也能够继续细分,如电商行业,订单领域与商品领域,订单表须要映射到订单索引,也须要与商品索引映射。

多数据表->单索引

多数据表映射到单一索引

  • 多对一映射关系,多个数据表映射到单一索引,索引能够采用宽表结构,也能够采用子对象映射方式;

  • 单业务领域,数据表设计时通常会遵循数据库范式(注:1,2,3,4),即便是反范式设计,也只会增长一点冗余,若是要多表联合查询,数据库表的关联效率很低,甚至是运行不起来,须要借助 Elasticsearch 合并多个数据表到一个索引中;

  • 跨业务领域的数据表要联合查询,也须要借助 Elasticsearch 整合。

多数据表->多索引

多数据表映射到多个索引

  • 多对多映射关系,多个数据表映射到多个索引,复杂度高;

  • 一个中型以上的业务系统,会划分红多个领域,单领域会持续细分为多个子领域,领域之间会造成网状关系,业务数据相互关联;

  • 数据库表关联查询效率低,跨库查询能力局限,须要借助 Elasticsearch 合并;

  • 按照领域需求不一样,合并为不一样的索引文件,各索引应用会有差别,部分是通用型的,面向多个领域公用;部分是特殊型的,面向单个领域专用。

多源数据表->多索引

多源数据表映射到多个索引

  • 多源多表,多对多映射关系,数据表与索引之间的映射关系是交叉型的,复杂度最高;

  • 一个大中型业务系统,不一样的业务场景会采用不一样的数据存储系统;

  • 关系型数据库多样化,如 A 项目采用 MySQL,B 项目采用 PostgreSQL,C 项目选用 SQLServer,业务系统通用型的查询几乎不能实现;

  • 非关系型数据库多样化,如 A 项目采用键值类型的 Redis,B 项目选用文档型的 MongoDB,业务系统一样也不能实现通用型查询;

  • 基于异构数据源通用查询的场景需求,一样须要借助 Elasticsearch 合并数据实现。

03

结语


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


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


正文完


做者:李猛

https://www.jianshu.com/u/19522b124f97

本文编辑:筷子




活动预告




2020 年的 Elastic 中文社区技术分享交流活动开始啦!只不过咱们是以在线的方式进行的,第一期的分享嘉宾是来自京东零售计算存储平台的两位架构师,他们带来的主题是关于如何在 Elasticsearch 之上实现存储与计算分离的实践,存储与计算分离是目前业界很是火的一个话题,要不要上车了解一下啊?


本次分享的嘉宾主持人为 Elastic 中文社区创始人 Medcl 和现就任于 Google 的工程师吴斌,宝宝们快去注册吧。


每期活动中,咱们会从经过百格活动网站报名并实时观看直播的社区用户中随机抽取 5 名幸运观众,每人赠送 1 本博文视点计算机书籍或者 1 份 Elastic 定制记念品。详细书单和 Elastic 记念品介绍在本页面下方哦~


嗨,互动起来吧!

喜欢这篇文章么?

欢迎留下你想说的,留言 100% 精选哦!

Elastic 社区公众号长期征稿,若是您有 Elastic  技术的相关文章,也欢迎投稿至本公众号,一块儿进步! 投稿请添加微信:medcl123



招聘信息

Job board

社区招聘栏目是一个新的尝试,帮助社区的小伙伴找到心仪的职位,也帮助企业找到所需的人才,为伯乐和千里马牵线搭桥。有招聘需求的企业和正在求职的社区小伙伴,能够联系微信 medcl123 提交招聘需求和发布我的简历信息。


Elastic中文社区公众号 (elastic-cn)

为您聚集 Elastic 社区的最新动态、精选干货文章、精华讨论、文档资料、翻译与版本发布等。

喜欢本篇内容就请给咱们点个[在看]吧

本文分享自微信公众号 - Elastic中文社区(elastic-cn)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。

相关文章
相关标签/搜索