The ObjectRocket MongoDB infrastructure is scalable, performant, highly available, and easy to use.
The Mission Control interface offers easy provisioning. An ObjectRocket instance is a highly available cluster, which can contain many databases. After you create your instance, you can access it by using any of the standard MongoDB connection methods. You can manage the entire instance with it’s own connection string and access control lists (ACLs). You can also manage individual databases and collections.
📝MongoDB space usage:-
The following information outlines how ObjectRocket calculates space usage for all MongoDB instances, including determining how much space your MongDB instance is using and an explanation of associated charges.
✒️Calculating space for MongoDB plans:-
On the ObjectRocket MongoDB platform, a plan represents the maximum amount of data you can store on a MongoDB instance without taking any action. When building a MongoDB instance for the first time, you’re required to choose a size in incrementing blocks, such as 5 GB, 20 GB, 50 GB, or others. Because you’ll know exactly how the capacity increases as you grow, this size selection makes it easy to plan out scaling in advance.
If the MongoDB instance is sharded, the plan size is multiplied by the number of shards currently attached to the instance to give you the maximum amount of space available. If the MongoDB instance is a replica set, the plan size is the maximum available storage space.
The following formula shows how to calculate the maximum gigabytes in plan (mgp) for all MongoDB instance types:
mgp = (SizeofPlan in GBs) * n (where n is the number of shards)
By using this formula, a 5 GB sharded instance with 3 shards has a mgp of 15 GB.
All data used for determining space usage is pulled directly from MongoDB by using db.stats() across each individual database on each shard, which differs slightly for WiredTiger or MMAPv1.
If the MongoDB instance is running on WiredTiger, two values are used from the dbStats output, dbStats.storageSize (dss) and dbStats.indexSize (dis). Using these values is necessary because WiredTiger stores data and indexes in separate files.
The following formula shows how space consumed is summarized for WiredTiger per database:
dbs1 + dbs2 + … + dbsn = Document Storage for instance (ids)
dbi1 + dbi2 + … + dbin = Index Storage for instance (iis)
dbs + dbi = Storage used for a single database (sdb)
sdb1 + sdb2 + … + sdbn = Aggregated consumed space within Replica Set (asc)
After calculating how much space each database and index use, ObjectRocket uses that information to find out how much space a MongoDB instance is using with the following formula:
asc1 + asc2 + … + ascn = Total consumed space on all replica sets (tsc)
MMAPv1 stores data and indexes on the same files, so the only important output is dbStats.fileSize. While MMAPv1 logs both dbStats.storageSize and dbStats.indexSize, this information is only useful in roughly determining the level of fragmentation within the MongoDB instance.
✒️What is not calculated
ObjectRocket fully manages MongoDB for you, including the pieces that create storage amplification like replication, journaling, namespace file, and ObjectRocket administrative databases. The following space calculations aren’t necessary:
- Oplog size (local)
- Journal size
- Namespace size
🖊️MONGODB 4.2 IS NOW AVAILABLE ON THE OBJECTROCKET PLATFORM-
We are happy to announce that MongoDB version 4.2 has passed our tests and is generally available on the ObjectRocket platform.
🖊️What’s New in MongoDB 4.2
You can get the full list of what is available in the MongoDB 4.2 release notes. Here are some of the updates and changes we wanted to highlight:-
Distributed multi-document transactions: In version 4.0, MongoDB introduced transactions on Replica-Sets only. MongoDB 4.2 expands multi-document transactions support to sharded clusters.
Mutable shard keys: Before MongoDB 4.2 the value of the shard key was immutable. With the enhancement of distributed transactions, shard keys value can now change. Just remember that you can only change the shard key value, not the shard key field(s).
You can read more about the changes related to sharded clusters here.
MongoDB 4.2 adds TLS options that are meant to replace SSL options (SSL is deprecated to 4.2). Additionally, client-side field level encryption is introduced that helps you to protect sensitive data. Read more on security improvements here.
Removes MMAPv1 storage engine
MongoDB 4.2 only supports WiredTiger storage engine. If you are still using MMAPv1 our support team can help you complete the transition to WiredTiger without service disruption. Simply open a ticket here and we will start working with you.
As with every major version, 4.2 fixes bugs that aren’t backported. Put simply, this means that some bugs affecting older versions are fixed in 4.2 but never backported for different reasons in previous versions, like 4.0 and 3.6.
Aggregation improvements: MongoDB 4.2 supports on-demand materialized views. Using the $merge operator allows users to save the aggregation output to a collection. $merge operator provides more flexibility compared to the $out operator and can help you enhance your security model.
Hybrid index builds: MongoDB removes the foreground/background index builds by introducing the hybrid index builds. Hybrid index builds don’t block database operations and at the same time, the build time is faster than a background index.
Wildcard Indexes: Wildcard indexes supporting queries against fields whose names are unknown or arbitrary. You can now index entire subdocuments without knowing their structure.
You can read more about the changes related to indexing and aggregation here.
📝Why Use MongoDB?
MongoDB is a document, NoSQL database that offers ease of implementation while combining performance, high availability, and automatic scaling. MongoDB, compared to MySQL, enables users to modernize existing relational workloads by addressing the requirements of new applications while supporting features like multi-document ACID transactions.
🖊️Benefits of ObjectRocket for MongoDB
As an extension of your team, we address the performance and scalability challenges posed by database architectures head on with unlimited access to MongoDB DBAs and Fanatical Support.
We monitor 254 metrics/min on every MongoDB instance, and are ready to take action if an alert is triggered.
🖊️24/7 Fanatical Support
by MongoDB Experts
Monitoring & Alerts
Resource Scaling & Management
Scaling & Query Analysis
MongoDB Schema Design
Architectural Consultation & Design
Production Level Database Audit
✒️ObjectRocket for MongoDB Features
Sharded and replica MongoDB instances are offered in 3 member replica sets for data redundancy and fault tolerance. Sharded instances consist of MongoS servers, config servers, and the shards themselves. All instances are capable of running the latest MongoDB version and enable SSL encryption connection along with an approved IP whitelist configured by the customer.
Our fully-managed MongoDB service supports applications hosted on Rackspace Cloud, AWS, Azure, and dedicated environments.
▶️Tools & Integrations
- API Access
- Restful API
- Slow Query Detection
- Automated Compaction
- New Relic Integration
- Profiling Limiter
▶️Custom and Advanced Configurations
- 3 Node Replica Sets
- Sharded Clusters
- Percona Server for Enterprise Workloads
- Single Database
▶️Security: RocketSecure Database Access
- Integrated Firewalls
- SSL Encryption
- Encryption for Data at Rest
- Audit Log Access
- LDAP Integration
- Delayed Replica Node
MongoDB versions 3.6, 4.0, and 4.2 instances in AWS and GCP are now available via our Private DBaaS offering. Rather than using shared infrastructure, Private DBaaS allows you to get a completely dedicated DBaaS cluster in almost any AWS or GCP region that you can use to host any and all of our hosted database services.