All Products
Search
Document Center

ApsaraDB for MongoDB:MongoDB versions and storage engines

Last Updated:Mar 18, 2024

This topic describes the MongoDB versions and storage engines that are supported by ApsaraDB for MongoDB and the relationship between MongoDB versions and storage engines. This can help you select an instance that best suits your needs.

Supported MongoDB versions

The following MongoDB versions are supported by ApsaraDB for MongoDB.

Note

You can manually upgrade the MongoDB version while an instance is running. However, you cannot downgrade the MongoDB version. For more information, see Upgrade the major version of an ApsaraDB for MongoDB instance.

Storage engines

Storage engine

Scenario

Description

WiredTiger

It is the default storage engine and applicable to most business scenarios.

Data is in the B-tree structure. Compared with the earlier MMAPv1 storage engine, WiredTiger significantly improves performance and reduces storage costs while supporting data compression.

Relationship between MongoDB versions and storage engines

Storage engine

MongoDB 4.4 or later

MongoDB 4.2

MongoDB 4.0

MongoDB 3.4

WiredTiger

  • Replica set instances

  • Sharded cluster instances

  • Replica set instances

  • Sharded cluster instances

  • Standalone instances

  • Replica set instances

  • Sharded cluster instances

  • Standalone instances

  • Replica set instances

  • Sharded cluster instances

MongoDB 7.0

MongoDB 7.0 is bundled with features such as queryable encryption, shard metadata consistency check, sampled queries, shard key analysis, (analyzeShardKey), and AutoMerger. MongoDB 7.0 also optimizes sharding, time series collections, aggregation, and database security.

  • Queryable encryption

    In MongoDB 6.0, the queryable encryption feature is in preview. In MongoDB 7.0, this feature is generally available. For more information, see Queryable Encryption.

  • Shard metadata consistency check

    The checkMetadataConsistency command is added in MongoDB 7.0 to check metadata inconsistency across different shards. You can include this check item in daily O&M to identify potential inconsistency at the earliest opportunity. For more information, see checkMetadataConsistency.

  • Sampled queries and shard key analysis

    You can analyze whether the shard key of a collection is proper based on the results of sampled queries. This can help you efficiently design the schema and shard key for the collection and make more informed decisions on using a sharding architecture. For more information, see analyShardKey and configureQueryAnalyzer.

  • AutoMerger

    MongoDB 7.0 introduces a new feature called AutoMerger for the balancer. When data or indexes are unevenly distributed, excessive shards exist, or data is migrated, AutoMerger merges chunks to balance data distribution and improve database performance. By default, AutoMerger is enabled in MongoDB 7.0. You can also configure an active window for the balancer to enable AutoMerger.

  • Sharding

    • The rangeDeleterHighPriority parameter can be used to specify whether the deletion of orphan documents has a high priority. By default, this parameter is set to false, which indicates that MongoDB prioritizes business-related delete operations over the deletion of orphan documents.

    • MongoDB 7.0 removes the operationsBlockedByRefresh document that contains statistics about operations blocked by catalog cache refreshes. This is because the operationsBlockedByRefresh counters increase on mongos nodes for every operation that uses collection routing information, even if the operation is not blocked by a catalog refresh activity.

    • Monitoring metrics related to resharding are added.

    • The maxSize option is no longer supported for the addShard command.

    • When the chunk size of the config.settings collection is adjusted, a validity check is performed to ensure that the new value falls within a reasonable range of 1 to 1,024.

    • Starting in MongoDB 6.0.3, several adjustments are made to the balancer policy.

      • The balancer evenly distributes data based on the difference in data volume rather than the number of chunks between shards.

      • Partitioning is performed by range instead of by chunk.

      • Automatic splitting takes effect only when data is migrated across shards.

  • Time series collections

    • The restrictions imposed in earlier versions on the use of the DELETE command for time series collections are removed. The only restriction on the current DELETE command is that the command cannot be used in a multi-document transaction.

    • Time series collections are supported for the COMPACT command.

  • Aggregation

    The following operators are added in MongoDB 7.0 to perform bit calculations and support percentiles.

    Operator

    Description

    $bitAnd

    Returns the result of the bitwise AND operation on a numeric value of the INT or LONG type.

    $bitNot

    Returns the result of the bitwise inverse operation on a numeric value of the INT or LONG type.

    $bitOr

    Returns the result of the bitwise OR operation on a numeric value of the INT or LONG type.

    $bitXor

    Returns the result of a bitwise XOR operation on a numeric value of the INT or LONG type.

    $median

    Returns the approximate median, which is equivalent to the 50th percentile.

    $percentile

    Returns the specified percentile.

  • Security

    • Key Management Interoperability Protocol (KMIP) V1.0 and V1.1 are supported.

    • OpenSSL 3.0 and OpenSSL FIPS are supported.

  • Others

    • Fields such as catalogCacheIndexLookupDurationMillis are added to slow query logs. For more information, see Logging Slow Operations.

    • The transaction concurrency of the storage engine can be dynamically adjusted. The default concurrency before adjustment is 128. Starting in MongoDB 7.0, the transaction concurrency is automatically adjusted. For more information, see Concurrent Storage Engine Transactions (Read and Write Tickets).

    • Fields related to query sampling are added to the currentOp command. For more information, see currentOp Metrics.

    • Composite wildcard indexes are supported. For more information, see Compound Wildcard Indexes.

    • The $changeStreamSplitLargeEvent operator is added to allow you to split large change events that exceed 16 MB in size. For more information, see Large Change Stream Events.

    • The performance of the slot-based query execution engine is optimized.

    • Metrics related to chunk migrations are added. For more information, see New Sharding Statistics for Chunk Migrations.

    • The USER_ROLES system variable can be used to obtain the role of the current user.

    • Global parameters related to analyzeShardKey, balancer, and queryAnalyzers are added.

    • More fields are added to the results returned for serverStatus. For more information, see serverStatus Output Change.

