The content of this page has been automatically translated by AI. If you encounter any problems while reading, you can view the corresponding content in Chinese.
Help & Documentation>TencentDB for MongoDB>Product Intro>Product Features>Overview of New Features in v7.0

Overview of New Features in v7.0

Last updated: 2025-02-08 10:04:48

On this page:

This article lists the main features introduced in TencentDB for MongoDB v7.0. For details, see MongoDB 7.0 release-notes.
Note:
v7.0 is currently in gradual phased release. For early access, please submit a ticket to apply.

Performance Improvement of Slot-Based Query Execution Engine

The Slot-Based Query Execution Engine in TencentDB for MongoDB v7.0 is a further optimization and expansion of previous versions. This technology breaks down query operations into a series of "slots," each responsible for a specific part of the query, allowing for finer-grained parallel processing. This design enables the database to handle complex queries more efficiently, especially for aggregation pipeline queries with $group or $lookup stages, providing better performance.

Shard Key Analysis

The analyzeShardKey command and db.collection.analyzeShardKey() method introduced in MongoDB 7.0 are important tools for analyzing the performance of a collection's shard key. These tools evaluate the appropriateness of the shard key based on the results of sample queries, helping to design a better schema and shard key, ensuring more reasonable data distribution in the sharded cluster, and improving query efficiency.
 The basic syntax of the analyzeShardKey command is as follows:
db.adminCommand({
  analyzeShardKey: <string>,
  key: <shardKey>,
  keyCharacteristics: <bool>,
  readWriteDistribution: <bool>,
  sampleRate: <double>,
  sampleSize: <int>
})
analyzeShardKey field: specify the namespace of the collection to be analyzed.
key field: define the shard key to be analyzed. This can be an unsharded collection, a candidate shard key of the sharded collection, or the current shard key of the sharded collection.
keyCharacteristics field: decide whether to calculate the characteristic metrics of the shard key, such as associated cardinality, frequency, and monotonicity.
readWriteDistribution field: decide whether to calculate the metrics of read-write distribution.
sampleRate field: define the proportion of documents to be sampled when calculating the characteristic metrics of the shard key.
sampleSize field: define the number of documents to be sampled when calculating the characteristic metrics of the shard key.
Note:
Use the configureQueryAnalyzer command or the db.collection.configureQueryAnalyzer() method to configure the query analyzer to sample queries running on the collection.

Queryable Encryption

Queryable Encryption introduced in MongoDB 7.0 is a significant security feature that allows users to perform client-side encryption of sensitive data fields and store these fields in a fully randomized encrypted data form on the database server. It also supports running expressive queries on encrypted data. Here are some key points of queryable encryption:
Data Encryption and Querying: Queryable encryption allows client-side encryption of sensitive data fields and stores these fields in encrypted form on the database server. It also supports performing equality and range queries on encrypted data.
Encryption and Decryption Process: Sensitive data is encrypted throughout its lifecycle (including in transit, at rest, in use, in logs, and in backups) and is only decrypted on the client side.
Automatic Encryption and Explicit Encryption: Queryable encryption can be implemented through automatic encryption or explicit encryption. Automatic encryption allows encrypted read and write operations without the need to add explicit calls for encryption and decryption fields. Explicit encryption allows encrypted read and write operations through the MongoDB driver's encryption library, but this requires specifying the logic to use this library for encryption in the application.
Key Management: When using queryable encryption in a production environment, a remote Key Management Service (KMS) must be used to store encryption keys.

AutoMerger

The AutoMerger introduced in MongoDB 7.0 is an important component of the Balancer, designed to optimize data distribution in a sharded cluster. The AutoMerger runs automatically when data or index distribution is uneven, there are too many shards, or during data migration. It automatically merges chunks that meet specific merge requirements. The auto merge operation is performed every autoMergerIntervalSecs seconds. Administrators can enable or disable the AutoMerger using the configureCollectionBalancing command, for example:
db.adminCommand({
  configureCollectionBalancing: "<db>.<collection>",
  chunkSize: <num>,
  defragmentCollection: <bool>,
  enableAutoMerger: <bool>
})

New Aggregation Operators: $median and $percentile

$median Aggregation Operator: Used to calculate the median of input values. The median is the middle value when the values are arranged in order. If the number of input values is odd, the median is the middle value; if even, the median is the average of the two middle values. The following example groups by category and calculates the median of the value field of each group.
  db.collection.aggregate([
  {
    $group: {
      _id: "$category",
      medianValue: { $median: { input: "$value" } }
    }
  }
])
$percentile operator: Used to calculate the percentile value of a specified percentile in an input array. A percentile indicates the percentage of data items in a set of data that are less than or equal to this value. The following example groups by category and calculates the 90th percentile of the value field for each group.
  db.collection.aggregate([
  {
    $group: {
      _id: "$category",
      percentileValue: { $percentile: { input: "$value", p: 0.90, method: "approximate" } }
    }
  }
])

Compound Wildcard Indexes

The compound wildcard indexes introduced in MongoDB 7.0 is a new feature that allows creating indexes on multiple fields, which can include a wildcard item and multiple non-wildcard items. This type of index is particularly useful for documents with flexible schemas, where document field names may differ in the collection. In the following example, wildcardProjection is used to specify which subfields should be included in the index. The wildcard index item $** specifies every field in the collection, while wildcardProjection restricts the index to the specified fields "customFields.addr" and "customFields.name". For more information, see Compound Wildcard Indexes.
db.runCommand({
  createIndexes: "salesData",
  indexes: [
    {
      key: {
        tenantId: 1,
        "$**": 1
      },
      name: "tenant_customFields_projection",
      wildcardProjection: {
        "customFields.addr": 1,
        "customFields.name": 1
      }
    }
  ]
})

Other Features

ChangeStream supports large change events and introduces the $changeStreamSplitLargeEvent stage to split large change events exceeding 16MB. For more information, see Large Change Stream Events.
The slow log adds a new field catalogCacheIndexLookupDurationMillis to record the time spent retrieving index information from the index cache, helping to analyze and diagnose query performance issues more accurately, especially in operations involving index lookups. For more information, see log messages for slow queries.
WT engine dynamic throttling: Automatically adjusts the transaction concurrency of the WT storage engine dynamically to optimize database performance under high load. For more information, see Concurrent Storage Engine Transactions.
Security enhancement, supporting KMIP 1.0 and 1.1, as well as OpenSSL 3.0 and OpenSSL FIPS, enhancing data security.
Added new statistics metrics to monitor chunk migrations. For more information, see New Sharding Statistics for Chunk Migrations.
Metadata consistency check, the checkMetadataConsistency command introduced in MongoDB 7.0 is used to check metadata consistency issues in sharded clusters.
中国站 - English