01名词解释
DB：database，泛指关系型数据库，具有严格事务隔离机制的数据类库产品，如mysql、sqlserver、postgresql、oracle、db2等。db-engine综合排名前面的全部是关系型数据库。ES：elasticsearch，最好的开源搜索引擎产品，Nosql非关系型数据库，不具备严格事务隔离机制。当前db-engine综合排名第7。应用：本文泛指业务应用系统，是OLTP场景，非OLAP场景，大量运用事务型数据库产品的业务系统。索引：在关系型数据库中是指数据检索的算法，在Elasticsearch是指数据存储的虚拟空间概念，类同数据库中的表。02背景需求
为什么单一DB不能满足应用系统？为什么单一ES不能满足应用系统？为什么要使用DB结合ES混用的模式？而不是结合其他Nosql？比如Mongodb......下面从技术层面与业务层面分析探讨。技术层面db与elasticsearch的技术特性说明*DB局限性*关系型数据库索引基于**最左优先原则**，索引要按照查询需求顺序提前创建，不具备任意字段组合索引能力比如某xxx表有30个字段，若要求依据任意字段组合条件查询，此时关系型数据库显然无法满足这种灵活需求，包括当下很受欢迎的Nosql明星产品Mongodb也不能满足。*关系型数据库支持有限度的关联查询，一般在业务应用系统中，关联表会控制在2～3个表（**个人观点**：有3个表关联的业务场景需要由技术架构师评估是否容许，开发工程师只容许2个表关联），且单表的数据量是要平衡考虑才可以，跨同构数据库源关联就更加不容许。那跨异构数据库源呢？不是不容许，实在是有心无力。*关系型数据库普遍采用B+树数据结构实现索引查询，面对超大数据量处理有天然的瓶颈，数据量超过百万千万级，复杂点的查询，性能下降很快，甚至无法运行。*关系型数据库虽然也支持主从同步，支持读写分离，但集群是一种松散式的架构，集群节点感知能力脆弱，不成体系，弹性扩展能力不行。*ES互补性*Elasticsearch基于Lucene核心库构建，以倒排索引算法为基础，集成多种高效算法。Elasticsearch默认为所有字段创建索引，任索引字段可组合使用，且查询效率相当高，相比关系型数据库索更加高效灵活。在业务系统中，有很多场景都需要这种任意字段组合查询的能力，简称**通用搜索**（跨越速运）。*Elasticsearch的数据模型采用的是FreeScheme模式，以Json主体，数据字段可以灵活添加，字段层级位置也可以灵活设置，关系数据库中需要多表关联查询，在Elasticsearch中可以通过反范式的关联能力，将多个业务表数据合并到一个索引中，采用对象嵌套的方式。*Elasticsearch天然分布式设计，副本与分片机制使得集群具备弹性扩展能力，可以应付超大的数据量查询，在单索引数据量十亿级也可以在亚秒内响应查询。*Elasticsearch的索引支持弹性搜索，可以指定一个索引搜索，也可以指定多个索引搜索，搜索结果由ES提供过滤合并，这就为业务系统提供了很灵活的操作空间，特别是在实时数据与历史数据方面，统一查询条件语法皆可执行。*Elasticsearch支持数据字段与索引字段分离，默认情况下，数据字段与索引字段是同时启用，实际在业务业务场景中，数据表中很多字段无需检索，只是为了存储数据，在查询时方便取回；很多检索字段也无需存储原始数据，只是检索过滤使用。*DB不等于ES*关系数据库定位全能型产品，强事务机制，数据写入性能一般，数据查询能力一般。*Elasticsearch定位查询分析型产品，弱事务机制，查询性能非常不错。*DB与ES各有优势劣势，不能等同取代业务层面db与elasticsearch业务背景说明*业务领域复杂度*在进入互联网/移动互联网/物联网之后，业务系统数据量的几何倍数增长，传统应当策略当然是采用分库分表机制，包括物理层面分库分表，逻辑层面分区等。非重要数据可以采用非关系型数据库存储，重要的业务数据一定是采用关系数据库存储，比如物流速运行业的客户订单数据，不容许有丢失出错。*面对复杂业务系统需求，当下最流行的解决方式是采用微服务架构模式，微服务不仅仅局限上层应用服务，更深层次的是底层数据服务（（微服务不在本次讨论之内），基于领域模型思维拆分分解。应用服务拆分成大大小小数个，可以几十个几百个，也可以更多，数据服务也拆分成大大小小数个。*业务查询复杂度*分库分表解决了数据的存储问题，但需要做合并查询却是个很麻烦的事，业务系统的查询条件一般是动态的，无法固定，更加不可能在分库分表时按照所有动态条件设计，这似乎代价太大。一般会选择更强大的查询数据库，比如Elasticsearch就非常合适*微服务架构模式解决了业务系统的单一耦合问题，但业务系统的查询复杂度确实提高不少，复杂点的应用服务执行一次查询，需要融合多个领域数据服务才能完成，特别是核心领域数据服务，几乎贯穿一个系统所有方面，比如物流速运行业订单领域。*DB与ES结合*业务数据存储由关系型数据库负责，有强事务隔离机制，保障数据不丢失、不串乱、不覆盖，实时可靠。*业务数据查询由Elasticsearch负责，分库分表的数据合并同步到ES索引；跨领域库表数据合并到同步ES索引，这样就可以高效查询。DB与ES结合问题db与elasticsearch结合的问题关于DB与Elasticsearch混合主要有以下两个问题：同步实时性数据一致性本文不探讨此问题，后续会有专题讲述如何解决。03混合场景
前面已经论证了关系型数据库与Elasticsearch混合使用的必要性，接下来是探讨混合场景下的业务场景数据模型映射。1.单数据表-单索引单数据表映射到单一索引*一对一映射关系，关系数据库有多少个表，Elasticsearch就有多少个索引*关系数据库提供原始数据源，Elasticsearch替代数据库成为查询引擎，替代列表查询场景*单数据表为水平分库分表设计，需要借助Elasticsearch合并查询。如图：电商行业订单场景，日均订单量超过百万千万级，后端业务系统有需求合并查询。*单数据表业务查询组合条件多，数据库索引查询能力局限，需要借助Elasticsearch全字段索引查询能力，主要替代列表查询场景。如：电商行业商品搜索场景，商品基础字段超过几十个，几乎全部都可以组合搜索2.单数据表-多索引单数据表映射到多个索引*一对多映射关系，单数据表映射到多个索引中*单数据表即作为**A索引**的主体对象，一对一映射，如*单数据表也作为**B索引**的子对象，嵌入到主体对象下面*基于微服务架构设计，在业务系统中，业务系统划分多个子领域，子领域也可以继续细分，如电商行业，订单领域与商品领域，订单表需要映射到订单索引，也需要与商品索引映射3.多数据表-单索引多数据表映射到单个索引*多对一映射关系，多个数据表映射到单一索引，索引可以采用款表结构，也可以采用子对象映射方式*单业务领域，数据表设计时一般会遵循数据库范式（注：1，2，3，4），即使是反范式设计，也只会增加一点冗余，如果要多表联合查询，数据库表的关联效率很低，甚至是运行不起来，需要借助Elasticsearch合并多个数据表到一个索引中。*跨业务领域的数据表要联合查询，也需要借助Elasticsearch整合。4.多数据表-多索引多数据表映射到多个索引*多对多映射关系，多个数据表映射到多个索引，复杂度高。*一个中型以上的业务系统，会划分成多个领域，单领域会持续细分为多个子领域，领域之间会形成网状关系，业务数据相互关联。*数据库表关联查询效率低，跨库查询能力局限，需要借助Elasticsearch合并；*按照领域需求不同，合并为不同的索引文件，各索引应用会有差异，部分是通用型的，面向多个领域公用；部分是特殊型的，面向单个领域专用。5.多源数据表-多索引多源数据表映射到多个索引*多源多表，多对多映射关系，数据表与索引之间的映射关系是交叉型的，复杂度最高。*一个大中型业务系统，不同的业务场景会采用不同的数据存储系统。*关系型数据库多样化，如A项目采用mysql，B项目采用postgresql，C项目选用sqlserver，业务系统通用型的查询几乎不能实现。*非关系型数据库多样化，如A项目采用键值类型的Redis，B项目选用文档型的mongodb，业务系统同样也不能实现通用型查询。*基于异构数据源通用查询的场景需求，同样需要借助Elasticsearch合并数据实现。04结语
经验总结*Elasticsearch虽然早期定位是搜索引擎类产品，后期定位数据分析类产品，属于Nosql阵营，且不支持严格事务隔离机制，但由于其先进的特性，在应用系统中也是可以大规模使用，能有效弥补了关系型数据库的不足。*本文主旨探讨了DB与ES混合的需求背景与应用场景，目的不是评选DB与ES谁更优劣，是要学会掌握DB与ES平衡，更加灵活的运用到应用系统中去，满足不同的应用场景需求，解决业务需求问题才是评判的标准。内容来源*内容来源在业务系统中大量运用DB与ES混合实战，得出的一些实战与思考，提供后来者借鉴参考，内容原创转载请注明。*本文-12-07Elastic-北京开发者大会已经分享，节选自『同步场景』重新整理编写，更多详细可以在Elasticsearch社区下载PPT*分享主题《CDC：DB到ES实时同步》关于我们*李猛(ynuosoft)，Elastic-stack产品深度用户，ES认证工程师，/年接触Elasticsearch，对Elastic-Stack开发、架构、运维等方面有深入体验，实践过多种Elasticsearch项目，最暴力的大数据分析应用，最复杂的业务系统应用；业余为企业提供Elastic-stack咨询培训以及调优实施。*深圳星图智能星图智能是Elastic官方MSP技术合作伙伴