Every company wants to leverage the cloud for the agility it provides. Running in the cloud can also provide significant cost savings – but not always. That’s because when you’re running large workloads in the cloud, they’re not predictable. That leaves you with the option to over-provision query capacity to handle spikes in demand, or to provision for the average and risk disappointing customers during those black Friday events.
Your best option? The MarkLogic Query Service. It provides immediate query capacity to handle spikes in demand. When demand slows, you simply remove that extra capacity. You just have to define what capacity to start with and what spikes will be expected. The service keeps a close watch on your system and adds or removes capacity as needed. It’s automatic, all provisioned, and all handled by the service running in AWS. Scale away!
The cloud is great because you can spin up a server when you need it, and get rid of it when you don’t. But, database provisioning isn’t that simple. You can’t just get rid of your data when you want to.
Data and databases aren’t stateless. To add query capacity and expand a cluster, you have to deal with migrating data, re-partitioning, re-balancing, and more. You don’t have time to deal with all that while handling spikes in demand. With most databases, you’re forced to guess, in advance, what demand might look like and when you do add capacity – it’s there to stay. And you hope it doesn’t blow through your budget.
We take a different approach so you don’t have to deal with these costly and risky scaling problems.
The MarkLogic Query Service takes advantage of our unique architecture to handle the spikes in demand. MarkLogic has E-Nodes (Evaluator Nodes) to process queries and D-Nodes (Data Manager Nodes) for data storage and retrieval, including things like journaling, data recovery, backup operations, and other on-disk data management.
This unique separation means that it is easy to add or remove E-Nodes as needed for additional query capacity, without having to worry about provisioning D-Nodes. Other databases don’t have this unique separation which makes them slow down as they work through re-balancing and re-partitioning as they scale.
The MarkLogic Query Service automatically adds and removes E-Nodes to handle reads. It’s all provisioned and all managed by the application. The database cluster with the D-Nodes where the data itself resides is still managed by the customer. Initially, the Query Service reacts to resource needs by adding E-Nodes to handle spikes. But, over-time it becomes predictive to handle expected spikes in demand.
For example, when releasing a novel API to end-users that may drive significant adoption or there is an application that may have a major spike (promotions, social-media events).
For example, publishing important, highly consumed content every morning at 10:00 AM or a customer 360 app that is heavily accessed every afternoon.
For example, a reporting application that should be isolated from a transactional application for performance reasons.