blog

What’s New in MongoDB 4.4

Onyancha Brian Henry

Published

MongoDB 4.4 (currently in beta) is being rolled out with the main agenda of addressing developer suggestions from the MongoDB community . This version has been released to augment the database’s ability to operate at a convenient and dependable scale, therefore developed under the “user-driven engineering” principle to enable it deliver numerous improved features.

Improved Features in MongoDB 4.4

Hedged Reads

MongoDB query router issues read requests in parallel to multiple replica sets and  data results from the most efficient node is returned, thereby reducing the application latency.

Definable Shared Keys

Adding suffixes to a shard key after modifying data distribution during the scaling process.

Mirrored Reads

This is a feature that pre-warms caches of secondary replicas so as to reduce the aftermath of primary elections that may result from planned maintenance or outages.

Aggregation Enhancements

Aggregation enhancement has various improvements, including defining and costuming Aggregation Expressions, combining data from multiple mongo collections into a single result set, string manipulation, and new operators in array handling. The following are some of the enhancements:

$out

$out operation has been improved to output collection results to different databases as opposed to an earlier version that could only output to a collection in the same database that aggression was.

$indexStats

$indexStats has new field outputs in MongoDB 4.4 which includes fields :

building

It’s a Boolean Flag, which indicates the index being built.

spec

Specification document for each index

shard

The specific name of a shard if required

$merge

In MongoDB 4.4 $merge has been improved to output on the same collection that is being upgraded. Additionally, one can also output in a collection that appears on the pipeline like the $lookup.

$planCacheStats Changes

$planCacheStats state has been improved to run both mongod and mongos instances in MongoDB 4.4. Moreover, $planCacheSTats has a new field known as the host field when running mongo. PlanCache.list() is a wrapper for $planCacheStats aggregation stage.

$collStats Changes

$collStats has been made to accept the query exec stats during augment documentation. Additionally, Collection Scans as fields with the following description;

Field Name

Description

nonTailble

This is a 64-bit integer that performs a collection scan on several queries that do not use tailable cursor.

total

Total is a collection of queries performed collection scan which does not use a tailable cursor.

$unionWith Aggregation

MongoDB has added $unionWith, a feature that unifies collection sets, that is, it unites results of a pipeline from several collections into one set.

$unionWith Syntax

$unionWith has the following general syntax:

cd{ $unionWith: { coll: "", pipeline: [ , ... ] } }

$unionWith has a simplified version of syntax which is used to include all documents from a collection:

{ $unionWith: "" }  // include all documents from the specified collection

$accumulator aggregation

$accumulator is another new feature in MongoDB 4.4 that specifies a custom accumulator operator. Accumulators are operators that do not change state as documents make progress along the pipeline. You can use a $accumulator operator to execute JavaScript functions that are not supported by MongoDB. $accumulator is found in the following three stages of pipeline:

  1. $bucket stage: Only outputs documents containing not less than one document input.
  2. $group stage: Inputs documents by specified _id and outputs a document for each particular grouping
  3. $bucketAuto stage: It sorts document entries into specific group numbers known as buckets.

Syntax

The syntax for $accumulator is as follows:

{ $accumulator:{

init: ,

initArgs: ,    // Optional

accumulate: ,

accumulateArgs: ,

merge: ,

finalize: , // Optional

lang: 

  }}

$function Aggregation

$function aggregation defines an aggregation function in JavaScript.

$function operator can be used to define functions to use behaviors that are not supported by MongoDB

The syntax for $function is as below:

{

  $function: {

body: ,

args: ,

lang: "js"

  }

}

Other features included in the latest MongoDB 4.4 version are: writes concerns, global reads, stream replication, Resumable initial sync, and Compound hashed shard. 

What’s New With MongoDB Replica Sets?

Resumable Initial Sync

MongoDB 4.4 has a feature that attempts to resume an interrupted sync process.

Streaming Replications

In the previous versions of MongoDB, secondaries collected batches of oplog by request issued to sync from the source.  With MongoDB 4.4, synch processes form sources will send continuous streams of oplog entries to the secondary synch processes. 

Rollback Directory

From MongoDB 4.4 on the rollback, the collection directory is given the name according to the collection's UUID and the collection namespace.                                                                                                                 

Minimum Oplog Retention Period

From MongoDB 4.4 on, it is possible to specify the least number of hours you want to preserve an oplog entry.

Replica Set Reconfiguration Changes

MongoDB 4.4 has a command called replSetReconfig that allows addition or removal of not more than one voter at a time. Another new feature in MongoDB 4.4 is the changes to replSetGetConfig. The MongoDB 4.4 replSetConfig can stipulate a new option commitmentStatus.

Compound Hashed Shard Keys

