Mongo vs Tar MK... When is it appropriate to use Mongo MK for AEM

The general thumb rule is MongoMK provides better scalability and TarMK provides better performance. But most applications requires both scalability and performance.

The detailed analysis for Author & Publish instances as per the Adobe recommended metrics is

Author Environment
Metrics comparison against the criteria to validate if MongoMK would be the suitable option for an application is in the below table

Metric	Criteria	Dotcom Requirement	In favor of MongoMK
Number of named users connected in a day	In the thousands or more	Less than 1000	No
Number of concurrent users	In the hundreds or more	100 concurrent users	Maybe
Volume of asset ingestions per day	In hundreds of thousands or more	About 1000’s of assets ingested per day during the peak	No
Volume of page edits per day	In hundreds of thousands or more (including automated updates via Multi Site Manager or news feed ingestions for example)	No automated updates, will have about 1000’s of page edits during the pack	No
Volume of searches per day	In tens of thousands or more	May have tens of thousands of searches during the peak	May

Other points on MongoMK for Authoring Environment
· Scalability – MongoMK provides the ability to have multiple AEM instances share the same MongoDB instance. This shared all clustering approach enables horizontal scalability of AEM instances, adding additional AEM nodes as the load increases
· Replication – MongoMK reduces the overhead of replication; it effectively delegates replication functionality to the MongoDB, which has mature model to maintain replica sets. Also the no. of MongoDB replicas and AEM instances can be scaled independently
· Distributed Authoring teams – MongoMK helps when we have distributed authoring teams spread across geographies. Content changes done by all authors gets persisted to the same primary MongoDB instance and gets replicated to the secondary replica sets
· Automated Recovery – MongoDB replica sets and automated failover helps with automated system recovery when the primary MongoDB instance goes down or in case of the whole data center failure; never the less TarMK also provides the option for setting up automated recovery

Recommended Option for Authoring Environment
The choice of MongoMK or TarMK for authoring instance can be based on no. of AEM instances required in authoring environment, in line with Adobe recommendation.
· If more than 1 active AEM instance is needed for Authoring environment – MongoMK
· If the volume can be handled with 1 active AEM instance - TarMK

Publish Instance
The thumb rule for considering if MongoMK is a choice for publish instance is if publish instance is required to support user generated content.
Other points on MongoMK for Publish Environment
Code releases – When releasing code changes to production for an application, we will have to release it to one data center, validate the release and then release it to the other data center. This sometimes is a mandatory requirement to ensure 24/7 availability. Such rolling release is well supported by TarMK. With MongoMK, code release gets replicated to all MongoDB replica’s making the isolated release to one data center difficult.
AEM Upgrades – Applying patches and release upgrades to AEM also requires rolling releases which is well supported by TarMK because of their shared nothing clustering approach
Horizontal scalability – Both TarMK and MongoMK supports horizontal scalability for publish instance. With TarMK, we can have a form of independent shared nothing AEM instances, which are kept in sync by replication.

Recommended Option for Publish Environment
The choice of MongoMK or TarMK for publish instance can be based on if the site supports user generated content or not.
· Site support user generated content – MongoMK
· Site does not support user generated content - TarMK

Binary Data Store in AEM

In AEM 6.x, binaries are by default chunked and stored in the Node data store – Segment (TarMK) or Document (MongoMK). Options provided to store binary data (>4kb) in a separate data store – file system or an S3 bucket. The separate datastore is preferred for production systems esp. asset deployments for performance and maintenance reasons.

Source: Configuring Node Stores and Data Stores in AEM 6 – docs.adobe.com

AEM MK (Microkernels) - TarMK and MongoMK

AEM comes with Oak storage. Oak(Apache Jackrabbit Product) is a new JCR implementation with a completely new internal architecture.

There are two options for the AEM persistence layer back-end used by Oak : TarMK and MongoMK.

Main differences b/w TarMK and MongoMK


Adobe recommendation says we must consider MongoMK when we come across below metrics

Number of named users connected in a day: in the thousands or more.
Number of concurrent users: in the hundreds or more.
Volume of asset ingestion per day: in hundreds of thousands or more.
Volume of page edits per day: in hundreds of thousands or more (including automated updates via Multi Site Manager or news feed ingestion for example).
Volume of searches per day: in tens of thousands or more.


TarMK is optimized for single-node performance whereas MongoMK is designed for scalability and clustered deployments also the volume of data.

AEM Microkernels - MongoMK vs TarMK

