SQL数据同步到ELK- 日常开篇

Posted 2022-04-27 baiyunchen

需求

在我们的实际业务中，业务数据大部分是通过传统DB做持久化，但有时会使用Solr/Elastic Search等做搜索、缓存等其他服务，那么如何将数据同步到这些异构的存储系统中呢？

这就是我最近在学习的一个东西，要想让数据非常稳定、高效、低延时的同步，并非一件易事（对于我来说是这样，如果你有非常成熟的方案，请务必要推荐给我！！！）。

这个系列将会以SQL SEVER同步到ELK为例，尝试一下各种不同的方案，在写本篇时，还只是理论研究阶段，所以未来这篇文章如果写不下去了，希望大家谅解，毕竟SQL SERVER的方案实在太少了。

常见思路

一般来说，解决该问题的常见思路有以下几种（欢迎补充）：

1. 利用数据库触发器，在需要监听的字段或表上创建触发器
2. 使用数据库的一些特性，比如本篇想说的SQL Server CDC，或者mysql的Bin Log等
3. 在程序中修改DB数据的地方，同时修改搜索引擎中的数据

但上述方案均有不同程度的优势和不足：

方案1：

优：简单，而且主流数据库都支持触发器，方案较为通用。

劣：触发器这三个字一说出来，就会想到性能差。没错，该方案虽然简单，但性能是个大问题，基本上DBA是不允许你在PRD搞触发器这种东西的。

方案2：

优：可靠性较高，而且大部分数据库有办法对数据变化进行排序，不需要额外处理顺序问题

劣：不同的数据库机制不一致，如果一套系统涉及多种存储方式，那就得考虑和研究多种变更监测方式，如果数据库不支持或支持的不好，这种方式也基本上就不太容易往下进行了。

而且这种方式有时候也会带来一些额外的DB开销，比如SQL SERVER的CDC可能会导致DB死锁和DB文件占用空间变大的问题。

方案3：

优：能轻松应对不同数据库和多份额外存储（存储到多种大数据、缓存等产品中），实时性较高，甚至可以牺牲性能来保证多种产品同时存储完成。

劣：需要对程序进行较大的实现方案调整，而且该方式会导致无法直接修改DB中的数据，会给运维带来一定的麻烦，除非有比较完善的运维工具来协助。

现有方案情况

MySQL的数据库同步方案，有阿里巴巴开源的比较成熟的Canal（https://github.com/alibaba/canal），其他国内的大厂也有不少的开源产品。

BUT，SQL SERVER就尴尬了，除了微软的一些文档，其他的方案少之又少，更别说像阿里这样的大厂的方案了，所以本着尝试的态度，开了这样一篇博客，希望对后人研究有些帮助吧~

BUT，还是有一些通用的基于JDBC的产品，比如ELK系列中的L（LogStash）, SQL SERVER可以凑合的使用，接下来我将会做一些尝试，来同步SQL SERVER和ELK中的数据。