MongoDB Shell
MongoDB Shell
Storage Engines
Changed in version 3.0: MongoDB includes support for two storage engines: MMAPv1, the storage engine available in previous versions of MongoDB, and WiredTiger. MongoDB uses the MMAPv1 engine by default.
The files in the dbPath directory must correspond to the configured storage engine. mongod will not start if dbPath contains data files created by a storage engine other than the one specified by --storageEngine.
Supported Platforms
MongoDB distributions are currently available for Mac OS X, Linux, Windows Server 2008 R2 64bit, Windows 7 (64 bit), Windows Vista, and Solaris. The MongoDB distribution for Solaris does not include support for the WiredTiger storage engine.
For a full list of the recommended operating systems for production deployments, see: Recommended Operating Systems for Production Deployments.
SEE ALSO
Platform Specific Considerations
Use the Latest Stable Packages
Be sure you have the latest stable release.
All releases are available on the Downloads page. The Downloads page is a good place to verify the current stable release, even if you are installing via a package manager.
Use 64-bit Builds
Always use 64-bit builds for production.
Although the 32-bit builds exist, they are unsuitable for production deployments. 32-bit builds also donot support the WiredTiger storage engine. For more information, see the 32-bit limitations page
Concurrency
MMAPv1
Changed in version 3.0: Beginning with MongoDB 3.0, MMAPv1 provides collection-level locking: All collections have a unique readers-writer lock that allows multiple clients to modify documents in different collections at the same time.
For MongoDB versions 2.2 through 2.6 series, each database has a readers-writer lock that allows concurrent read access to a database, but gives exclusive access to a single write operation per database. See the Concurrency page for more information. In earlier versions of MongoDB, all write operations contended for a single readers-writer lock for the entire mongod instance.
WiredTiger
WiredTiger supports concurrent access by readers and writers to the documents in a collection. Clients can read documents while write operations are in progress, and multiple threads can modify different documents in a collection at the same time.
SEE ALSO
Allocate Sufficient RAM and CPU
Data Consistency
Journaling
MongoDB uses write ahead logging to an on-disk journal. Journaling guarantees that MongoDB can quickly recover write operations that were not written to data files in cases where mongod terminated as a result of a crash or other serious failure.
Leave journaling enabled in order to ensure that mongod will be able to recover its data files and keep the data files in a valid state following a crash. See Journaling for more information.
Write Concern
Write concern describes the guarantee that MongoDB provides when reporting on the success of a write operation. The strength of the write concerns determine the level of guarantee. When inserts, updates and deletes have a weak write concern, write operations return quickly. In some failure cases, write operations issued with weak write concerns may not persist. With stronger write concerns, clients wait after sending a write operation for MongoDB to confirm the write operations.
MongoDB provides different levels of write concern to better address the specific needs of applications. Clients may adjust write concern to ensure that the most important operations persist successfully to an entire MongoDB deployment. For other less critical operations, clients can adjust the write concern to ensure faster performance rather than ensure persistence to the entire deployment.
See the Write Concern document for more information about choosing an appropriate write concern level for your deployment.
Networking
Use Trusted Networking Environments
Always run MongoDB in a trusted environment, with network rules that prevent access from all unknown machines, systems, and networks. As with any sensitive system that is dependent on network access, your MongoDB deployment should only be accessible to specific systems that require access, such as application servers, monitoring services, and other MongoDB components.
NOTE
By default, authorization is not enabled, and mongod assumes a trusted environment. Enableauthorization mode as needed. For more information on authentication mechanisms supported in MongoDB as well as authorization in MongoDB, see Authentication and Authorization.
For additional information and considerations on security, refer to the documents in the Security Section, specifically:
For Windows users, consider the Windows Server Technet Article on TCP Configuration when deploying MongoDB on Windows.
Disable HTTP Interfaces
MongoDB provides interfaces to check the status of the server and, optionally, run queries on it, over HTTP. In production environments, disable the HTTP interfaces.
Manage Connection Pool Sizes
To avoid overloading the connection resources of a single mongod or mongos instance, ensure that clients maintain reasonable connection pool sizes. Adjust the connection pool size to suit your use case, beginning at 110-115% of the typical number of concurrent database requests.
The connPoolStats command returns information regarding the number of open connections to the current database for mongos and mongod instances in sharded clusters.
See also Allocate Sufficient RAM and CPU.
Hardware Considerations
MongoDB is designed specifically with commodity hardware in mind and has few hardware requirements or limitations. MongoDB’s core components run on little-endian hardware, primarily x86/x86_64 processors. Client libraries (i.e. drivers) can run on big or little endian systems.
Allocate Sufficient RAM and CPU
MMAPv1
The MMAPv1 storage engine is not CPU bound due to its concurrency model. As such, increasing the number of cores can help but does not provide significant return.
Increasing the amount of RAM accessible to MongoDB may help reduce the frequency of page faults.
WiredTiger
The WiredTiger storage engine is CPU bound. Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of CPUs can impact performance:
- Throughput increases as the number of concurrent active operations increases up to the number of CPUs.
- Throughput decreases as the number of concurrent active operations exceeds the number of CPUs by some threshold amount.