MongoDB 6.0

MongoDB 6.0 is bundled with features such as queryable encryption and Cluster-to-Cluster Sync. MongoDB 6.0 also optimizes time series collections, change streams, aggregation, queries, elasticity, and database security.

  • Queryable encryption

    Queryable encryption allows you to encrypt sensitive data from the client side, store the data as fully randomized encrypted data on the database server side, and then run expressive queries on the encrypted data.

    Queryable encryption allows only the client to obtain the plaintext of sensitive data. After a query that contains an encryption key obtained from Key Management Service (KMS) is sent to the server, the server processes the query and returns a response in ciphertext. Then, the client decrypts the response by using the encryption key and displays the response in plaintext.

  • Cluster-to-Cluster Sync

    The mongosync tool is introduced in MongoDB 6.0 to support continuous and uni-directional data synchronization across ApsaraDB for MongoDB instances. The mongosync tool allows you to manage and monitor a synchronization task in real time. You can start, stop, resume, or reverse the synchronization task.

  • Time series collections

    Time series collections are enhanced in terms of indexing, query, and sorting.

    • Secondary and compound indexes can be used on time series collections to improve read performance.

    • Geospatial indexes can be added for time series data to support scenarios that involve distance and location.

      For example, you can track temperature changes in refrigerated trucks and monitor the fuel consumption of cargo ships on a specific route.

    • Last point queries on time series data are optimized. You no longer need to scan the entire collection to obtain the last data point.

    • Time series data can be sorted in a more efficient manner by using timestamps and creating clustered and secondary indexes on metadata fields.

  • Change streams

    MongoDB 6.0 provides the following new features and optimizations:

    • Pre-images can be viewed.

      Note

      Prior to MongoDB 6.0, only post-images can be viewed. Starting from MongoDB 6.0, pre-images can also be viewed. For more information about pre-images and post-images, see Change Streams with Document Pre- and Post-Images.

    • DDL statements such as create, createIndexes, modify, and shardCollection are supported. For more information, see Change Events.

    • The wallTime field is added to change events. The timestamp used by the field supports multiple conversion operators such as $toDate, $tsSeconds, and tsIncrement to facilitate consumption.

  • Aggregation

    MongoDB 6.0 provides the following new features and optimizations:

    • $lookup and $graphLookup are supported by sharded cluster instances.

    • The support of $lookup for joins is improved.

    • The support of $graphLookup for graph traversal is supported.

    • A maximum of a hundredfold improvement in the performance of $lookup is archived.

    Note

    For more information about $lookup and $graphLookup, see $lookup (aggregation) and $graphLookup (aggregation).

  • Queries

    Operators such as $maxN, $topN, $minN, $bottomN, $lastN, and $sortArray are added. Operators allow you to use databases for computing to reduce the burden on business applications.

    Note

    For more information about the operators, see Aggregation Pipeline Operators.

  • Elasticity

    MongoDB 6.0 provides the following new features and optimizations:

    • The default size of a data chunk is updated from 64 MB to 128 MB. This reduces data migration frequency and decreases networking and routing overheads.

    • The configureCollectionBalancing command is supported. The command supports the following features:

      • Supports different chunk sizes for different sharded tables.

        For example, you can set the chunk size to 256 MB for ultra-large sharded tables and set the chunk size to 64 MB or 32 MB for small sharded tables that require even data distribution.

      • Supports active collection defragmentation.

        Compared with the compact command, the configureCollectionBalancing command optimizes defragmentation services to reduce disk space usage.

      Note

      For more information about the configureCollectionBalancing command, see configureCollectionBalancing.

    • Security

      MongoDB 6.0 optimizes the Client-Side Field Level Encryption (CSFLE) feature. After the optimization, the CSFLE feature is available for Key Management Interoperability Protocol (KMIP)-compliant key providers. In other words, in addition to local Keyfile-based key management services, MongoDB also supports third-party key management devices by using KMIP. This provides enhanced security.

      Note

      The CSFLE feature has been widely used in the management of sensitive data, especially in data migration scenarios.

