10亿级ES数据迁到MongoDB成本和性能实践

某智能产品业务数据之前存储在Elasticsearch(Es)中，磁盘占用约30T(按照单副本计算)，总数据量25亿，按照不同业务分类分别存在于不同表中。迁移前，业务存在较严重的性能及成本问题，当前业务已经迁移部分数据到MongoDB中，迁移后效果明显，成本实现十倍级节省，业务抖动问题也得以解决。当前我司已有数百亿Es数据迁移MongoDB，同时也有数百亿MongoDB迁移Es，根本原因业务就是选型错误引起。本文以该场景业务迁移作为案例，主要分享以下方面的内：MongoDB适用场景及不适用场景MongoDB和Es各自优势MongoDB和Es同样数据，真实磁盘消耗对比对从MongoDB迁移到ES后，我们减少了80%的服务器一文的一些不同看法没有万能的数据库，本文最后会总结MongoDB和Es各自的适用场景，以客观立场分析评价MongoDB和Es，拒绝“捧一个，踩一个”。拒绝“捧一个，踩一个”。Es绝对是一款优秀的搜索引擎，在模糊匹配、全文搜索、复杂检索等方面相比MongoDB拥有更大的优势。本文对应业务场景查询比较简单，查询更新等条件都是固定字段，不涉及复杂检索，所以在此场景MongoDB更具优势。另外，MongoDB当前默认的wiredtiger存储引擎，在高压缩、高性能、锁粒度等方面进一步提升了MongoDB在该场景下的优势。我司已有多个业务数百亿级数据从Es迁移MongoDB，由于其他业务迁移MongoDB的时间较早，之前没有详细记录迁移前后的ES和MongoDB详细资源对比，只有大概资源消耗比值。为了尽量客观评价迁移前后的数据对比，因此选择近期正在从Es迁移MongoDB的一个集群，同时记录源集群和目的集群的详细资源占用情况，这样的对比结果会更加客观真实。一、业务背景一、业务背景该业务存储智能产品相关数据，总数据量20多亿，单个集群ES磁盘消耗约30T。业务迁移背景如下（以下为业务开发同事整理)：Es集群不太稳定，造成秒级耗时，对我们业务影响挺大，感知非常明显；具体我们业务需求，主要是根据用户id来进行精确查询，没有复杂全文检索、模糊查询等需求，所以其实用不到Es的优点；Es成本太高。二、源Elasticsearch集群资源及部署情况二、源Elasticsearch集群资源及部署情况源ES集群业务在两个机房各申请了一个集群，由业务自己通过双写的方式来保障数据一致性，当一个集群异常业务自己切流量到另外一个集群。源ES集群部署架构及资源规格如下：1、源Elasticsearch集群部署架构1、源Elasticsearch集群部署架构如上图所示，由于为了实现两机房双活容灾及单集群抖动引起的业务故障，在A机房和B机房各搭建了一个ES集群，业务通过双写来自己维护两个集群的数据一致性。当A机房集群1异常，或者A机房掉电，则业务切流量到B机房备集群2，对应架构图如下：2、集群资源规格2、集群资源规格A机房集群1和B机房集群2内部部署架构完全已有，单个集群总共有26个节点，每个节点都部署在容器中，单个容器规格资源如下所示：单个容器规格资源如下所示：CPU：32内存：64G磁盘：2T磁盘类型：SSD单个集群总资源消耗如下：单个集群总资源消耗如下：CPU：32*26=832内存：64G*32=2048G磁盘：2T*32=64T两个集群总资源消耗如下：两个集群总资源消耗如下：CPU：32262=1664内存：64G322=4096G磁盘：2T322=128T3、源集群架构业务痛点3、源集群架构业务痛点从上面的分析可以看出，为了保障业务多活和集群高可用，业务通过双写实现，异常后业务自己判断切换，这增加了业务痛点。该架构主要痛点如下：成本高，本身每个集群都是多副本，第2个备集群进一步增加了成本；增加了业务开发难度，业务需要双写逻辑；数据一致性无法得到保障，例如集群1异常或者故障，业务读写切到集群2，当集群1恢复正常，异常这断时间内，集群2的数据会比集群1多；不利于业务快速迭代开发；业务只是按照固定字段做查询，查询条件单一，这种场景选择MongoDB本身性能会更好。三、目的MongoDB集群架构三、目的MongoDB集群架构业务开始迁移MongoDB的时候，通过和业务对接梳理，该集群规模及业务需求总结如下：总数据量20多亿；Es数据单集群磁盘消耗总和30.5T左右；读写峰值流量流量很小，几百上千；同城两机房多活容灾；1、MongoDB资源评估1、MongoDB资源评估分片数及存储节点套餐规格选定评估过程如下:内存评估内存评估我司都是容器化部署，以以网经验来看，MongoDB对内存消耗不高，历史百亿级以上MongoDB集群单个容器最大内存基本上都是64Gb，因此内存规格确定为64G。分片评估分片评估业务读写流量很低，但是数据量较大，因此分片数确定为2个分片。磁盘评估磁盘评估按照以往测试验证及线上真实数据迁移对比，同样的数据存入MongoDB和Es中真实磁盘消耗占比如下：MongoDB:Es 1：6MongoDB:Es 1：625亿Es真实磁盘消耗30.5T，预计MongoDB磁盘消耗5T左右，考虑到未来数据增长，我们按照50亿数据计算，预计需要10T空间。2个分片，因此每个分片5T数据，最终确定单个mongod实例容器磁盘规格5T。CPU规格评估CPU规格评估由于容器调度套餐化限制，因此CPU只能限定为16CPU(实际上用不了这么多CPU)。mongos代理及config server规格评估mongos代理及config server规格评估此外，由于分片集群还有mongos代理和config server复制集，因此还需要评估mongos代理和config server节点规格。由于config server只主要存储路由相关元数据，因此对磁盘、CUP、MEM消耗都很低；mongos代理只做路由转发只消耗CPU，因此对内存和磁盘消耗都不高。最终，为了最大化节省成本，我们决定让一个代理和一个config server复用同一个容器，容器规格如下：8CPU/8G内存/50G磁盘，一个代理和一个config server节点复用同一个容器。分片及存储节点规格总结：分片及存储节点规格总结：2分片/16CPU、64G内存、5T磁盘。mongos及config server规格总结mongos及config server规格总结：8CPU/8G内存/50G磁盘2、集群部署架构2、集群部署架构由于该业务所在城市只有两个机房，因此我们采用2+2+1(2mongod+2mongod+1arbiter模式)，在A机房部署2个mongod节点，B机房部署2个mongod节点，C机房部署一个最低规格的选举节点，如下图所示：说明：说明：每个机房代理部署2个mongos代理，保证业务访问代理高可用，任一代理挂掉，对应机房业务不受影响。如果机房A挂掉，则机房B和机房C剩余2mongod+1arbiter，则会在B机房mongod中从新选举一个主节点。arbiter选举节点不消耗资源客户端配置nearest，实现就近读，确保请求通过代理转发的时候，转发到最近网络时延节点，也就是同机房对应存储节点读取数据。弊端：弊端：如果是异地机房，B机房和C机房写存在跨机房写场景。如果A B C为同城机房，则没用该弊端，同城机房时延可以忽略。四、性能优化过程四、性能优化过程该集群优化过程按照如下两个步骤优化：数据迁移开始前的提前预优化、迁移过程中瓶颈分析及优化、迁移完成后性能优化。1、数据迁移开始前的提前预操作1、数据迁移开始前的提前预操作和业务沟通确定，业务每条数据都携带有唯一id（用户生成的，不是MongoDB内部生成），同时业务查询更新等都是根据id维度查询该设备下面的单条或者一批数据，因此片建选择_id。分片方式分片方式为了充分散列数据到2个分片，因此选择hash分片方式，这样数据可以最大化散列，同时可以满足同一个_id数据落到同一个分片，保证查询效率。预分片预分片MongoDB如果分片片建为hashed分片，则可以提前做预分片，这样就可以保证数据写进来的时候比较均衡的写入多个分片。预分片的好处可以规避非预分片情况下的chunk迁移问题，最大化提升写入性能。sh.shardCollection(user_xxx.user_xxx,_id:hashed,false,numInitialChunks:8192)注意事项：切记提前对ssoid创建hashed索引，否则对后续分片扩容有影响。就近读就近读客户端增加nearest 配置，从离自己最近的节点读，保证了读的性能。mongos代理配置A机房业务只配置A机房的代理，B机房业务只配置B机房代理，同时带上nearest配置，最大化的实现本机房就近读，同时避免客户端跨机房访问代理。禁用enableMajorityReadConcern禁用该功能后ReadConcern majority将会报错，ReadConcern majority功能注意是避免脏读，和业务沟通业务没该需求，因此可以直接关闭。MongoDB默认使能了enableMajorityReadConcern，该功能开启对性能有一定影响，参考：1、MongoDB readConcern 原理解析：https:/ server层、操作系统开销等，当数据迁移完后，业务写流量相比全量迁移过程小了很多。也就是说，前量迁移完成后，cache中涨数据比例几乎很少，基本上不会达到20%阀值，业务读流量相比之前多了很多(数据迁移过程中读流量走原Es集群)。为了提升读性能，因此做了如下性能调整(提前建好索引)：节点cacheSize从之前的42G调整到55G，尽量多的缓存热点数据到内存，供业务读，最大化提升读性能。每天凌晨低峰期做一次cache内存加速释放，避免OOM。五、迁移MongoDB后性能对比五、迁移MongoDB后性能对比当前已有2个表从Es迁移到该MongoDB集群，同时该业务新增了15亿其他业务数据到该集群，当前目的MongoDB集群已有近20亿数据。1、Es时延情况1、Es时延情况由于该集群ES没有历史时延统计曲线统计，因此ES的时延统计只有以下现象(来自业务方反馈)：查询秒级耗时，对我们业务影响挺大，感知非常明显。2、MongoDB集群时延曲线2、MongoDB集群时延曲线从上面的监控可以看出，由于除了迁移有源Es的数据，另外还有该业务的其他业务数据流量流向该集群，因此MongoDB集群流量相比Es会更高，MongoDB整体时延约1.5ms左右，远远好于之前Es的秒级时延抖动。六、迁移成本收益对比六、迁移成本收益对比1、ElasticSearch集群规格1、ElasticSearch集群规格原Es单个集群一共26个节点，每个节点副本容器规格：32CPU、64Gmem、2T磁盘，磁盘类型SSD，单个集群规格总结如下：单集群节点总数：26每个节点规格：32CPU、64Gmem、2T磁盘总数据量：25亿为了实现机房多活容灾和业务高可用，实际部署了两个Es集群，实际规格成本还的在上面的基础上增加一倍。2、MongoDB集群规格2、MongoDB集群规格当前该MongoDB集群已有约16亿数据(其中部分为Es集群以外数据，该集群除了存储部分Es迁移过来的数据，还存储该业务线其他业务数据)，该MongoDB集群规格如下：分片数：2单分片副本数：4每个节点规格：16CPU、64G mem、5T磁盘两个分片预计存储最大数据量：预计存储Es集群中总数据量的两倍。3、成本对比计算过程3、成本对比计算过程CPU、MEM内存成本对比计算过程CPU、MEM内存成本对比计算过程源Es两个集群和目的MongoDB集群资源对比如下：说明：说明：由于集群部署方式可能有很多冗余，上面的CPU和内存成本比对比实际上不客观，可能Es部署时候规格设置浪费。当然，MongoDB实际上CPU资源也非常空闲，所以CPU和内存指标对比无太大参考作用。磁盘成本对比计算过程(成本比约6：1)磁盘成本对比计算过程(成本比约