Understanding of MongoDB's Wiredtiger Storage Engine

Today I saw the official document of MongoDB Wiredtiger Storage engine, said I Wiredtiger Storage engine understanding!

After the mongodb3.2 version, the Wiredtiger storage engine is the default storage engine.

Document level Concurrency

Wiredtiger writes use concurrency control at the document level, so multiple clients can be modified simultaneously with different document in one collection.

For as many read and write operations as possible, Wiredtiger uses the optimistic concurrency control (optimistic concurrency controls), which is equivalent to optimistic locking, Wiredtiger's global, single-minded lock, which exists only in database and Collections level, for example: Drop a collections, requires a database-level lock. When the storage engine conflicts between database and collection locks, one of them will cause a conflict between the databases and write mongdb to go back to the operation.

Snapshots and checkpoints

Wiredtiger uses multi-version concurrency control (MVCC). In the beginning of the operation, Wiredtiger provides a snapshot of the point in time for this transaction (snapshot), a snapshot that renders a set of views of the data in memory.

When written to a disk, Wiredtiger passes all data in the snapshot in the same way to the data file on disk. The durable data in the data file is used as a checkpoint (checkpoint), which ensures that data files are consistent with the data from the previous checkpoint, including the last checkpoint. Eg: checkpoints can be used as a point of recovery for data. The Wiredtiger of MongoDB configuration is to create a site that is at intervals of 60 seconds or 2 GB of log data.

During the writing of a new site, if the previous site is still valid, in this case, MongoDB can recover data from the previous valid checkpoint if MongoDB ends unexpectedly or encounters an error suddenly and starts again.

When the Wiredtiger metadata table is atomically updated to the description document of the new inspection site, the new site becomes available and stable, one but the new site becomes available, and Wiredtiger releases pages from the old inspection site.

Journal

Wiredtiger uses a write-ahead to process log, and checks the site to ensure the durability of the data.

Wiredtiger logs render all data changes between check sites, if MongoDB exits between inspection sites, it uses logs to re-update all modified data from the last checkpoint point, the frequency of information updates, and the frequency with which MongoDB writes log data to disk. Wiredtiger logs are compressed using a fast compression library if you want to specify a mixed compression operation or do not compress using storage.wiredTiger.engineConfig.journalCompressor

The minimum log record size for Wiredtiger is bytes. If a log record is less than or equal to bytes, Wiredtiger does not compress the log record.

Compression

in the in MongoDB, using Wiredtiger, MongoDB supports compression for all collection and index, and compression is used to reduce storage space using extra CPU expenditure. By default, Wiredtiger uses block-level compression, all collections are used for fast compression libraries, and all Indexes (index) are compressed using prefixes. When compressing collections, block-level compression with zlib is also available, to specify a rotating compression operation or not to compress, using Storage.wiredTiger.collectionConfig.blockCompressor , if you don't want to compress index, you can look at Storage.wiredTiger.indexConfig.prefixCompression

For most workloads, the default compression setting balances storage efficiency and processing requirements.

Memory use

　　MongoDB uses WIREDTIGER,MONGODB to take advantage of Wiredtiger's internal cache and file system cache.

After the Mongdb 3.4 version, the Wiredtiger internal cache will become larger: 50% memory minus 1GB or 256MG, through the file system cache, MongoDB automatically use all the free memory, these memory is not Wiredtiger Used by the cache or other processes. The data is compressed in the file system's cache. To adjust the Wiredtiger internal cache size can be seen Storage.wiredTiger.engineConfig.cacheSizeGB.

Remember, do not adjust the size of the Wiredtiger internal cache beyond the default values.

Understanding of MongoDB's Wiredtiger Storage Engine