Dave Graham's Blog

With the advent of Cloud Computing and the general resurgence of computing grids, data storage has been taken for granted. However, as cloud computing’s storage and access demands continue to grow, the need for an optimized storage layer and hardware accompaniment become even more critical.

The general focus has been on computational power, integration points via software (API access, for example), and code portability.  Storage, on the other hand, was considered a commodity to be taken advantage of; a simple pool of storage for whatever data needed some level of retention and access.  However, as cloud computing’s storage and access demands continue to grow, the need for an optimized storage layer and hardware accompaniment become even more critical.

In this series of articles (which represent a paper I am writing), I will attempt to examine key areas where a Cloud Optimized Storage Solution (referred to as COSS through the remainder of this document) can both bolster the general availability of the cloud at large and concurrently provide appropriate performance for the cloud application set based on Service Level Agreements (SLAs).  As part of this examination, I will look at the following key areas:  the type of content being stored and how it is being allocated to storage, the expected performance “tiers” or metrics associated with performance, SLA types and examples, COSS hardware performance, the interoperability and portability of the COSS solution, compliance and authentication characteristics for storage, and the integration of environmental considerations in the design (i.e. “green” computing). Further, I will also attempt to introduce the concept of neural networking as an integration model for COSS. In order to enhance the understanding of each of these categories, I will include visuals where appropriate as well as tabular data explanations for consideration.

Part 1: What Content is being stored on COSS?

Data within the global Cloud is considered to be of two distinct varieties: structured and unstructured. Structured data is best defined as: “data that ha(s) been represented in a manner that allows computation with those data .” Structured data includes (but is not limited to) meta-data, XML/XHTML, database frameworks and underlying structures, and email (some).  Structured data is therefore “information that has been organised to allow identification and separation of the context of the information from its content .”  Unstructured data, on the other hand, is best defined as: “Data that is not in tabular or delimited format ” or “Data which is not structured such as free-text . The computer cannot automatically extract properties and relationships… ”  Unstructured data, in praxis, refers to content such as audio, video, graphic images, email (some), documents (some), and some variations of XHTML (not tagged).

Each type of content, whether it be structured or unstructured,  has different influencing factors affecting its storage and retrieval.  For example, unstructured data, like audio or video, typically has some method of compression applied to it (MP3, AAC, WMV, MP4, etc) that limits the actions that can be applied to them by storage systems or host-level software. Conversely,  structured data can contain high levels of commonality which influence the ability to provide de-duplication level services.  In either case, how this content can be managed is a function of both its inherent nature as well as how it is being stored.

[This appeared originally here and is republished in full by kind permission of the author, who retains copyright.]