01序言
mongodb与elasticsearch热度排名本文内容涉及到Mongodb与Elasticsearch两大阵营，可能会引起口水之争，仅代表个人经验之谈，非阵营之说，主要围绕2个话题展开，如下：
为什么要从MongoDb迁移到Elasticsearch？如何从MongoDb迁移到Elasticsearch？
02现状背景
Mongodb本身定位与关系型数据库竞争，但工作中几乎没有见到哪个项目会将核心业务系统的数据放在上面，依然选择传统的关系型数据库。
项目背景
公司所在物流速运行业，业务系统复杂且庞大，用户操作者很多，每日有大量业务数据产生，同时业务数据会有很多次流转状态变化，为了便于记录追踪分析，系统操作日志记录项目应运而生，考虑到日均增加数据量，原有操作日志数据基于Mongodb存储。
操作日志记录系统需要记录两种数据，如下说明：
变更主数据，什么人在什么时间在系统哪个模块做了什么操作，数据编号是什么，操作跟踪编号是什么
变更从数据，实际变更数据的变化前后，此类数据条数很多，一行数据多个字段变更就记录多条
项目架构
项目架构描述如下：
1.业务系统新增或者编辑数据，产生操作日志记录发送到Kafka集群，基于dataid字段作为key
2.新增或编辑数据实际存储到mysql数据库
3.canal集群订阅Mysql集群，按照业务系统模块配置监控的数据库与表
4.canal将监控到的变更业务数据发送到kafka集群，基于dataid字段作为key
5.操作日志系统从kafka获取主记录数据与从记录数据
6.操作日志系统写入数据到Mongodb，同时需要反查询
操作日志记录业务流程说明Mongo架构
集群架构说明
服务器配置8c/32gb/gbssdRouter路由服务器部署了3个节点Config配置服务器部署了3个节点Shardnbsp;分片服务器部署了9个节点主操作记录设计3个分片从操作记录设计3个分片
mongodb集群架构图03问题说明
MongoDB的信徒们可能怀疑我们没有使用好，或者我们的运维能力欠缺。或者认为我们有Elasticsearch的高手在。不是这样的，弃用Mongodb选择Elasticsearch其实并非技术偏见问题，而是我们的实际场景需求，原因如下：
搜索查询
Mongodb内部采用B+Tree作为索引结构，此索引基于最左优先原则，且必须保证查询顺序与索引字段的顺序一致才有效，这个即是优点，但在现在复杂业务场景也是致命的业务系统查询操作日志记录会有很多过滤条件，且查询条件是任意组合的，现有mongodb是不支持的，或者说所有关系型数据库都不支持，如果要支持，得创建好多组合的B+数索引，想法很不理智，这个我们已经在[《DB与ES混合之应用系统场景分析探讨》](