Caching vs Tiering



Accelerating IO Saving money by moving cold data to cheap storage
Easy to implement Need efficient tiering algorithms
Unless latency sensitivity of application is well understood, spending money on expensive SSD hurts. Unless the data access patterns are well understood or deterministic, data distribution across tiers will not be optimal, hurting performance and wasting expensive drives
Real-time workload adjustments, random I/O, transactional applications, and server and desktop virtualisation. Images, emails
Size exposed to user is the size of  back-end Size exposed to user is a aggregation of all tiers.
There is a possibility that old data sits in back-end (HDD – cold)and new data in front-end (SSD – hot). Multiple copies possible. At any given time data sits in one of these tiers (Archive, HDD, SSD). Only one copy.
Does not have picture of storage tiers. Just pushes the data from cache device to backend devices. If the backend storage has uniform speed and does not have notion of storage tiers, we can use this. SSD tier should be large enough to support both incoming writes as well as hot data. SSD provisioning should be decided based on workloads. Need to have understanding of number of tiers and their importance w.r.t workloads and data.
Mostly within the box. Either nearer to app or backend storage. We can manage more than one layer of storage. SSD-HighspeedHDD-CapacityHDDs
In case of write-through or write-around caches (improving reads), we can drop the data. No data movement is needed. Data movement across boxes is considered. Creates lot of data movement. ping pong effect.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s