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.

Supported MongoDB versions

ApsaraDB for MongoDB supports the following MongoDB versions:
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 MongoDB versions.

Storage engines

Storage engine Use scenario Description
WiredTiger It is the default storage engine and is applicable to most business scenarios. Data is displayed in the B-tree structure. Compared with the earlier MMAPv1 storage engine, WiredTiger significantly improves performance and reduces storage costs by compressing data.

Relationship between MongoDB versions and storage engines

Storage engine MongoDB 5.0 MongoDB 4.4 MongoDB 4.2 MongoDB 4.0 MongoDB 3.4
  • Replica set instances
  • Sharded cluster instances
  • 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 5.0

MongoDB 5.0 marks a new release cycle to deliver new features to users faster than in the past.
  • Native time series platform

    MongoDB 5.0 natively supports the entire lifecycle of time series data, from ingestion, storage, query, real-time analysis, and visualization through to online archival or automatic expiration as data ages. This makes it faster to build and run time series applications at a lower cost. With the release of MongoDB 5.0, MongoDB has expanded the universal application data platform, which makes it easier for developers to process time series data. This further expands the use scenarios of MongoDB in areas such as IoT, financial analysis, and logistics.

  • Live resharding
    Live resharding allows you to change the shard key for your collection on demand as your workload grows and evolves. No database downtime or complex migration within the dataset is required in this process. You can run the reshardCollection command in the Mongo Shell to select the database and collection that you want to reshard and specify the new shard key.
    reshardCollection: "<database>.<collection>", key: <shardkey>
    • <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, MongoDB clones an existing collection and then applies all operation logs in the existing collection to a new collection. When all operation logs are applied, MongoDB switches business to the new collection and deletes the existing collection.
  • Versioned API

    The Versioned API allows new features and improvements to be flexibly added to the database of each version with full backward compatibility. When you want to change an API, you can add a new version of the API and run it on the same server at the same time as the existing version of the API. With the accelerated release of MongoDB versions, the Versioned API enables quicker and easier access to the features of the latest MongoDB version.

    The Versioned API defines a set of commands and parameters that are most commonly used in applications. These commands do not change regardless of whether a database release is an annual major release or a quarterly rapid release. You can pin the driver to a specific version of the MongoDB API by decoupling the application lifecycle from the database lifecycle. This way, even if the database is upgraded and improved, your application can continue to run for several years without modifications to code.

  • Default majority write concern

    Starting with MongoDB 5.0, the default write concern is majority. A write operation is committed and write success 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 can provide stronger data durability guarantees out of the box.

  • Long-running snapshot queries

    Long-running snapshot queries improve the versatility and flexibility of applications. By default, snapshot queries executed by this feature have an execution duration of 5 minutes. You can also customize the duration of a snapshot query. In addition, this feature maintains strong consistency with snapshot isolation guarantees without impacting the performance of your live and transactional workloads, and enables snapshot queries to be executed 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 enhanced user experience, the new 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 an intuitive and interactive experience.

  • Version release adjustment

    Starting with the 5.0 release, 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 a production environment.

MongoDB 4.4

MongoDB 4.4 addresses aspects that were frequently mentioned by users of earlier versions.
  • Hidden Indexes

    Existing indexes are hidden to ensure that these indexes are not 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 concurrent access to a single shard and alleviates 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 clusters, a read request can be simultaneously sent to two replicas of the same shard. The results first received are used to recover the client. This reduces the request latency.

  • Streaming Replication

    Operation logs of the primary database actively flow into the secondary database. Compared with the previous version where the secondary database is polled, this method saves nearly half of the round-trip time and improves the performance of data replication between the primary and secondary databases.

  • Simultaneous Indexing

    The indexing processes of the primary and secondary databases are synchronized. This greatly reduces the latency generated by the primary and secondary databases in the indexing processes and ensures that the secondary database can access the most recent 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

    MongoDB supports resumable upload during full synchronization between primary and secondary nodes. This prevents the need for a full synchronization from scratch in the event of a network disconnection.

  • Time-Based Oplog Retention

    You can customize the retention period of operation logs. When operation logs 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 expressions 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 a two-phase commit protocol to ensure the atomicity, consistency, isolation, durability (ACID) properties of transactions in sharded clusters. This greatly expands its business scenarios.
  • Distributed transactions

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

  • Repeatable reads

    The repeatable read feature provides the automatic retry capability in a poor-quality network environment. This reduces logic complexity on the service side and ensures 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 abandon full-database encryption and use field-level encryption to make business more flexible and secure.

  • 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 better suited for finance and other scenarios that are dependent on transactions and use NoSQL features.
  • Cross-document transactions

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

  • 40% increase in migration speed

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

  • Significantly improved read performance

    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 read capabilities.

MongoDB 3.4

MongoDB 3.4 offers higher performance and security than MongoDB 3.2.
  • 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 operation log 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 load balancing of sharded clusters. Multiple mongos nodes compete for 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 to 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 enables richer document operations such as summing some fields and saving them as a new field.

  • Sharding zones

    The zone concept is introduced for sharded clusters 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 clusters across data centers.

  • Collation

    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.