Most efficient way to expose semi-static information in Azure

Question

I am building a social game that needs to store status information about players, games, and boards on the server. The status information can easily be encoded in a byte array for efficiency and can be referenced by a single id (e.g., user id, game id). I anticipate many more reads than writes, and the writes don't have to be very efficient.

Using Windows Azure, I'd like to find the most efficient way to store and expose this information, where by efficient way I mean (in order of importance):

• quickest response time, and
• lowest operational costs.

My initial though is to use blob storage to expose these byte blobs (with a web role to update them when needed). But is the performance the best? Alternatively, I could store the status information in a SQL Azure database and expose it via Web API (constructing the response on the fly).

Are there any gotchas when accessing the blob information from an iOS device?

Answer 1

Your initial tought of using blob storage was a good starting point. Let's say you want to show some high scores in your application (assuming this is semi-static you talk about).

A Worker Role could calculate the top 100 users ever 4 hours and store this list in a blob (as a JSON string). Now you'll need to decide if the performance of blob storage is sufficient for your app? Take a look at the scalability targets:

• Up to 60 MBytes/sec for a single blob
• Transactions: Up to 5,000 entities/messages/blobs per second (per storage account)

The transaction limit could be the bottleneck if you have a massive amount of users. In that case you can increase the performance by using the CDN. With the CDN, your content will be replicated on CDN nodes in 24 countries. This means your end user will download the blob from a nodes that is judged as "closer"/faster independent of the datacenter where your application is being hosted and you won't be limited to the scalability targets menitoned previously.

You also need to take into account that there might be scenarios where you want to referesh this semi-static data (maybe each time a user finished a game), without having to do this in real-time (you don't want to block the user if this is a long running process). Such scenarios can easily be addressed using Queues, Topics, and Subscriptions. This allows you drop a message in a queue (or a topic) when the user finished a game, and have one or more background 'workers' (possibly on an other role/VM/...) processing the message.

Answer 2

With the information given, I think blob storage would be more likely to meet both of your requirements, even more so if you have a large and dispersed audience. Since latency seems like it would be an issue, using SQL Azure could require deployment to multiple data centers to support a 'global audience,' and then you'd need to pull in some sort of data synchronization layer as well across the instances.

With blob storage, storage costs are definitely cheaper per byte AND you can leverage the CDN for an additional (but still manageable) cost to get reduce latency for that global audience. It doesn't sound like you need the relational power of SQL Azure anyway.

As mentioned in my comment above, keep tabs on Windows Azure Mobile Services. It may not meet your needs today, but additional platform support has been announced, and using the services - currently from Windows 8 - is incredibly straightforward. It does, by the way, use SQL Azure as the back end, which is a cost consideration (although the service itself, in preview mode, is free). For what it's worth, I did find this blog on using Windows Azure Mobile Services with iOS - as you might expect with open standards and interfaces, anything is possible :)

Answer 3

Personally I'm a huge fan of caching semi-static content in Windows Azure Cloud Service's "local storage" area. When a request comes in, if you already have the file you can just return a file-stream reference to it back to the requestor. This approach prevents you from exposing your blob storage account directly to a consuming client, and also helps reduce any transaction costs. There's also the potential upside of allowing the service you have that processes the request to introduct any business logic into the stream, such as ACS style behavior.

Of course this does come with trade-offs as you then need to manage the cache and the bandwidth available to your cloud service now has to help serve up the request responses instead of just letting Windows Azure Storage do it for you.