MongoDB 5.0

MongoDB 5.0 marks a new release cycle to deliver new features faster than in the past.

  • Native time series platform

    MongoDB 5.0 natively supports the entire lifecycle of time series data that ranges from ingestion, storage, query, real-time analysis, and visualization to online archival or automatic expiration as data ages. This streamlines the building and running of time series applications and lowers costs. In V5.0, MongoDB has expanded the universal application data platform to make it easier for developers to process time series data. This further extends the application scenarios of the platform to areas such as IoT, financial analysis, and logistics.

  • Live resharding

    You can change the shard key for your collection on demand as your workload grows or evolves. No database downtime or complex migration within the dataset is required in this process. You can run the reshardCollection command in the MongoDB Shell to select the database and collection that you want to reshard and specify the new shard key.

    reshardCollection: "<database>.<collection>", key: <shardkey>
    Note
    • <database>: the name of the database that you want to reshard.

    • <collection>: the name of the collection that you want to reshard.

    • <shardkey>: the name of the shard key.

    • When you run the reshardCollection command on MongoDB, it clones an existing collection and then applies all oplogs in the existing collection to a new collection. After applying all oplogs, MongoDB switches to the new collection and deletes the existing collection.

  • Versioned API

    The Versioned API feature allows you to add new features to the database of each version with full backward compatibility. When you change an API, you can run a new version of the API on the same server at the same time as the existing version of the API. As new MongoDB versions are released at a faster pace, the Versioned API feature provides easier access to the features of the latest versions.

    The Versioned API feature defines a set of commands and parameters that are most commonly used in applications. These commands remain unchanged for all database releases, including annual major releases and quarterly rapid releases. As a result, the application lifecycle is decoupled from the database lifecycle, which allows you to pin the driver to a specific version of the MongoDB API. This way, even after your database is upgraded, your application can continue to run for several years without the need to modify any code.

  • Default majority write concern.

    Starting from MongoDB 5.0, the default level of write concern is majority. A write operation is committed, and write success response is passed back to the application only when the write operation is applied to the primary node and persisted to the logs of a majority of secondary nodes. This ensures that MongoDB 5.0 provides stronger data durability guarantees out of the box.

  • Long-running snapshot queries

    Long-running snapshot queries improve the versatility and flexibility of applications. You can use this function to run a query with a default time of 5 minutes or adjust the execution duration of a query. In addition, this feature maintains consistent snapshot isolation with real-time transactional databases, and allows you to run snapshot queries on secondary nodes. This allows you to run different workloads in a single cluster and scale your workloads to different shards.

  • New MongoDB Shell

    For better user experience, the MongoDB Shell has been redesigned from the ground up to provide a modern command-line experience, enhanced usability features, and a powerful scripting environment. The new MongoDB Shell has become the default shell for MongoDB. The new MongoDB Shell introduces syntax highlighting, intelligent auto-complete, contextual help, and useful error messages to create a visualized and interactive experience.

  • Version release adjustment

    Starting from MongoDB 5.0, MongoDB is released as two different release series: Rapid Releases and Major Releases. Rapid Releases are available for evaluation and development purposes. We recommend that you do not use Rapid Releases in the production environment.

MongoDB 4.4

