ApsaraDB for MongoDB:MongoDB versions and storage engines

ApsaraDB for MongoDB supports the following versions:

• MongoDB 8.0

• MongoDB 7.0

• MongoDB 6.0

• MongoDB 5.0

• MongoDB 4.4

• MongoDB 4.2

• MongoDB 4.0

• MongoDB 3.4 (discontinued)

• MongoDB 3.2

  MongoDB 3.2 has been discontinued. For more information, see [Notice] ApsaraDB for MongoDB discontinued version 3.2 and launched version 4.2 on February 4.

MongoDB 6.0 introduces features such as Queryable Encryption and Cluster-to-Cluster Sync. MongoDB 6.0 also optimizes time series collections, change streams, aggregation, queries, elasticity, and security.

• Queryable encryption

  Queryable Encryption lets you encrypt sensitive data from the client side, store the data as fully randomized encrypted data on the database server, and run expressive queries on the encrypted data.

  Queryable encryption allows only the client to view the plaintext of sensitive data. When a query reaches the server, it includes an encryption key obtained from Key Management Service (KMS). The server then processes the query on the ciphertext and returns an encrypted response. Finally, the client decrypts the response using the key and presents it in plaintext.

• Cluster-to-Cluster Sync

  Cluster-to-Cluster Sync introduces the new mongosync tool, which supports continuous and unidirectional data synchronization between two MongoDB instances across any environment, including hybrid, Atlas, on-premises, and edge environments. You can also control and monitor the entire synchronization process in real time and start, stop, resume, or even reverse the synchronization as needed.

• Time series collections

  MongoDB 6.0 enhances time series collections in terms of indexing, querying, and sorting.

  • It introduces secondary and compound indexes to improve read performance.

  • It introduces Geo-Indexing for spatio-temporal data. This adds geographic information to time series data, which helps with analysis in scenarios that involve distance and location.

    Example scenarios include tracking the temperature changes of a cold chain transport vehicle in summer and monitoring the fuel consumption of a cargo ship on a specific route.

  • It optimizes last point queries on time series data. You no longer need to scan the entire collection to query the last data point.

  • It optimizes the sorting of time series data. Sorting operations are completed more efficiently using clustered and secondary indexes on time and metadata fields.

• Change streams

  This release introduces the following new features and optimizations:

  • It supports viewing pre-images of changes.

    Note

    Versions before MongoDB 6.0 only support viewing post-images. Starting from MongoDB 6.0, you can view both pre-images and post-images. For more information about pre-images and post-images, see Change Streams with Document Pre- and Post-Images.

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

  • It adds the wallTime field to Change Events. The timestamp supports multiple conversion and display operators, including $toDate, $tsSeconds, and tsIncrement, to facilitate business consumption.

• Aggregation

  This release includes the following new features and optimizations:

  • Sharded cluster instances support $lookup and $graphLookup.

  • It improves support for JOINS in $lookup.

  • It improves support for graph traversal in $graphLookup.

  • It improves $lookup performance, with up to a hundredfold improvement in some scenarios.

  Note

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

• Query

  MongoDB 6.0 adds operators such as $maxN, $topN, $minN, $bottomN, $lastN, and $sortArray. These operators allow you to offload more computations from the business layer to the database, which makes the business layer more lightweight.

  Note

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

• Elasticity

  The following new features and optimizations are now available:

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

  • It supports the configureCollectionBalancing command. This command supports the following features:

    • You can set different chunk sizes for different sharded tables.

      Example: For a very large sharded table, you can set the chunk size to 256 MB. For a relatively small sharded table where you want a more even distribution across shards, you can set the chunk size to 64 MB or 32 MB.

    • You can actively defragment a collection.

      Compared with the compact command, the configureCollectionBalancing command provides a better defragmentation service, which effectively reduces 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. CSFLE now supports any key management provider that complies with the Key Management Interoperability Protocol (KMIP). This means that in addition to local key management based on KeyFile, MongoDB can integrate with third-party key management devices using KMIP, which provides users with enhanced security.

    Note

    The CSFLE feature is widely used in managing sensitive data, especially in data migration scenarios.

The new release cycle enables faster delivery of new features to users.

