Feature

Storage Bin: It's time to change the way you think about data

Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Surprise winner: BlueArc earns top NAS quality award honors."

Download it now to read this article plus other related content.


Once you realize that not all data is transactional, you can begin to manage it more intelligently.


Last month I explained my theory of why we're so screwed up infrastructure-wise or at least how we got to this point. This month I'll try to show you the way out of the situation.

For a few minutes, forget everything you know or at least everything you think you know. Accept my argument that almost everything we've done in commercial IT has been based on transactional requirements. Open your mind.

There are two distinct types of data: dynamic and persistent. Dynamic data is in flux; this is where transactional data begins. Persistent data is fixed. It's what it is and will never be anything else.

Just because data is dynamic doesn't mean it starts and dies within an RDBMS. Structured database data starts as dynamic, but at some point it becomes a nonchanging record. It's persistent. You may have reasons to keep it inside a database forever (although I doubt they're valid ones), but those records are still persistent; they are what they are.

Here are a few rules that will help you:

Rule 1: Don't confuse how something begins its life with how it will end. Everything begins dynamic and ends persistent. Stop delineating between structured, unstructured and semistructured. All types live dynamically for some period, whether it's a Word document, a movie, a credit card transaction or an email. It all ends

Requires Free Membership to View

up as fixed digital content.

Rule 2: The attributes and requirements for each type of data are different. Read/write performance, throughput, redundancy, DR, etc., count more in the dynamic phase of data life; however, we've extended all of those philosophies to data that has stopped changing. Building data redundancies and protection schemas to handle real money transactions is good business; backing up a nonchanging data element a thousand times isn't. Having your bulletproof transaction system capable of handling all the dynamic money events thrown at it is good business. But adding processing power, capacity, network infrastructure, etc., to keep it churning away rather than removing the 90% of the data that isn't dynamic and can interfere with the real transactional stuff isn't.

This was first published in June 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: