Native Apps At The Client & Cloud

Srinivasan Sundara Rajan

Subscribe to Srinivasan Sundara Rajan: eMailAlertsEmail Alerts
Get Srinivasan Sundara Rajan: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Cloud Database Design, Scale Out Using Shared Nothing Pattern

Virtual storage and database partitions

Abstraction Vs Flexbility :
It is evident that storage plays a major part in the data center and for cloud services. The storage virtualization plays a key part in the dynamic infrastructure attribute of Cloud Computing. Which means the storage is provisioned and de-allocated on demand and usage needs. The good part is that this complex stuff is hidden from the cloud consumer.

However while the storage allocation is abstracted it also brings in performance concerns in a multi tenant cloud environment where by most of the cloud consumers are geographically dispersed and a good amount of data retrieval and manipulation at stake.

Currently most cloud storage virtualization platforms rely on the hardware options like fiber channel, Ethernet switch, network attached storage (NAS) and iSCSI as the implementation medium.

Currently Cloud platforms have very little support for database design related virtualization enhancements. But in future designing databases specific for Cloud especially for private clouds in large enterprises is a sure possibility. In this context the following design principles are important when you design database applications which needs to be delivered using Cloud platform.

Shared Nothing Vs Shared Every Thing
Shared resource and shared nothing represent forms of data access architectures. In a shared (every thing) resource model various processes in the DBMS have access to all system resources, including the data. In the shared-nothing environment, separate DBMS resources divide up the workload, rach responsible for its own data, memory locations, and other resources.

Most popular databases support a shared-nothing model using different strategies. For example,

  • Oracle : Utilizes Range & Hash portioning of tables towards shared nothing . Here it is a table and table space level segregation of data based either on range of key values or a hashing algorithm. (note : Oracle Real Application clusters at the instance level adopt a Shared Every Thing Model)
  • DB2 UDB follows a shared nothing model. Data is partitioned according to a partition key. Rows are assigned to a partition, and each partition has total control of that row. If another partition wants to read or update a row, it must send the request to the owning partition. The owning partition then executes the command on behalf of the requestor.
  • Sql Server : Utilizes Distributed Partitioned views to implement Shared nothing architecture.

Shared nothing model greatly simplifies things like resource contention, including memory, locks and processors . Implemented properly , it offers unlimited scalability. As new rows or data sources are added, more partitions can be added. The workload on any individual partition remains the same.

Storage Virtualization & Shared Nothing Meet Each Other

While the dynamic infrastructure tenant of cloud computing is satisfied by the current classic model as seen in the picture , but the load balancing and scalability needs are fully satisfied by hardware at this time. However implementing the shared nothing data access architecture with a proper access key will highly improve the scalability and performance of cloud databases which in turn increases the QoS of the Cloud platform and make the XaaS a real success providing the best of cost efficiency and improved performance.

View Of a Shared Nothing Cloud Database

As evident implementing a Shared Nothing Cloud Database Model does not replace Storage Virtualization, but compliments the scalability further by splitting the data within multiple virtual storage drives. As seen in the diagram,

Load balancing algorithms implemented at the shared nothing cloud databases further augment the Load balancing options provided by the Cloud Platform.

Shared Nothing Cloud Database Design Considerations

  • Implement Hashing or Ranging Keys as part of the tables which logically separate the data based on the Cloud platform needs. For example if in a SaaS platform multi tenancy is the need then having the CUSTOMER ID or CUSTOMER KEY as a Hashing key for the shared nothing cloud databases
  • Increase the scalability further by implementing a Geography or Time based partition which scales up well depending on the situations
  • Ensure that the queries utilize the logical partitions established as part of the shared nothing architecture. For example if you can query a customer by SSN in a cloud database which has implemented a shared nothing architecture using Geography, then utilize the geography also part of the query filter conditions
  • Have an option to rebalance the data within the virtualized storage if they started becoming skewed due to the way the hashing algorithm is built in

What is expected from Cloud Platform Providers & Database Vendors

  • Expecting the database vendors provide shared nothing algorithms tailored for virtual storage, especially on the rebalancing based on the disk usage
  • New cloud aware partitioning techniques
  • Complimenting load balancing algorithm to augment what is currently available at the hardware
  • Ability to PIN SQLs to a virtual machine based on dynamically queried resource usage

Over all Private Clouds at Enterprise need to satisfy still more SLA or QoS as part of their service and full support from database engines is key to the success. Share Nothing Architecture is one important thing to achieve these non functional needs of the Cloud Platform.

More Stories By Srinivasan Sundara Rajan

Highly passionate about utilizing Digital Technologies to enable next generation enterprise. Believes in enterprise transformation through the Natives (Cloud Native & Mobile Native).