MongoDB storage engine

It does affect

• How data is written to disk
• How data is deleted/removed from disk
• how data is read from disk
• Data structures used to store data

You can choice which Plug-in to use Actually

• MMAPv1
• WiredTiger

MMAPv1

https://docs.mongodb.com/manual/core/mmapv1/

MMAPv1 is MongoDB�s original storage engine based on memory mapped files. It excels at workloads with high volume inserts, reads, and in-place updates.

Maps data files directly into virtual memory

• Collection-level locking with MongoDB 3.0
• Database-level locking with MongoDB 2.2-2.6

Locks Shared resource

• Data
• Metadata
  • Indexes
  • Journal

Journal Write-ahead log allows to have consisntency of the data, in the event of the disk failure It is strongly recommend in production environment

Data on Disk is BSON Bits are mapped from disk to virtual memory

The document occupies 32kB up by 32kB until 2MB where it grows 2MB by 2MB until 16MB If the document is smaller, the block is padded. Having block of 32KB makes the storage more available to be re-used because it has standard size's gap.

Padding By default, MongoDB uses Power of 2 Sized Allocations so that every document in MongoDB is stored in a record which contains the document itself and extra space, or padding. Padding allows the document to grow as the result of updates while minimizing the likelihood of reallocations.

! The current storage engine default is wiredTiger, the course is for the 2.4 version

> db.serverStatus().storageEngine
{
    "name" : "wiredTiger",
    "supportsCommittedReads" : true,
    "readOnly" : false,
    "persistent" : true
}

MMapv1 Documents & DataFiles

mongod --storageEngine mmapv1 # it is not need because it is the default storage engine

WiredTiger

It is first storagePluggable in the version 3.0 Features

• Document level locking
• Compression
• Performance gains
• Lucks some pitfalls(insidie) of MMAPv1

It is used by other DB' Open Source

• It works at collection level and not at database level, it means
  ls $DBPATH collection-0-3561015462238979467.wt collection-0--8721906374104504950.wt collection-2-3561015462238979467.wt index-1-3561015462238979467.wt index-1--8721906374104504950.wt index-3-3561015462238979467.wt index-4-3561015462238979467.wt

WT Internals

• Stores data in btrees
• Writes are initially separate, incorporated later
• Two caches
  • 1 WT cache which is the half memory of the server by default
  • 2 File System cache

_WT Document level locking__ The right scales with the number of threads, try to know have more threads than your cores

WT Compression 3 compression options

• Snappy (Default) - fast
• \lib - more compression
• none

WT Options

WiredTiger options:
  --wiredTigerCacheSizeGB arg           maximum amount of memory to allocate
                    for cache; defaults to 1/2 of physical
                    RAM
  --wiredTigerStatisticsLogDelaySecs arg (=0)
                    seconds to wait between each write to a
                    statistics file in the dbpath; 0 means
                    do not log statistics
  --wiredTigerJournalCompressor arg (=snappy)
                    use a compressor for log records
                    [none|snappy|zlib]
  --wiredTigerDirectoryForIndexes       Put indexes and data in different
                    directories
  --wiredTigerCollectionBlockCompressor arg (=snappy)
                    block compression algorithm for
                    collection data [none|snappy|zlib]
  --wiredTigerIndexPrefixCompression arg (=1)
                    use prefix compression on row-store 

                    leaf pages