江苏龙网

  1. 首页 > 资讯 > 科技 > >

「埃尔法哥哥」DB与ES混合应用之数据离线同步


序言
首先解释下 即时、实时与离线 概念定义 ， 最近碰到很多的认知误区 ， 需要纠正下 。
即时概念
当数据变更之后马上就可以查询变更 ， 内部采用事务隔离机制 ， 查询的数据必须阻塞直到数据更新完毕 ， 如单实例关系数据库数据发生变更后 ， 然后马上可查询到 。
实时概念
在数据同步场景中 ， 包括异构数据源和同构数据源之间 ， 泛指在可接受的很快时间范围内同步完成 ， 一般的认知是秒级左右 ， 也可以毫秒或者微秒 ， 依据业务需求与实现能力定义 。 如mysql主从同步也做不到即时性 ， 只能实时性 ， 业务系统如果做读写分离 ， 也仅限非即时数据
离线概念
相比实时定义 ， 离线没有很强的时间即时性要求 ， 一般强调数据的吞吐量 ， 一般常规定义分钟级、小时级、自然天 。 如大数据BI应用中 ， 数据同步要求普遍T+1 。

「埃尔法哥哥」DB与ES混合应用之数据离线同步
本文插图

即时、实时、离线时间要求
前一篇文章《DB与ES混合应用之数据实时同步》 ， 我们主要分享了实战项目中基于CDC机制构建的数据实时同步技术方案 ， 整体技术栈链路长 ， 中间环节多 ， 需要复杂的代码编程 ， 投入成本高 ， 不利于快速投入生产应用 。 实际在多数业务系统场景中 ， 离线同步需求占比最高 ， 下面这篇文章 ， 我们主要探讨DB到ES的数据离线同步问题 。
背景需求
DB到Elasticsearch离线同步的业务应用场景有很多 ， 相比实时同步业务应用场景 ， 更能体现选择Elasticsearch替代DB作为查询引擎的优越性 ， 以下介绍几个离线同步的业务场景 。
历史数据查询
在电商或者物流行业 ， 日均会产生很多订单数据 ， 未完成的订单数据实时性查询频率高 ， 需要做很多上下游的数据流转处理；相反已经完成的订单数据查询频率不高 ， 但是日积月累的历史订单数据会增加很快 ， 若系统架构设计将实时数据与历史数据合并一起等同对待 ， 那么运行一段时间数据系统会出现很多致命的性能问题 ， 如实时数据查询更新会变慢 ， 用户体验下降 ， 历史数据查询量大 ， 一次查询可能会将系统严重阻塞 。
常规的做法是将实时数据与历史数据分离设计 ， 实时数据查询频率高 ， 单次查询数据量小 ， 系统响应快；历史数据查询频率低 ， 单次查询的数据量多 ， 系统响应稍慢 ， 甚至可以接受慢一些 。
介于传统关系型数据库的局限性 ， 同样采用Elasticsearch应对此系统场景 ， 实时数据查询走Elastic实时集群 ， 历史数据走Elastic历史集群 ， 实时数据同步可以使用CDC机制 ， 历史数据同步得需要专用离线通道方法 。

「埃尔法哥哥」DB与ES混合应用之数据离线同步
本文插图

实时数据集群与历史数据集群
业务技术重构
随着公司业务调整与业务发展 ， 业务系统也需要相应持续的重构 ， 不仅业务模型要重构 ， 技术架构也需要重构 ， 由于人的原因或者技术发展的原因 ， 原有的数据库系统难以满足业务需求 ， 此时需要更换到更合适的数据库系统 。
如很多基于Mongodb存储的业务系统 ， 其实切换到Elasticsearch更加合适 ， 速度更快 ， 成本更低（后续案例在编辑...） ， 那么系统重构之后就需要将数据从Mongodb全量同步到Elasticsearch ， 这也属于离线同步场景 。
关系性数据库局限性就不用说了 ， 大名鼎鼎的Mongodb其实也有很多业务应用短板 ， 或者应用误区 ， 如很多基于Mongodb存储的业务系统 ， 其实切换到Elasticsearch更加合适 ， 速度更快 ， 成本更低 ， 切换成本也很低（详细见另一篇文章《为什么要从Mongodb迁移到Elastic》） ， 那么系统重构之后就需要将数据从Mongodb全量同步到Elasticsearch ， 这也属于离线同步场景 。


推荐阅读


上一篇：[驱动之家]下一代小米AI相机曝光：完全替代滤镜 8K视频成主流

下一篇：埃尔法哥哥：Python编程教程：面向对象之高级特性