MONGODB 存储文件碾压MYSQL 与 配置文件学习

故事的这样说起,我们的软件外包商,在软件开发中将一些文件存入了MYSQL 十几行的数据竟然占据了几十GB 的存储空间,数据库的内存是一直告急. 在我们DB发现这个问题的时候,已经有点晚了, 估计这时候有人说,哎你怎么不管,在早期,实际上各种原因可能DB 不能早期介入一些设计,或者根本没有精力来介入到这些设计当中,导致这样的问题.

那我不是标题党,后面我们出了一个解决方案,让外包商将文件存储移步到了MONGODB ,然后进行压测,在压测过程中,100G 存储空间最终压测将一台MONGODB 服务器压爆了, 压测的MONGODB 的硬件参数 4G 内存, 2核心,100G 磁盘, 做的复制集. 此前MYSQL 通过BLOB 字段来存储那些文件,40G 内存,4CORE CPU ,出现性能问题(当然,基本搞开发的应该知道 MYSQL 是不能存储文件的,但不知道怎么搞得)

具体开发怎么测试的

共四次

1 5线程 12G 文件

2 10线程 5G文件

3 20线程 10G 文件

4 40线程 37G文件

以4G 内存 搏 40G 内存,最终也没落下风的MONGODB 自然是优胜者.存储的数据每个document 1MB . 所以用碾压了这两个字来描述,也的确不过分.

说完那个标题党,然后的好好捋一捋 MONGODB 4.2 的配置文件和MONGODB 3.6 4.0之间的不同,看看新版本到底.

第一个感官 MMAPV1 的引擎算是完蛋了,4.2 是可以抛弃这个数据库引擎了

在systemLog 里面基本上 4.0 和 4.2 是没有变化的

systemlog中的 verbosity 日志的详细度的问题, 关于这个配置不建议设置的详细度太高,因为在下面的 component 可以针对详细的项目来进行日志信息的输出,MONOGDB 的 verbosity 整体调整的细度太高的情况下,会造成日志量巨大的问题.

quiet 这个部分在生产上应该被关闭掉, 在生产上减少关键日志的输出,对于发现问题后的排查十分不利.

关于systemLog.timeStampFormant的格式来说,可以选择的有三种,这里可能比较容易被观察到的 iso

关于日志的详细度来说 mongodb 在日志的详细度方面的调整也是比较详细的.

其中包含的内容

accessControl

command

control

ftdc

geo

index

network

query

replication.heartbeats

replication.rollback

sharding

storage

storage.journal

storage.recovery

transaction

write

等多项信息,对于关心的信息可以添加更详细的记录信息,例如对于地理信息的 geo 方面需要进行更详细的记录, network 对于网络不稳定的,query, 对于查询信息中的一些问题和细节进行相关信息的记录,index ,replication.heartbeats storage write 对于每个系统特定关注的信息进行记录.

Storage 存储,存储的变化中4.0 和 4.2 之间是有变化的

明显的一点是4.2中的配置文件已经没有了mmapv1数据库引擎,剩下的就是wiredtiger

storage:
   dbPath: <string>
   indexBuildRetry: <boolean>
   journal:
      enabled: <boolean>
      commitIntervalMs: <num>
   directoryPerDB: <boolean>
   syncPeriodSecs: <int>
   engine: <string>
   wiredTiger:
      engineConfig:
         cacheSizeGB: <number>
         journalCompressor: <string>
         directoryForIndexes: <boolean>
         maxCacheOverflowFileSizeGB: <number>
      collectionConfig:
         blockCompressor: <string>
      indexConfig:
         prefixCompression: <boolean>
   inMemory:
      engineConfig:
         inMemorySizeGB: <number>

从MONGODB 4.0 开始 indexBuildRetry 不能在复制集中出现,所以从4.0开始indexBuildRetry 将不在被支持.

commitIntervalMs, 这个参数默认是100ms , 实际上如果需要更高的系统的性能,可以设置不超过500ms的参数提供数据与磁盘交互的性能.具体调整需要根据

syncPeriodSecs 默认值60 这个参数主要是设置MONGODB 的数据刷入到磁盘的时间，官方强调不要设置，但如果你将值设置为0 系统将不会同步内存的数据和磁盘数据，并且journaling日志会将磁盘空间快速消耗。

如果想关注内存的数据到磁盘的数据的状态，通过serverStatus 命令中关于 backgroudFlushing 位置，有相关信息。

wiredTiger 中的engineConfig 中的cacheSizeGB 中的设置的内存中关于，到底wiredTiger 使用了多少内存的问题，按照官方的计算模式

你的总内存 -1 * 0.5

如你有16G 内存 （16-1） * 0.5 这就是wiredTiger 默认情况下得到的内存。

通过下面的命令

db.serverStatus().wiredTiger.cache 我们可以了解到wiredTiger 是怎么利用cache的

关于MONGODB 4.2中关于 storage.wiredTiger.engineConfig.journalCompressor 中关于压缩的方式不光有我们熟悉的zlib 压缩模式或者 snappy ，现在新版本的MONGODB 提供了关于journal压缩的 zstd 模式，这个压缩的方式比 zlib 压缩的方式要更节省CPU资源，这点做得要比其他数据库在压缩方面具有优势。

storage.wiredTiger.engineConfig.maxCacheOverFlowFileSizeGB

这个设置是在 4.21开始的值，这里不建议设置，默认值0 ，当需要的内存超过原有的设置也不会有边际。

storage.wiredTiger.collectionConfig.blockCompressor

这个设置是关于MONGODB 中每个collection的压缩的设置，MONGODB4.2中添加的配置，其中也可以选择 zstd这样的数据压缩方式。

其余的设置与MONGODB4.0 3.6 大同小异，再次强调MONGODB4.2已经不再支持 MMAPV1.