mongo 手册阅读笔记

有一种叫做capped collection，类似于固定长度的队列，这个适合做大流量顺序读写，oplog就是用这个类型做的。他是一个FIFO队列，当队列满的时候会踢掉最老的记录。

倒序查询：db.cappedCollection.find().sort( { $natural: -1 } )

他的限制：不支持shard， 不能删除记录，

 

v3.2之后默认的引擎是WiredTiger

 

当mongod重启的时候，会检查checkpoint，如果发现和journal不一致，会讲journal的checkpoint之后的记录同步到datafile。

WiredTiger journal: 每一次客户端的写操作引起的内部一系列看写操作会被打包成一个记录，写入到in memory buffer，然后当下列条件之一成立，会flush到磁盘的journal文件

• New in version 3.2: Every 50 milliseconds.

• MongoDB sets checkpoints to occur in WiredTiger on user data at an interval of 60 seconds or when 2 GB of journal data has been written, whichever occurs first.

• If the write operation includes a write concern of j: true, WiredTiger forces a sync of the WiredTiger journal files.

• Because MongoDB uses a journal file size limit of 100 MB, WiredTiger creates a new journal file approximately every 100 MB of data. When WiredTiger creates a new journal file, WiredTiger syncs the previous journal file.

MMAPV1 journal：

内存有两个view： shared view映射的是data file， private view映射的是journal file

1. MongoDB first applies write operations to the private view.
2. MongoDB then applies the changes in the private view to the on-disk journal files in the journaldirectory roughly every 100 milliseconds. MongoDB records the write operations to the on-disk journal files in batches called group commits. Grouping the commits help minimize the performance impact of journaling since these commits must block all writers during the commit. Writes to the journal are atomic, ensuring the consistency of the on-disk journal files. For information on the frequency of the commit interval, see storage.journal.commitIntervalMs.
3. Upon a journal commit, MongoDB applies the changes from the journal to the shared view.
4. Finally, MongoDB applies the changes in the shared view to the data files. More precisely, at default intervals of 60 seconds, MongoDB asks the operating system to flush the shared view to the data files. The operating system may choose to flush the shared view to disk at a higher frequency than 60 seconds, particularly if the system is low on free memory. To change the interval for writing to the data files, use the storage.syncPeriodSecs setting.

 推荐使用XFS或者EXT4，WiredTiger强烈建议使用XFS

Recommended Configuration

For all MongoDB deployments:

• Use the Network Time Protocol (NTP) to synchronize time among your hosts. This is especially important in sharded clusters.

For the WiredTiger and MMAPv1 storage engines, consider the following recommendations:

• Turn off atime for the storage volume containing the database files.

• Set the file descriptor limit, -n, and the user process limit (ulimit), -u, above 20,000, according to the suggestions in the ulimit reference. A low ulimit will affect MongoDB when under heavy use and can produce errors and lead to failed connections to MongoDB processes and loss of service.

• Disable Transparent Huge Pages. MongoDB performs better with normal (4096 bytes) virtual memory pages. See Transparent Huge Pages Settings.

• Disable NUMA in your BIOS. If that is not possible, see MongoDB on NUMA Hardware.

• Problems have been reported when using MongoDB with SELinux enabled. To avoid issues, disable SELinux when possible.

  If you are using SELinux on Red Hat, you must configure SELinux to be able to run MongoDB. See:Configure SELinux for MongoDB and Configure SELinux for MongoDB Enterprise for the required configuration.

  NOTE

  If you are using SELinux, any MongoDB operation that requires server-side JavaScript will result in segfault errors. Disable Server-Side Execution of JavaScript describes how to disable execution of server-side JavaScript.

For the WiredTiger storage engine:

• Set the readahead setting to 0 or 16. Setting a higher readahead benefits sequential I/O operations. However, since MongoDB disk access patterns are generally random, setting a higher readahead provides limited benefit. As such, for most workloads, a readahead of 0 or 16 provides optimal MongoDB performance.

For the MMAPv1 storage engine:

• Ensure that readahead settings for the block devices that store the database files are appropriate. For random access use patterns, set low readahead values. A readahead of 32 (16 kB) often works well.

  For a standard block device, you can run sudo blockdev --report to get the readahead settings and sudo blockdev --setra <value> <device> to change the readahead settings. Refer to your specific operating system manual for more information.