• Native time series platform

  By natively supporting the entire lifecycle of time series data, from ingestion, storage, and querying to real-time analysis, visualization, and online archiving or automatic expiration as data ages, building and running time series applications becomes faster and more cost-effective. With the release of MongoDB 5.0, MongoDB expanded its universal application data platform, which makes it easier for developers to handle time series data and further extends its application scenarios in areas such as the Internet of Things (IoT), financial analytics, and logistics.

• Live resharding

  You can change the sharding key of a collection on demand as your business runs and data grows, without database downtime or complex migrations within the data collection. To do this, you can run the reshardCollection command in the MongoDB Shell, select the database and collection that you want to reshard, and specify the new sharding key.

  reshardCollection: "<database>.<collection>", key: <shardkey>

  Note

  • <database>: The name of the database to reshard.

  • <collection>: The name of the collection to reshard.

  • <shardkey>: The name of the sharding key.

  • When you call the reshardCollection command, MongoDB clones the existing collection, applies all oplog entries from the existing collection to the new collection, and then automatically switches to the new collection after all oplog entries are applied. The old collection is deleted in the background.

• Versioned API

  The Versioned API allows MongoDB to flexibly add new features and improvements to the database in each release, and new versions are compatible with earlier ones. When you need to change an API, you can add a new version of the API and run it on the same server concurrently with existing versioned APIs. As MongoDB releases accelerate, the Versioned API enables you to use the latest MongoDB features faster and more easily.

  The Versioned API defines a set of the most commonly used commands and parameters for applications, which remain unchanged whether the database is in an annual major release or a quarterly rapid release. By decoupling the application lifecycle from the database lifecycle, you can pin your driver to a specific version of the MongoDB API. This allows your application to continue running for years without code modifications, even as the database is upgraded and improved.

• Default Majority Write Concern

  Starting from MongoDB 5.0, the default write concern level is `majority`. A write operation is committed and a success response is returned only when the write has been applied to the primary node and persisted to the logs of a majority of replica nodes. This provides stronger data reliability guarantees out of the box.

• Long-running snapshot queries

  Long-Running Snapshot Queries increase the versatility and resilience of applications. You can use this feature to run queries with a default duration of 5 minutes, which can be adjusted, while you maintain snapshot isolation consistent with a real-time transactional database. You can also run snapshot queries on secondary nodes, which lets you run different workloads in a single cluster and scale them across different shards.

• New MongoDB Shell

  To provide a better user experience, MongoDB 5.0 redesigned the MongoDB Shell (mongosh) from the ground up. It offers a modern command-line experience, enhanced usability features, and a powerful scripting environment. The new MongoDB Shell is the default shell for the MongoDB platform. It introduces syntax highlighting, intelligent auto-completion, contextual help, and useful error messages to create an intuitive and interactive experience.

• Version release adjustment

  Starting from MongoDB 5.0, MongoDB releases are divided into Major Releases and Rapid Releases. Rapid Releases are provided as development versions for download and testing but are not recommended for production environments.

This version addresses the top user pain points from previous versions.

• Hidden Indexes

  You can hide existing indexes to ensure that they are not used in subsequent queries. This lets you observe whether deleting a target inefficient index causes business performance fluctuations. If there is no impact, you can safely delete the inefficient index.

• Refinable Shard Keys

  You can add one or more suffix fields to improve the distribution of existing documents on chunks. This avoids concentrating all access on a single shard and distributes the server load.

• Compound Hashed Shard Keys

  You can specify a single hashed field in a compound index, which greatly simplifies business logic.

• Hedged Reads

  For sharded cluster instances, a read request can be sent to two replica set members of a shard simultaneously. The result from the member that responds the fastest is returned to the client, which reduces request latency.

• Streaming Replication

  Oplog entries from the primary database are actively streamed to the secondary database. Compared with the polling method in previous versions, this saves nearly half the round-trip time and improves the performance of primary-secondary replication.

• Simultaneous Indexing

  Index creation on the primary and secondary databases is synchronous. This significantly reduces index creation latency and ensures that the secondary database can promptly access the latest data.

