Warning alert:We're building our new website - with more examples, tips and docs! Some sections though might still be incomplete or under review. When browsing, keep an eye for progress notes and ways to get updated on particular topics.
Tiered Resource Usage
Info alert:Note
While the features below are supported on Microsoft Azure, you might need a custom deployment to actually turn them on.
Microsoft Azure offers its Compute resources in different configurations. For example, disks can be slower or faster, instance configuration can include more CPU cores, or less RAM. The cost of using Compute resources differs depending on these parameters - slower disks are cheaper than faster disks, etc.
With mishmash io you can take advantage of different Compute offers and control your running costs.
Combine slow and fast disks, more powerful instances with less powerful ones in the same cluster, and then arrange them in tiers. Apps with lower requirements will automatically use resources in lower tier.
Disk tiers
You can configure mishmash io to store data in different disk tiers per app, or
by using parameters like access frequency. For example, if an app has a lot of
old, historical data that is not accessed as often as fresh data - it might better
if you arrange its data by access frequncy.
CPU and RAM tiers
Disks of all tiers can be assigned to one a same instance type, in a 'single tier' CPU or RAM configuration - effectively sharing the same computing power across different data tiers.
But you can also set CPU and RAM resources to 'match' disk tiers - assigning
fewer CPU cores to lower tier data.
Default alert:Limit each tier
You can go further by also configuring the autoscaling per tier: effectively limiting the maximum resources a tier can use at any time.
Default alert:Get the right limits
Use mishmash io metrics to understand exactly how much resources you need and how that need changes over time - then optimize your tiers accordingly.
Node role tiers
As a distributed database mishmash io runs various internal processes, for example - doing data computations to answer app requests and coordinating a distributed computation.
These processes are typically running on the same nodes, sharing the same CPU cores and memory. But they can also be separated - to dedicate more CPU/RAM to say, answering requests and take out the coordinating role to less powerful instances.
On a small mishmash io cluster there's little difference between the needs of its internal roles (or processes), but on a large one these differences can become significant.
In such scenarios you can arrange Compute resources in tiers depending on roles assigned.
Default alert:Learn more
To learn more about mishmash io internals check out the architecture document.