本文始发于知乎Elasticsearch专栏：从MySQL建立Elasticsearch索引-引言
日常工作里，因业务需要大量使用了Elasticsearch。为了简化索引的开发工作，我们需要一个易用可扩展的MySQL到ES的同步框架，在比较了可以找到的各种开源框架&工具后，我们还是选择自行研发了一个，名字简单粗暴：es-common。
背景
16年我接手了并负责了部门所有业务的搜索系统，旧搜索系统是基于Lucene自研实现的一个搜索框架，包含了平表创建、全量索引、增量索引、搜索引擎四个部分基础功能的封装；另有一个管理系统，用于配置索引、字典等信息。框架的实现思路是通过建立平表，简化索引创建的过程。
接手该系统以后，各业务出现井喷式发展，各种需求铺天盖地，同时该系统的不稳定性也开始作妖，最早三个人的小团队每天都疲于奔命。解决现有问题的同时，也在查找更好的解决方案。于是Elasticsearch进入视野。
基于JSON的交互、分布式、数据与逻辑隔离、开箱即用、稳定等特性，使我们确定了向ES转型的计划。每个点都是现有系统没有解决的问题，具体的点就不吐槽了。
选择
我们的需求有：
- 支持全量、增量建立索引，以使数据变更较快体现
- 支持更新指定文档，以处理突发问题
- 索引有版本控制，以防止出现问题无法快速回滚
- 尽量减少代码开发，减少出错概率，更专注业务
- 简单的出错处理，失败检测等
- 支持插件化开发，提供额外数据
- 支持简单的规则，类似合并同主键数据
- 域名、AUTH不可见，以满足安全要求
- 支持非MySQL来源的数据，因为微服务的存在，不是所有数据都能从DB获取到
当时的调用结果已经找不到了，那么按照现在可以搜索到的框架和工具来重新做调研好了。简单搜索了一下MySQL到ES的同步框架或者工具，有以下几个：
这几个工具通过简单的配置，即可建立索引，但分析我们的需求，有以下需求无法满足：
- 需要提供DB的URL、User和Password等，我们公司由于安全的考虑，是无法拿到这些参数的；
- 有部分数据是通过微服务获取的，单纯的SQL是无法访问微服务的；
- 有的表数据量比较大，需要分片多JOB同时处理，JDBC在这点上操作比较麻烦；
- 增量是需要按照主键进行更新的，按照时间扫描对表压力比较大；
- 类似工具无法走常规发布，有一定的发布风险
基于以上原因，我们选择了自己研发了一个框架，用来满足我们的需求。下篇文章讲介绍es-common的实现思路。
