Mysql 数据同步到 ES 的技术方案选型和思考

本文探讨了ES的文本搜索和多维筛选能力,以及它在企业级数据操作中的优势。同时,对比了数据迁移同步的两种模型——堆积能力的订阅消费和低延迟的端对端直连。此外,强调了Redis作为内存缓存技术在互联网架构中的重要性和学习价值。
摘要由CSDN通过智能技术生成

ES 的几个显著特点,能有效补足 MySQL 在企业级数据操作场景的缺陷

文本搜索能力:ES 是基于倒排索引实现的搜索系统,配合多样的分词器,在文本模糊匹配搜索上表现得比较好,业务场景广泛。

多维筛选性能好:亿级规模数据使用宽表预构建(消除 join),配合全字段索引,使 ES 在多维筛选能力上具备压倒性优势,加上文本搜索能力,独此一家。

开源和商业并行:ES 开源生态非常活跃,具备大量的用户群体,同时其内后也有独立的商业公司支持,而这让用户根据自身特点有了更加多样、渐进的选择。

为什么是数据迁移同步方式?

稳定性好:迁移同步对主数据库的操作主要是进行数据和日志的顺序读取,同时并发小,对主数据库稳定性影响较小(较多的下游订阅可能在网络层面存在影响,一般用消息解决)。另外日志(Binlog/WAL/Redo 等)可重放特质,让下游丢数据的可能性大大减小(处理好幂等的情况下)

业务解耦:一般而言主数据库更多承载事务型操作,而下游数据系统承载运营等层面的业务。

业务侵入小:数据迁移同步对业务无侵入,双端对接标准数据库(源),可以便利地找到开源、商业、云等各个方向的成熟解决方案或产品。

业务适配性好:某些数据迁移同步产品能够嵌入业务逻辑,让下游获取到更加贴近业务的数据,从而让数据服务更加有效和便捷。

数据迁移同步模型选择

订阅消费

image.png

优点

堆积能力:由于引入了消息队列,所以整个链路是具备变更数据的堆积能力的。假设变更数据消费的比较慢,MySQL 本地较老的 binlog 文件由于磁盘空间的不足而被删除时,消息队列的数据依然存在,数据同步依然可以进行。

数据分发能力:引入消息队列后可以支持多方订阅。如果下游多个应用都依赖源端的变更数据,可以订阅同一份 topic 即可。

数据加工能力:由于变更数据是由下游消费者订阅,因此订阅后可以灵活的做一些数据加工。例如从外部调用微服务接口或者反查一些数据来做数据加工都是比较方便的。

缺点

运维成本相对较高:包含了较多的组件和应用,运维保障相对复杂。

稳定性风险较高:一环出问题会导致整个数据同步链路的稳定性收到影响。而且排查和定位问题也会比较困难。

端对端直连

image.png

优点

低延迟:端对端的直接同步,链路较短,延迟低

稳定性好:链路组件少,出问题概率较低,定位排查均比较容易。适合对数据精确性高的严苛场景。

功能拓展性强:对端写入消息系统,模拟订阅模式,可拓展性强

运维部署检点:链路组件少,部署运维更简单

数据迁移同步模型选择总结

如果没有众多的下游数据订阅,建议采用直连模式。数据同步链路往往置于在线业务中,随着业务规模以及重要性逐渐加大,链路稳定性更为重要些。

另外端到端模式只要支持对端数据源为消息中间件,可立即实现订阅模式,数据加工能力在某些数据迁移同步产品上可通过上传业务代码运行的方式解决。

数据架构在满足业务需求的同时,简洁和清晰能够让系统更加易于维护和排查,当遇到链路每天同步大量数据、偶尔丢几条需要排查,或同步链路卡住不同步等情况,端对端方式往往体现出相当大的优势。

MySQL 关联表在 ES 上的设计

关系型数据库中的表 join 关系在 ES 可以用几种数据类型来表达,包括 objected,nested,join 三种。

objected

object 类型可以存储嵌套结构。

优点:表示主 field 和 object 内部 field 之间的一对多关系,支持 doc 的 join 查询。由于所有查询时依赖的关联数据也都在一个文档内,避免了 ES 内部的 join,查询效率较高。

缺点:一对多关系只能保留一层,多于一层的会被打平,会丢失嵌套 field 内部的关联关系。

nested

nested 类型可以存储嵌套结构,表示一对多关系,是 object 类型的拓展。

优点

不会出现 object 的缺点,整个嵌套关系是完整维护的,子文档内部关联关系保存是完整的

关联数据通过实现上自然关联到主文档上,搜索时性能较好(相对于 join)

缺点

一个 nested field 只能属于一个主文档

在 nested 类型中,子文档和主文档之间强绑定,主文档更新的时候会强制更新子文档。在写多读少的场景,新能开销较大。

child 文档的查询必须通过父文档再找到子文档

子文档频繁修改的话会影响别的子文档和父文档,因为本质上在 lucene 实现上是父文档下的冗余存档

join

join 类型可以配置父子文档,通过父子文档来实现一对多的能力,一个索引只能建一个。相比 nested 类型,该类型更加灵活。父子文档之间通过 parentId 来关联,实际实现上他们就是独立的文档。

优点

子文档更新不影响父文档和其他子文档

一个子文档可以单独搜索

一个文档在作为子文档时可以自己选择属于哪个父文档。通过 relation 可以指定不同的 join 列

缺点

需要建个全局序数,用于服务于父子文档的关联关系,这个会影响搜索性能

join 和 nested 类型比较

join 适合写多读少场景,更加适合关注索引性能的场景。这意味着更新的生效会更快,但是搜索时的开销也相对大些

nested 适合读多写少的场景,更加关注搜索的性能

去规范化实现

下面将介绍几种数据同步去规范化的几种方式:

主表冗余数据

业务侧将一些查询时需要的关系数据提前冗余在源表的一个字段中。

image.png

优点:处理模式能应对各种一对多的关联关系,对数据同步工具的功能要求低,配置简单,只需要支持单同步到 ES 即可。

缺点

索引、搜索性能非最佳:提供给 ES 的不是构建好的宽表数据。这种实现方式会有索引、搜索性能方面的额外开销,不是性能最佳的实现方式。

业务系统入侵:业务系统写主数据的时候需要额外写入信息。

主数据库表冗余过多数据:关系型数据库表冗余了过多其他表的信息,可能存在存储和性能开销。
先自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助,可以扫码领取!

img

完结

Redis基于内存,常用作于缓存的一种技术,并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中,使用最广泛的缓存,在工作中常常会使用到。Redis也是中高级后端工程师技术面试中,面试官最喜欢问的问题之一,因此作为Java开发者,Redis是我们必须要掌握的。

Redis 是 NoSQL 数据库领域的佼佼者,如果你需要了解 Redis 是如何实现高并发、海量数据存储的,那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。

dis基于内存,常用作于缓存的一种技术,并且Redis存储的方式是以key-value的形式。Redis是如今互联网技术架构中,使用最广泛的缓存,在工作中常常会使用到。Redis也是中高级后端工程师技术面试中,面试官最喜欢问的问题之一,因此作为Java开发者,Redis是我们必须要掌握的。

Redis 是 NoSQL 数据库领域的佼佼者,如果你需要了解 Redis 是如何实现高并发、海量数据存储的,那么这份腾讯专家手敲《Redis源码日志笔记》将会是你的最佳选择。

[外链图片转存中…(img-86oqz2CK-1711403331365)]

需要更多Java资料的小伙伴可以帮忙点赞+关注,点击传送门,即可免费领取!

  • 18
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值