Starting in MongoDB 4.4, you can shard a collection using a compound shard key with a single hashed field. Before 4.4, MongoDB did not support compound shard keys with a hashed field. Compound hashed sharding supports features like zone sharding, where the prefix (i.e., first) non-hashed field or fields support zone ranges while the hashed field supports more distribution of the sharded data. For example, the following operation shards a collection on a compound hashed shard key supporting zoned sharding:

sh.shardCollection(

  "examples.compoundHashedCollection",

  { "fieldA" : 1, "fieldB" : 1, "fieldC" : "hashed" }

)

General Sharded Clusters Improvements

Index Consistency Checks

In MongoDB 4.4, the config server essentially, by default, checks for file irregularities over the shards for sharded collections. The command serverStatus returns the field shardedIndexConsistency to report on file irregularities when running on the config server essential. In MongoDB 4.4, you'll have more than one removeShard operation in advance. In previous  adaptations, removeShard returns a mistake on the chance that another removeShard operation is in advance.

Shard Key Limit

Beginning in form 4.4, MongoDB expels the 512-byte constraint on the shard key estimate. For MongoDB 4.2 and prior, a shard key cannot surpass 512 bytes.

Improved Catalog Cache Refresh

In MongoDB 4.4, in case there is an old chunk, the catalog cache revives it to get  a shard that has the chunk. 

MongoDB 4.4 has the enableFinerGrainedCatalogCacheRefresh which  is a parameter for impairing catalog cache revival.  enableFinerGrainedCatalogCacheRefresh focuses on the shard and utilizing the more seasoned catalog cache revive behavior. 

The enableFinerGrainedCatalogCacheRefresh parameter defaults to true.

Query and Sharding Enhancements in MongoDB 4.4

MongoDB has a tradition of continually scaling out through the distribution of data into multiple nodes or through sharding. A shard key holds a document because the shard key of a given document can only be changed before an assignment and not after an assignment. 

The evolution of MongoDB has made it challenging to recalibrate shards of a provided content in MongoDB. To enable rebalancing, MongoDB 4.4 release has introduced refinable shard keys that permit documents sharded keys to be modified. 

Refinable shard keys allow a change in document shard keys to be changed by enabling documents belonging together on a shard to change their requirements and hence becomes dynamically rebalanced.

Rebalancing can be programmatically or aggressively depending on how the user views it over time.

Other Improvements

Aggregation of MongoDB collection when different datasets allow queries through Unions. Such a capability enables the treatment of data differently and not as a separate ETL.

Data can be moved and consolidated on the server and passed to the client, and the process does not require multiple trips to manage a complete result.  

$function is among costumed Aggregation that enables the execution of more complex aggregations on the server-side and enhances the data processing process. 

Various version costumed procedures appear on the released MongoDB 4.4. The costumed features have been linked to the increased performance of the beta version. Nonetheless, $function is only invoked when other costumed and inbuilt features are not sufficient in the undergoing process.

MongoDB Query Language and Drivers

  1. Custom Aggregation appearances have owners function extending MongoDB as part of the aggregation execution pipeline.
  2. Union Aggregation has more in-depth analysis and exploration through blending data from multiple collections into the Union Aggregation pipeline.
  3. Write concerns and Global Read to write durability and configure cluster read isolation.
  4. Swift drivers and New Rust
  5. Scaled-Out Flexibility and performance
  6. Streaming Replication and Simultaneous Indexing reduces replica lag to serve data to users in MongoDB 4.4.
  7. Results are returned as soon as possible due to the Hedged Reads minimizing p65 and p99 latencies by submitting a read request to multiple data replicas in MongoDB.
  8. Retaining data locality as Compound Hashed keys are distributed evenly across various shards with their shard key.
  9. No system downtown when defining and refining the shard key at any given time.

Resilience and Security

  1. Authentication in MongoDB 4.4 beta is above 50% faster and is TLS 1.3.
  2. Connection to MongoDB Atlas requires AWS IASM Authentication, which simplifies the cloud-native security by reusing temporary Amazon IAM credential and existing regular.
  3.  Recovers nodes by Resumable Initial sync that eases the scale-out process by adding new replicas. Reduced impact of primary elections by Mirrored Reads warming the caches of secondary after planned maintenance or outage. 

Conclusion

MongoDB 4.4 has unleashed a better experience in a non-relational document-based database by improving performance features in its system. The improvements have enabled faster analytical, operational, and transactional applications with MongoDB 4.4. 

MongoDB 4.4 has also allowed Flexibility when defining data distribution as the requirements of operation changes. Improvement made on MongoDB 4.4 has made it more reliable in terms of latency, sophistication, and security control while using Mongo Atlas, which is the cloud.

Subscribe below to be notified of fresh posts