数据库中同步数据到elastic search的方案比较
本文转载自:https://juejin.im/post/6844904041672081421
#方案1,利用logstash定时向数据库读取数据然后写入到elastic search中
架构:数据库+logstash+elastic search
缺点:
1)因为是定时读取数据库,存在一定的时延
2)若同步时间间隔调的比较短,比如每秒定时同步一次数据,此时会增大业务数据库的压力
3)若一次同步的数据量比较大的话,网络传输成本会增大
相关链接:https://www.cnblogs.com/csts/p/6120644.html
为了解决时延的问题,采用同步双写方案,实时同步数据,于是引入方案2:
#方案2:同步双写,即在业务应用系统写数据到数据库时,同时插入一条数据到elastic search中
架构:业务应用+elastic search
缺点:硬编码,强业务耦合,性能差等
为了解决同步双写性能差的问题,那么引入mq来实现异步双写,于是引入方案3:
#方案3:异步双写,即引入mq并开发一个数据同步系统,在业务系统应用(生产者)中每做一笔交易,然后将数据发送到mq,数据同步系统(消费者)订阅mq消息,完成数据同步到elastic search中
架构:业务应用+mq+同步系统+elastic search
缺点:数据同步逻辑与业务应用系统强耦合在一起
相关链接:https://blog.csdn.net/lp2388163/article/details/80633190
为了解决数据同步逻辑与业务应用系统强耦合的问题,为了解耦且解决logstash定时同步时延的问题,于是引入阿里的canal来同步数据,引入方案3:
#方案4,利用canal订阅数据库的binlog日志文件,然后实时发送数据到elastic search中
架构:mysql+canal+elastic search
缺点:
1)若在高并发场景下,对canal服务器及客户端可能会造成性能压力
2)若canal同步binlog日志过程中,canal客户端宕机可能导致数据丢失
相关链接:https://www.jianshu.com/p/9677ca6ca34e
为了解决方案3中高并发的性能压力及canal客户端宕机数据丢失的问题,此时也引入mq,既做到限流削峰又起到数据缓存存储的作用
#方案5:利用canal订阅数据库的binlog日志文件,然后实时发送数据到mq中,然后利用数据同步系统订阅mq的消息完成数据同步到elastic search中
架构:mysql+canal+mq+数据同步系统+elastic search
缺点:增加了系统架构复杂性
相关链接:https://www.cnblogs.com/sanduzxcvbnm/p/11558858.html
PS:
1,由于canal的开源方案中只支持mysql,若要同步oracle数据,可以考虑oracle同步工具比如ogg,databus等
2,文中提及的mq有很多,比如active mq,rabbit mq,rocket mq,kafka等,根据不同的业务场景选择合适的mq。