SQL数据同步到ELK（一）- 日常开篇
需求
在我们的实际业务中，业务数据大部分是通过传统DB做持久化，但有时会使用Solr/Elastic Search等做搜索、缓存等其他服务，那么如何将数据同步到这些异构的存储系统中呢？
这就是我最近在学习的一个东西，要想让数据非常稳定、高效、低延时的同步，并非一件易事（对于我来说是这样，如果你有非常成熟的方案，请务必要推荐给我！！！）。
这个系列将会以SQL SEVER同步到ELK为例，尝试一下各种不同的方案，在写本篇时，还只是理论研究阶段，所以未来这篇文章如果写不下去了，希望大家谅解，毕竟SQL SERVER的方案实在太少了。
常见思路
一般来说，解决该问题的常见思路有以下几种（欢迎补充）：
- 利用数据库触发器，在需要监听的字段或表上创建触发器
- 使用数据库的一些特性，比如本篇想说的SQL Server CDC，或者MySQL的Bin Log等
- 在程序中修改DB数据的地方，同时修改搜索引擎中的数据
- 利用DB中的LastModifyTime之类的字段来追踪变更
但上述方案均有不同程度的优势和不足：
方案1：
优：简单，而且主流数据库都支持触发器，方案较为通用。
劣：触发器这三个字一说出来，就会想到性能差。没错，该方案虽然简单，但性能是个大问题，基本上DBA是不允许你在PRD搞触发器这种东西的。
方案2：
优：可靠性较高，而且大部分数据库有办法对数据变化进行排序，不需要额外处理顺序问题
劣：不同的数据库机制不一致，如果一套系统涉及多种存储方式，那就得考虑和研究多种变更监测方式，如果数据库不支持或支持的不好，这种方式也基本上就不太容易往下进行了。
而且这种方式有时候也会带来一些额外的DB开销，比如SQL SERVER的CDC可能会导致DB死锁和DB文件占用空间变大的问题。
方案3：
优：能轻松应对不同数据库和多份额外存储（存储到多种大数据、缓存等产品中），实时性较高，甚至可以牺牲性能来保证多种产品同时存储完成。
劣：需要对程序进行较大的实现方案调整，而且该方式会导致无法直接修改DB中的数据，会给运维带来一定的麻烦，除非有比较完善的运维工具来协助。
方案4：
优：方案非常简单，任何一种数据库都能支持，也能满足运维时直接对DB中数据的操作需求。
劣：需要依赖DB中的特定字段，可能会涉及到原有表结构的修改。在删除数据时无法通过这种方式获得数据的变更
现有方案情况
MySQL的数据库同步方案，有阿里巴巴开源的比较成熟的Canal（https://github.com/alibaba/canal），其他国内的大厂也有不少的开源产品。
BUT，SQL SERVER就尴尬了，除了微软的一些文档，其他的方案少之又少，更别说像阿里这样的大厂的方案了，所以本着尝试的态度，开了这样一篇博客，希望对后人研究有些帮助吧~
BUT，还是有一些通用的基于JDBC的产品，比如ELK系列中的L（LogStash）, SQL SERVER可以凑合的使用，接下来我将会做一些尝试，来同步SQL SERVER和ELK中的数据。
