對于ES，我并沒有在實際項目中應用（自己研究過，沒有實戰過）；我們項目使用的是MongoDB；由于項目的特殊性，我們研究了很多關于A->B的數據同步方案，包括DB2/Mysql到MongoDB，MongoDB到MongoDB等等。
MySQL數據同步到ES的方案把MySQL的數據實時同步到ES，這樣可以實現在ES中低延遲的檢索，有些公司的項目做了分庫，可以單獨搭建一套ES來放全量的數據（或全量數據的部分字段，達到全量檢索的效果），常用的數據同步實現方案有這些：
MySQL Binlog：MySQL的Binlog日志可以用于數據庫的主從復制、數據恢復，也可以將MySQL的數據同步給ES；這里需要注意，Binlog的日志模式只能使用ROW模式（另外兩種模式是STATEMENT和MIXED）；解析Binlog日志中的內容，執行ES Document API，這樣就可以將數據同步到ES中；
MySQL dump：如果是新建的項目，使用Binlog做數據同步是沒有問題的，但如果MySQL已經運行了一段時間，項目架構中后增加的ES，那么歷史數據的遷移就要額外處理了，因為Binlog可能已經被覆蓋了。這時候歷史數據的同步，可以使用mysqldump對現有數據導出，之后再使用Binlog的方式；
開源工具：前兩種方式都是在數據庫日志這個級別做文章，我們還可以使用一些開源工具，比如go-mysql-elasticsearch；它可以幫助我們完成第一次全量數據同步，后續增量數據同步的工作（底層也是解析Binlog日志）；又或者mypipe，它支持將Binlog日志內容解析后推送到Kafka，如果要寫入到ES中，還需要寫額外的代碼從Kafka中消費數據寫入ES。
我們項目中的實現方案上面提過，我們項目中是將關系型數據庫DB2/Mysql中的數據同步到MongoDB中，Mysql尚且還能使用Binlog日志，DB2想要把變化的數據實時通知出來，實現起來比較困難（寫程序部署到DB2服務器上，要和數據庫做關聯配置，當數據發生變化，程序發送MQ通知給外圍系統），先不說性能是否能保證，就是“自己寫一個通知程序部署到數據庫所在服務器上（有侵入）”，這一點至少在我們公司是無法做到的。
我們采用了一個非常low的方式來解決這個問題，就是Java程序掃描DB2表中的時間戳，讀取最近變化的數據，加工到MongoDB中；
雖然實現方案比較low，但是效果還不錯，因為我們在從關系型數據到MongoDB的數據同步過程中，可以自有地做數據加工；相當于按照一定的數據維度，比如按照客戶維度，把幾十張表做關聯，加工后行程一個document保存到MongoDB中；再對外提供服務的時候，查詢效率提升的很明顯，因為表關聯已經提前完成了（接口響應大多數時候都是毫秒級，超過50ms就算慢了）。
缺點也很明顯，數據從關系型數據庫到MongoDB的延遲很高，我們項目幾經優化，也需要20分鐘左右；所以一定要結合著業務場景考慮是否使用這種方案。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。