Gartner Blog Network

The Importance of Named Keys

by Raj Bala  |  March 14, 2016  |  2 Comments

I’ve been thinking about a subtle feature of Amazon S3 and other object storage platforms:  user-named keys.  Objects are stored and retrieved by names that are assigned either by a user or an application.  Here’s an example of how this works:

  1. A user uploads a document through a web application.
  2. The application generates a name for that document and stores it as an object in an object storage platform.  The name for the object need not be persisted because the name is programmatically generated perhaps based on existing information.
  3. Another user needs to retrieve that document.
  4. The application makes a request to the object storage platform to retrieve the object with a specific named key.  The application knows the name of the object’s key because it’s programmatically generated whenever it needs to be accessed.
  5. The user gets their document.

In the context of an application, this allows names for objects to be automatically generated at run time without needing to be explicitly persisted.  Perhaps the name of the object is the unique primary key (or some other combination of naming) used for that record in the web application’s database that manages the documents.

In contrast, there are object storage platforms that do not support named keys.  These object storage platforms return object IDs when objects are created.  Here’s an example of how this might work:

  1. A user uploads a document through a web application.
  2. The application stores it as an object in an object storage platform that generates an object ID and returns it’s back in the response.
  3. The application needs to persist this object ID in order to retrieve it later, so it’s added to the record in the application’s database that’s used to manage documents.
  4. Another user needs to retrieve that document.
  5. The application makes a request to the object storage platform by object ID.
  6. The user gets their document.

The operation in step 3 where the object ID is persisted is required in the second scenario because the name of the object is not generated by the application — it’s generated by the object storage server.  Without the object’s key there may be no way to subsequently retrieve the object particularly if there’s no way to enumerate objects.

Two side effects of only supporting server-generated object IDs:

  1. Application servers need to persist a proprietary object ID which can lead to a subtle, but meaningful form of lock-in.
  2. The failure scenarios and complexities of mobile application architectures will increase because of a need further interaction with an application server in the process of creating data.

The result:  prefer object storage platforms that support named keys!

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research


Raj Bala
Research Director
5 years at Gartner
20 years IT Industry

Raj Bala is a Research Director at Gartner covering cloud infrastructure and platform services. Read Full Bio

Thoughts on The Importance of Named Keys

  1. Nice article. I might add that even when using named keys for writing objects, reading them back using object ID’s can provide a significant performance boost. Reading with named keys adds an extra object ID lookup operation on the backend storage service. In a shared storage environment with lots of objects, an object ID lookup operation can be costly. A storage service that allows both named key writes and object ID reads should be considered in that case.

    • Raj Bala says:

      There are many factors and each object storage platform may handle this differently, but generally the trade-offs of using named-keys are worth any potential minor performance impact of object lookup.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.