• Mirrored Reads

  The primary node replicates a certain proportion of read traffic to the secondary database for execution. This ensures that the secondary node handles a portion of the read traffic, which reduces business access latency.

• Resumable Initial Sync

  Resumable Initial Sync provides a resumable transfer feature during full synchronization between the primary and secondary databases. This prevents the full synchronization process from restarting from the beginning due to network disconnections.

• Time-Based Oplog Retention

  Time-Based Oplog Retention supports customizing the retention period for oplog entries to prevent them from being cleared on the primary database, which would trigger a full synchronization.

• Union

  MongoDB 4.4 adds the $unionWith stage to implement functionality similar to SQL's union all, which enhances MongoDB's query capabilities.

• Custom Aggregation Expressions

  MongoDB 4.4 adds $accumulator and $function to implement custom Aggregation Expressions, which improves interface uniformity and user experience.

MongoDB 4.2 uses a two-phase commit method to ensure the atomicity, consistency, isolation, and durability (ACID) properties of transactions in sharded clusters, which greatly expands its applicable business scenarios.

• Distributed transactions

  Distributed transactions use a two-phase commit method to ensure the ACID properties of transactions in sharded clusters. This greatly expands MongoDB's business scenarios and marks a leap from NoSQL to NewSQL.

• Retryable reads

  Retryable reads provide an automatic retry capability in weak network environments. This reduces the logical complexity on the business side and ensures business continuity.

• Wildcard indexes

  For fields that are not predetermined, you can create a wildcard index to cover multiple feature fields under a document. This is convenient to manage and flexible to use.

• Field-level encryption

  Field-level encryption is supported at the driver level. You can encrypt specific sensitive information, such as account names, passwords, prices, and phone numbers, individually. This avoids full-database encryption and improves business flexibility and security.

• Materialized views

  Materialized views can cache calculation results to avoid repeated calculations, improve operational efficiency, and reduce logical complexity.

MongoDB 4.0 is more suitable for scenarios such as finance that rely on transactions and use NoSQL features.

• Cross-document transaction support

  MongoDB 4.0 is the first NoSQL cloud database to support cross-document transactions. It combines the speed, flexibility, and functionality of the document model with ACID guarantees.

• 40% faster migration speed

  Concurrent reads and writes allow newly added shard nodes to complete data migration faster to handle the business workload.

• Greatly expanded read performance

  With the transaction feature, secondary nodes no longer block read requests due to log synchronization. Alibaba Cloud also supports a multi-node extension feature across all versions, which can significantly improve the read capabilities of your business.

MongoDB 3.4 offers various improvements in performance and security compared with version 3.2.

• Faster primary-secondary synchronization

  All indexes are built while data is being synchronized. Previous versions only built the _id index. Also, during the data synchronization phase, secondary nodes continuously read new oplog information to ensure that the local database on the secondary nodes has enough storage space for temporary data.

• More efficient load balancing

  In version 3.2 and earlier, load balancing for sharded clusters was handled by Mongos nodes. Multiple Mongos nodes would compete for a distributed lock. The Mongos node that successfully acquired the lock would perform the load balancing task and migrate chunks between shard nodes. In version 3.4, load balancing is handled by the primary node in the ConfigServer, which greatly improves both the concurrency and efficiency of load balancing.

• Richer aggregation operations

  Version 3.4 introduces several aggregation operators to enhance data analytics capabilities. For example, bucket simplifies data categorization, $graphLookup supports more complex relationship operations than the $lookup operator from version 3.2, and $addFields enables more advanced document operations, such as summing specific fields and storing the result as a new field.

• Support for Sharding Zones

  The concept of a Zone is introduced in sharded clusters, mainly to replace the tag-aware sharding mechanism. It can assign certain data to one or more specified shard nodes. This feature greatly facilitates the cross-data-center deployment of sharding clusters.

• Support for Collation

  In previous versions, strings stored in documents were always compared byte by byte, regardless of language or case. With the introduction of Collation, the content of strings can be interpreted and compared according to the locale. Case-insensitive comparison is also supported.

• Support for read-only views

  Version 3.4 adds support for read-only views. Data in a collection that meets a specific query condition can be virtualized into a special collection, on which users can perform further query operations.