Feeds

back to article Object storage: The blob creeping from niche to mainstream

Storage dull? Dry? Uninteresting? Not a bit. Everybody and everything uses data storage. Without we'd be lost. And thanks in part to the growth of cloud computing and big data, storage has risen up the agenda. In the big data universe, things are changing. Our methods of naming, storing and retrieving filesystems need to be …

COMMENTS

This topic is closed for new posts.
Silver badge
Stop

"the guesswork of capacity planning is eliminated"

Any time I hear someone telling me that planning is no longer necessary, I cringe.

Here, we are being told that we no longer have to worry about a single application taking up 80% of the shared storage space.

I beg to differ. If a single application takes up 80% of my allocated storage, I think I'd pretty damn well better know why and have planned for it beforehand, because if this is a surprise, then it puts in question the whole data structure that I have put in place.

Sure, I understand that all I have to do is subscribe to an additional block of shared storage. That doesn't mean that I shouldn't have planned it beforehand.

Planning is never an option.

2
0
Anonymous Coward

Re: "the guesswork of capacity planning is eliminated"

I can see you missed the point of this.

When the storage pool is 80% full, your ex-boss will get a friendly call from EMC/IBM/HP/HDS* quoting him for more capacity, and he'll have all the money he used to pay you to buy it with.

* Delete as applicable

0
1
Silver badge

Re: "the guesswork of capacity planning is eliminated"

> I can see you missed the point of

Adding more capacity on a whim? From the likes of EMC? For only the cost of a single employee?

Surely you've never actually had any experience with this sort of thing.

1
0
Alert

Object: It's not just about storing stuff...

Interesting piece, Adrian. Good to see more discussion relative to the object technology space...finally. Just wanted to mention a feature I didn't see in the article, and in my opinion, one of object's most valuable, its capabilities in providing a foundation for information management. So much potential with this, but the architecture has to be right and you're correct that the products on the market today differ quite a bit in architecture. Having spent over 15 years in this space I've evaluated/competed with all of them and there's tremendous opportunity to really disrupt the storage industry; primarily file systems with that "right architecture".

Object won't obviate the need for file systems, but will substantially impact their use. As the advanced computing team from a major US university said during an executive briefing last year "...the file system has pretty much reached the end of its useful life", but also recognized it would continue to occupy a place in the environment (though much smaller in size). We'll also see object adoption move faster when SW engineers really begin to recognize what they can do with object and start using it as a development platform to deliver apps. Good to see Ms. Collier is in agreement on this point (worked with her in the past, Hi Lynn!).

The new paradigm of storing and interacting with information has emerged from the community networks and content sharing sites (Facebook, LinkedIn, Shutterfly, etc.) that rely on relationships, links, associations and "likes" (tags/metadata) where those relationships hold as much, if not more value than the actual content. The new generation of consumers, corporate users and technologists understand this paradigm far more than the stodgy, block-based, folder/file hierarchical technology of yester-year. Object technology provides an infrastructure that can persist and protect that data while enabling the creative "bit twiddlers" to take advantage of it in unique and exciting ways.

2
0
Silver badge

Re: Object: It's not just about storing stuff...

Anything that displaces the conventional file system is likely to require that same displaced file system under the covers. It may be invisible, embedded in some highly proprietary storage layer. However, sooner or later something is going to have to address it in conventional terms. That might even be the end user or admin. Less abstract elements of systems don't suddenly go away when a better abstraction is found.

A file name (or something like it) will likely continue to remain the most efficient path to an object regardless.

1
0
Meh

Re: Object: It's not just about storing stuff...

Yes and no to the "still need a filesystem under the covers". You can pretty much chop the directory tree off a traditional UNIX filesystem and use inode numbers as object IDs. For instance, the Object Storage Targets inside Lustre can be mounted locally on the storage servers for maintenance when the cluster filesystem is down, and what you then see is a placeholder filename for each inode in use, hashed into a containing directory tree to keep the directory sizes manageable. When the cluster filesystem is mounted, most operations refer directly to the inodes - it's only when a new object is created that its placeholder filename has to be added too.

As for efficiency: if you expose inode numbers to the filesystem layer, bypassing the directory tree and addressing inodes directory is certainly no *slower*...

1
0

Re: Object: It's not just about storing stuff...

@ZEN

Have you seen what we are developing by any chance?

0
0
Anonymous Coward

Re: Object: It's not just about storing stuff...

A file name (or something like it) will likely continue to remain the most efficient path to an object regardless.

Thank you, it's nice to read a comment which is written by someone who understands storage. Maybe next time you can ask them a searching question about it as well, something about how they intend to maintain block pointers without a filesystem type of structure, and therefore make optimal use of the underlying storage technology?

0
0
Anonymous Coward

Re: Object: It's not just about storing stuff...

....

As for efficiency: if you expose inode numbers to the filesystem layer, bypassing the directory tree and addressing inodes directory is certainly no *slower*...

Ummm I hate to have to point this out... but the inodes are the fucking filesystem. The directory tree is only a dictionary of inode assignment. So your object storage model is a filesystem without an inode dictionary.

0
0
Anonymous Coward

Ceph? Eucalyptus? GlusterFS?

Why mention OpenStack Swift but none of the alternatives?

0
0
Anonymous Coward

Techy Buzzword Generator

"each unit benefits from an extended metadata identifier"

"the desire for information quality is driving data ingest ‘granularity’"

"his firm’s Simpana 10 product exists in this space as a hardware-agnostic software storage solution"

"we can intelligently expose data for more use cases through API integration"

"service-based virtualised computing architectures"

0
0
Anonymous Coward

Centera is still the best object platform

Centera was one of the first and is still the best. That is why almost every financial institution and thousands of health care and other companies have it. EMC tried to replace it but it it is so sticky because customers love it and it just keeps selling. Long live Object. Long live Centera.

0
0
This topic is closed for new posts.