MongoDB Authentication slow my TPS?

前言

故事发生在上一篇 《MongoDB Validator 是否会因性能影响而成为摆设？》, 当我把这篇文章给TJ过目后，TJ直接给我建议了下一篇文章的题目“开启权限认证对性能产生的影响”。原因是自从上次MongoDB比特币勒索事件后，很多人一下意识到对数据库加密的必要，但是同时又担心开启鉴权会影响到MongoDB的性能和吞吐。所以借着上次文档校验测试之积累，这里给大家再来做一次鉴权方面的性能测试。

好了，这只是一个插曲，

接着来简单介绍下官方的Security。

官方的Security 是分好几种的，在这里，我们对使用最广泛的 SCRAM-SHA-1 进行验证。

先来看看官方对 SCRAM-SHA-1 算法的赞美吧：
– A tunable work factor (iterationCount),
– Per-user random salts rather than server-wide salts,
– A cryptographically stronger hash function (SHA-1 rather than MD5), and
– Authentication of the server to the client as well as the client to the server.

从3.0后，SCRAM-SHA-1 已成为默认的加密算法。但是如果是从2.6升级到3.0版本的，MongoDB还是支持 MONGODB-CR 算法的，然而官方极力推荐升级算法。具体算法步骤本篇不做过多赘述，可移步官网 https://docs.mongodb.com/manual/release-notes/3.0-scram/ 。

在就着之前发生的暴露在公网的MongoDB未加密而被勒索的事件，安全是必须要做到的。

希望今天这篇文章能够帮助到那些担心有安全问题，但又更担心性能问题的小伙伴们~

调研

为了避免重复造轮子并做好万手准备，先做一番深入的调研，并验证自己对整个过程中可能发生的问题，是一个必须的过程。（再次感谢我的师傅 菠萝同学 教会了我这一点。）

• 开启无权限认证
  
• 添加认证用户
  
• 重启数据库，并开启权限认证
  
• 确认ycsb 可以通过带验证的 connection uri 连入mongodb
  

在最后附上了参考API，可供大家了解。

硬件信息

同 《MongoDB Validator 是否会因性能影响而成为摆设？》中的验证过程，这里就简单总结一下：

服务器

• Product Name: ProLiant DL360 Gen9
• Storage: RAID10, SSD, 1600GB
• CPU*2: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, (8/8 cores; 16 threads)*2
• Memory: 64GB*2

数据库

• 单节点
• wiredTigerCacheSizeGB=16
• auth: enabled
• 其他全部默认

测试

load

r:0.95, i:0.05

r:0.5, u:0.5

r:0.7, u:0.2, i:0.1

r:0.1, u:0.2, i:0.7

r:0.1, i:0.9

所有压测报告，都会上传至github

https://github.com/MiracleYoung/mongodb_stressing_auth

结论

• 从以上压测报告，可以看出在开启权限认证的情况下，大并发的情况下对读的延迟影响基本可以忽略不计。
• 然而无论是从 load，还是从 r:0.1, i:0.9 的压测结果确实可以反映出，在大并发的情况下，开启认证对于写性能是有一定得影响的。
• 之所以 load 和 r:0.1, i:0.9 的差异，在我翻看了代码后发现，load 是采用batch commit 的方式，而insert 则是 一条一条提交。因此会有对比差异。

就以上得出的个人结论后，我认为，这些性能的牺牲是可以忽略不计的。毕竟没有影响到 10倍乃至百倍的性能消耗。

数据库，始终是以安全为第一参考要素的！

参考

• https://github.com/brianfrankcooper/YCSB/tree/master/mongodb
• https://docs.mongodb.com/manual/reference/connection-string/
• http://api.mongodb.com/java/current/index.html?com/mongodb/MongoClientURI.html