容器部署MongoDB与物理机部署MongoDB的性能比较分析

吴佳骅

（武汉城市职业学院 湖北·武汉 430064）

现在的项目开发早已不是平地起楼式的了。虚拟机、运行时、编译器、中间件、开发框架、数据库以及其他各种要配置的环境，在项目开发之前，以上这些都得先准备好，否则大概率影响实际开发任务完成进度。然而，这种由各种杂七杂八的东西形成的庞杂集合体，本身在部署时就很让人费神，稍有不慎，可能就会导致环境错误，在部署中发生人为错误的概率不低。当项目中发生新应用的加入时，也时常需要添加其他环境组件。这些原项目来说，有时就像是入侵的细菌，可能导致项目崩溃。于是，解决这些附加组件带来的麻烦又成了不小的工作量。这些原本与开发任务本身关系不大的工作，需要在项目的各个阶段上重复执行，消耗大量的精力和耐性，对于要求速度的项目开发，显然很不划算。

于是，容器技术开始被应用在项目开发当中。这是一种能够把环境变量、应用、数据库等等打包在一个封闭的镜像当中的技术，当需要调用它们的时候，只需要根据镜像去生成具体的执行实例。不同的实例里可以包含不同的组件来提供服务，而实例与实例之间是彼此独立的。容器的出现使开发人员能用更灵活的方式去组织所需要的复杂环境。因为实例与实例之间彼此互不干涉，由不同组件代码或者执行库冲突和不兼容等问题所引起的各种错误也就很难出现了。开发人员可以将全部的精力集中在项目本身的开发业务上，整体的开发效率提高了。

不过，把组件装进笼子里的容器技术，是否真的是解决问题的银色子弹？与传统方式相比，在从杂乱环境部署的魔障里解救出开发人员的同时，作为代价是否又失去了什么，比如性能？为了解开这个疑问，用开发项目常用的NoSQL数据库MongoDB做代表，测试比较物理机部署和容器部署的性能表现。

1 关于MongoDB

MongoDB使用C++语言编写，是一种面向文件存储的分布式NoSQL数据库。MongoDB会把数据当作文档来存放，风格和JSON很像，数据结构是键值对，值又可以再包含别的文档、列表或者文档的列表。整体使用风格都比较像关系数据库，操作也比较简单。

2 关于Docker

Docker在容器中最流行，它用Go语言编写，并用appche2.0许可证开源，英文意思是码头工人搬运的箱子。正如其名，Docker所提供的容器就像是一个一个的箱子，箱子里装着各种各样的东西，箱子与箱子直接又彼此独立，每个箱子同时又呈现类似的可以相互堆叠的规格，很容易组合。Docker由四个部分组成：客户端、守护进程、镜像和容器。Docker的运作方式是C/S模式。守护进程充当后台服务器，负责接受请求，并且处理它们。客户端则提供人机交互界面，让用户可以和守护进程进行交互活动。客户端和守护进程可以被部署在同一台主机上，开发用计算机大都如此；也可以分开来部署成远程模式，通过socket来完成通信。镜像是Docker由需要的环境变量、运行库和其他组件一起通过打包生成的模板，容器是镜像的实现，一份镜像可以实现无数相同的容器。

3 测试环境

为了测试结果更有参考价值，测试环境使用两套完全一样的硬件和操作系统。硬件：处理器intelcorei5-9400F，主频2.9GHz；硬盘SSD；内存16G DDR4。以上胜任一般开发用计算机，SSD可降低I/O对测试结果的影响。操作系统ubuntu16.04LTS，Docker版本17.03.1，MongoDB版本5.0.2。计算机A直接安装MongoDB，计算机B建立MongoDB的Docker镜像然后生成Docker容器。

4 测试方法

为了贴近平时的开发情景，本次测试分为两项：针对只读性能的测试和针对读写混合操作性能的测试。只读的性能测试设定为请求次数为25万次，数据量100万，表数30张，列数10列。读写混合操作的性能测试设定为请求次数25万次，数据量100万，表数1张，列数10列。

每种测试都设置4种并发线程：10线程、32线程、64线程、128线程。测试框架选择使用业内流行的sysbench-MongoDB。测试的数据全部在当次测试之前随机生成，避免数据库缓存对测试结果造成的影响。测试结果以获得的每秒钟完成事务数量为准，即TPS。

5 测试结果分析

5.1 只读性能测试结果分析

四轮只读性能测试的TPS结果如图1所示。

图1：只读性能TPS

从图1中不难看出，直接物理机安装MongoDB的计算机A与使用Docker部署MongoDB的计算机B在只读性能上还是有些差异的。10线程测试中，计算机A和B的实测TPS数据分别是400和399，基本持平。32线程测试中，计算机A和B的实测TPS数据分别是410和360，计算机B比A性能大约低12%。64线程测试中，计算机A和B的实测TPS数据分别是395和385，计算机B比A性能大约低3%。128线程测试中，计算机A和B的实测TPS数据分别是405和396，计算机B比A性能上大约低3%。两者的最大性能差发生在32线程测试中。

通过以上数据分析，可以认为使用Docker部署MongoDB的计算机B在只读性能上要稍逊于直接物理机安装MongoDB的计算机A，最大性能差距在中线程体现得较为明显，而在低线程和高线程并不会在性能上拉开较大的差距。

5.2 读写混合操作性能测试结果分析

四轮读写混合操作性能测试的TPS结果如图2所示。

图2：读写混合操作性能TPS

从图2中可以看出，二者在读写混合操作性能上同样存在差异。10线程测试中，计算机A和B的实测TPS数据分别是175和155，计算机B比A性能上大约低11%。32线程测试中，计算机A和B的实测TPS数据分别是200和167，计算机B比A性能上大约低16%。64线程测试中，计算机A和B的实测TPS数据分别是195和185，计算机B比A性能大约低5%。128线程测试中，计算机A和B的实测TPS数据分别是199和188，计算机B比A性能大约低1%。两者的最大性能差依旧发生在32线程测试中。

通过以上数据分析，可以认为使用Docker部署MongoDB的计算机B在读写混合操作性能上要明显逊于直接物理机安装MongoDB的计算机A，最大性能差发生在中线程，甚至高达15%以上，在低线程的性能差也在10%以上，在中高线程和高线程两者勉强保持5%以内的性能差距。

同时，对比图1和图2的结果，不难看出，两者的性能差距在读写混合操作时明显大于只读时。

6 结论

通过在相同硬件条件下对只读和读写混合操作这两种性能共8轮测试的结果分析，不难看出将MongoDB部署在Docker中虽然并不能在性能上完全与传统的物理机部署持平，但是损失的性能代价并不算太大，在低线程和高线程情况下这种性能差距是可以勉强接受，而在开发过程中最常涉及到中线程的情况下性能差距较大甚至超过10%。

所以，对于完全解决开发流程各个阶段上复杂烦琐的环境部署以保障整个流程里的环境一致这一问题，Docker并非银色子弹。在性能和便利的天平上，还是得依靠开发团队去针对实际的需求做出增减砝码的取舍。