What are SSDs? Enterprise Solid State Disks (SSDs) are built using NAND flash technology. Even with new developments such as 3 bit-per-cell (3bpc), their price-point will remain a significant premium compared to traditional HDDs (in terms of $/GB). Comparing $/IOPS, SSDs are at-par or better compared to HDDs. Keep in mind, its the read performance (write are much slower). Also, the writes need to be uniformly distributed (referred to as "wear leveling") to improve the longevity of the drive.
How are vendors positioning it? The mantra for storage controller vendors has been auto-tiering of data between pools of SSDs and HDDs within the controller. The data is moved between the pools in an automated fashion by tracking the IO access characteristics. The end goal is to deliver better performance by keeping the "hot" read dominated data in the SSDs (think of it as an extended cache). The IBM product for auto-tiering is called "EasyTier," while EMC has as more fancy acronym FAST (Fully Automated Storage Tiering).
So, whats the Scale-up and Scale-out dilemma? Lets first try to answer the question of justifying ROI your SSD investment. Consider an enterprise running an Online Transaction Processing (OLTP) workload where the database needs to respond near real-time by scanning millions/billions of entries. For the sake of a concrete discussion, consider the example of scanning the details of all passengers flying through a airport. The database needs to join information across multiple tables with billions of entries and give the query results in a few seconds. This can be accomplished in two ways:
Option 1: A conventional relational database query. The underlying storage layer needs to be extremely fast to serve the IO requests. Yes, you guessed it correctly. A storage controller with SSDs might be the solution for such applications and use-cases. This is the scale-up option where you beef up your infrastructure
Option 2: A Map-Reduce approach across commodity hardware. Facebook being a great example. Using Hadoop with SQL query interface (referred to as Hive), they analyze billions of log entries (6.2 PB of storage) for advertising analytics, usage patterns, etc. Map-reduce partitions the work across multiple compute nodes accessing commodity storage through a parallel file-system (HDFS). This is the scale-out paradigm. To put things in perspective, scale-out does not imply commodity storage. In fact, storage vendors support scale out products in the form of block-level virtualization (e.g., IBM's SAN Volume Controller) as well as file-based (Scale Out NAS or Parallel File Systems).
Take-away:
How are vendors positioning it? The mantra for storage controller vendors has been auto-tiering of data between pools of SSDs and HDDs within the controller. The data is moved between the pools in an automated fashion by tracking the IO access characteristics. The end goal is to deliver better performance by keeping the "hot" read dominated data in the SSDs (think of it as an extended cache). The IBM product for auto-tiering is called "EasyTier," while EMC has as more fancy acronym FAST (Fully Automated Storage Tiering).
So, whats the Scale-up and Scale-out dilemma? Lets first try to answer the question of justifying ROI your SSD investment. Consider an enterprise running an Online Transaction Processing (OLTP) workload where the database needs to respond near real-time by scanning millions/billions of entries. For the sake of a concrete discussion, consider the example of scanning the details of all passengers flying through a airport. The database needs to join information across multiple tables with billions of entries and give the query results in a few seconds. This can be accomplished in two ways:
Option 1: A conventional relational database query. The underlying storage layer needs to be extremely fast to serve the IO requests. Yes, you guessed it correctly. A storage controller with SSDs might be the solution for such applications and use-cases. This is the scale-up option where you beef up your infrastructure
Option 2: A Map-Reduce approach across commodity hardware. Facebook being a great example. Using Hadoop with SQL query interface (referred to as Hive), they analyze billions of log entries (6.2 PB of storage) for advertising analytics, usage patterns, etc. Map-reduce partitions the work across multiple compute nodes accessing commodity storage through a parallel file-system (HDFS). This is the scale-out paradigm. To put things in perspective, scale-out does not imply commodity storage. In fact, storage vendors support scale out products in the form of block-level virtualization (e.g., IBM's SAN Volume Controller) as well as file-based (Scale Out NAS or Parallel File Systems).
Take-away:
- Understanding your workload is critical!
- Classify your storage requirement as latency-sensitive, IOPS hungry, or explosive capacity.
- If you are indeed latency-sensitive, understand your data footprint and how fast it is growing. The Scale-up approach is preferred since its least disruptive, but if you are experiencing explosive data growth, a paradigm shift with smaller storage blocks is the way to go!
No comments:
Post a Comment