MongoDB 4.4 overcomes the most obvious problems with previous versions.

  • Hidden Indexes

    Existing indexes are hidden to ensure that these indexes will not be used in subsequent queries. You can check whether the deletion of a specified inefficient index compromises performance. If not, you can delete the inefficient index.

  • Refinable Shard Keys

    One or more suffix fields are added to improve the distribution of existing documents on chunks. This prevents the concurrent access to a single shard and decreases pressure on servers.

  • Compound Hashed Shard Keys

    A single hash field can be specified in a composite index to simplify the business logic.

  • Hedged Reads

    For sharded cluster instances, a read request can be sent to two replicas of the same shard simultaneously. The results received first are used to recover the client. This reduces the request latency.

  • Streaming Replication

    The oplogs of the primary database are actively sent to secondary nodes. Compared with the previous version where the secondary nodes are polled, this method saves nearly half of the round-trip time and improves the performance of data replication between the primary and secondary nodes.

  • Simultaneous Indexing

    The indexing processes of the primary and secondary nodes are synchronized. This greatly reduces the latency generated by the primary and secondary nodes in the indexing processes and ensures that the secondary nodes can access the latest data in a timely manner.

  • Mirrored Reads

    The primary node synchronizes a portion of read traffic to the secondary node for processing. The secondary node processes read traffic, which can reduce the access latency.

  • Resumable Initial Sync

    ApsaraDB for MongoDB supports resumable upload during full synchronization between the primary and secondary nodes. This prevents synchronization from beginning in case of network disconnection.

  • Time-Based Oplog Retention

    You can customize the retention period of oplogs. When oplogs are cleared, full synchronization from the primary node is required.

  • Union

    The $unionWith stage is added to improve the query performance of MongoDB. This stage is similar to the UNION ALL statement in SQL.

  • Custom Aggregation Expressions

    The $accumulator and $function operators are added to implement custom aggregation expression and improve interface consistency and user experience.

Note

For more information about the new features of MongoDB 4.4, see Features of MongoDB 4.4.

MongoDB 4.2

MongoDB 4.2 uses the two-phase commit method to ensure the atomicity, consistency, isolation, durability (ACID) properties of transactions in sharded cluster instances. This greatly expands its business scenarios.

  • Distributed transactions

    The two-phase commit method ensures the ACID properties of transactions in sharded cluster instances, expands business scenarios, and achieves a leap from NoSQL to NewSQL.

  • Repeatable read

    The repeatable read feature provides the automatic retry capability in a poor-quality network environment. This reduces logic complexity at the service side and ensures the continuity of your business.

  • Wildcard indexes

    You can create a wildcard index for nondeterministic fields to overwrite multiple feature fields in a document for flexible management and usage.

  • Field-level encryption

    Field-level encryption is supported at the driver layer and can be used to separately encrypt specified sensitive information such as accounts, passwords, prices, and mobile phone numbers. You can use field-level encryption to make business more flexible and secure without full-database encryption.

  • Materialized views

    Latest materialized views can cache computing results to make computing more efficient and logic less complex.

MongoDB 4.0

MongoDB 4.0 is more suitable for finance and other scenarios that are dependent on transactions and use NoSQL features.

  • Cross-document transactions

    As the first NoSQL database that supports cross-document transactions, MongoDB 4.0 combines the speed, flexibility, features, and ACID guarantee of document models.

  • Migration speed increase by 40%

    Concurrent read and write operations allow new shard nodes to migrate data fast and bear service loads.

  • Read performance significantly improved

    The transaction feature ensures that secondary nodes no longer block read requests due to log synchronization. The multi-node scaling feature is supported in all versions to significantly improve reading capabilities.

MongoDB 3.4

Compared with MongoDB 3.2, MongoDB 3.4 has been improved in aspects of performance and security.

Note

MongoDB 3.2 has been phased out. For more information, see [Notice] ApsaraDB for MongoDB has phased MongoDB 3.2 out and released MongoDB 4.2 since February 4.

  • Faster synchronization between the primary and secondary nodes

    All indexes are created when data is synchronized (only the _id index is created in earlier versions). During data synchronization, the secondary node continuously reads new oplog information to ensure that the local database of the secondary node has enough space to store temporary data.

  • More efficient load balancing

    In earlier versions, mongos nodes are responsible for the load balancing of sharded cluster instances. Multiple mongos nodes contest a distributed lock. The node that obtains the lock performs load balancing tasks and migrates chunks between shard nodes. In MongoDB 3.4, the primary Configserver node is responsible for load balancing. This greatly improves the concurrency and efficiency of load balancing.

  • More aggregation operations

    Many aggregation operators are added in MongoDB 3.4 to provide more powerful data analysis capabilities. For example, bucket can conveniently classify data. $grahpLookup supports more complex relational operations than $lookup in MongoDB 3.2. $addFields supports more diverse document operations such as sum some fields and store the calculated result as a new field.

  • Sharding zones supported

    The zone concept is introduced for sharded cluster instances to replace the current tag-aware sharding mechanism. The zone feature can allocate data to one or more specified shard nodes. This feature allows you to conveniently deploy sharded cluster instances across data centers.

  • Collation supported

    In earlier versions, strings stored in documents are always compared byte by byte regardless of Chinese, English, uppercase, or lowercase. After collation is introduced, the string content can be interpreted or compared based on the used locale. Case-insensitive comparison is also supported.

  • Read-only views

    MongoDB 3.4 supports read-only views. MongoDB 3.4 virtualizes the data that meets a query condition into a special collection on which you can perform further queries.