Latest AEM comes with Oak storage. Oak(Apache Jackrabbit Product) is a new JCR implementation with a completely new internal architecture.
There are two options for the AEM persistence layer back-end used by Oak: TarMK and MongoMK. Let us see the scenarios where each one is feasible and what are all the main differences.

TarMK vs MongoMK


Adobe recommendation says we must consider MongoMK when we come across below metrics

A number of named users connected in a day: in the thousands or more.

• Number of concurrent users: in the hundreds or more.
• The volume of asset ingestion per day: in hundreds of thousands or more.
• The volume of page edits per day: in hundreds of thousands or more (including automated updates via Multi Site Manager or news feed ingestion for example).
• The volume of searches per day: in tens of thousands or more.

Prerequisites for considering MongoMK as the persistence layer.

1. Once we identified MongoMK as the persistence layer below factors are mandatory.
2. Ensure involving MongoDB architects/ Adobe MongoDB Specialists for designing the solution.
3. AEM Developers should work hand in hand with MongoDB developers to implement a successful solution.
4. For a better turn around time, always ensure to have Mongo DB Maintenance License.
5. Ensure the proposed design is validated by an Adobe Certified Experience Manager Architect to avoid any future issues. 

Advantages of MongoMK in Authoring Instances
Horizontal Scalability Support – MongoMK supports multiple AEM instances to share the same MongoDB instance.
Efficient Data Replication – MongoMK effectively delegates replication functionality to MongoDB, which has a mature model to maintain replica sets. The major advantage here is MongoDB replicas and AEM instances are independent of each other.
Distributed Authoring Team Support – Content authoring across different geographical regions is supported by Mongo MK. At first, data gets saved int the primary MongoDB and then gets replicated to the secondary DB replica sets.
Automated Failover Recovery – MongoDB supports automated failover. The efficient configuration can help in automated system recovery from data center failure.

Advantages of TarMK in Publish Instances
Automated Failover Recovery - The efficient configuration of TarMK provides Automated recovery during system failures.
24/7 availability: Code changes are released on one data center, validate the release and then release it to the other data center. TarMK supports such rolling release efficiently.
Efficient upgrades: AEM Upgrades and patch fixes needs rolling release, thus TarMK provides better support.

Huge Data considerations: Which one to use?
If most of the Data in (TB) are binaries, TarMK is a good fit and a data store on the file system. If the data (in multiple TB) is structured content/nodes, MongoMK is the better choice because we can share the data.

Sharding can be found at MongoDB Documentation: Overview / Adobe Experience Manager 6.0 / Deploying and Maintaining / or The MongoDB Manual.

Final Notes:
TarMK is optimized for single-node performance whereas MongoMK is designed for scalability and clustered deployments. Another factor is the volume of the data. Also, keep in mind the MongoMK setup/configuration/maintenance requires additional knowledge about MongoDB.

In my next blog I will be talking about MongoMK Recommended Deployments(AEM on MongoDB )

AEM With MongoMK - Options

We can have 2 types of MongoMK configurations for AEM Oak Clusters.
1) Failover for High Availability in a Single Datacenter


Here a primary MongoDB will be used for Read/Write. So the multiple Oak instances accessing a MongoDB replica set within a single data center.
This setup helps for high availability and redundancy in the event of a hardware or network failure

Major advantages are:

• Scalability
• High availability
• Redundancy
• Automated failover of data layer

One of the disadvantage of this setup is, there are some performance issues when compared with TarMK.

2) Failover Across Multiple Datacenters
Here multiple Data Centers are involved. Primary MongoDB will be replicated to secondary systems. So multiple Oak instances accessing a MongoDB replica set across multiple data centers. In this configuration, MongoDB replication provides the same high availability and redundancy as compared to the previous configuration but it also includes the ability to handle a data center outage.

Major advantages are

• Scalability
• High availability
• Redundancy
• Automated failover of data layer

Final notes:
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances.

Footnotes:
What is MongoMK Arbiter? Why we need an Arbiter?

In software, the CAP theorem says, "If there are an equal number of servers on either side of the partition, the database cannot maintain CAP (Consistency, Availability, and Partition tolerance). An Arbiter is specifically designed to create an -imbalance- or majority on one side so that a primary can be elected in this case."

As per MongoDB site(https://docs.mongodb.com/v3.4/tutorial/add-replica-set-arbiter/) "Arbiters are MongoDB instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter. Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host."

If you get an even number of nodes on both sides, MongoDB will not elect a primary and your set will not accept writes.