1. RavenDB
2. Sql Azure
3. Azure Storage

Azure Storage

Microsoft proposes Azure Storage as the most scalable solution if you want to store data in the cloud. If you think of Windows Azure as an operating system for the cloud then Azure Storage is the supporting filesystem for it. It consist of three major parts: Tables, Queues and Blobs.

Azure Blobs are unstructured binary data just like files on a filesystem. You can  store some additional metadata and you can control whether they are publicly available or protected.

Azure Queues is a persistent Queue implementation. It gives you an async and decoupled way to comunicate between components of your distributed application.

Azure Tables is some kind of low level SQL table. In comparison to a real SQL table there are some limititions. Each table has only a partition key and a row key for efficient access. These two keys form a row identifier. There is no equivalent to a non-clustered index so querying with conditions which do not contain these two key columns are always expensive in terms of time. The flipside of this coin is very high scalability. An Azure Table is not limited in size and may span over several nodes.

Azure Storage is hosted for you so you do not have to worry about installing, configuring, managing, backups and scaling. All these points made me decline RavenDB as the candidate number one in the first article of this series.

It has some small limitations which I would consider a guideline for a correct usage of the services. The overall amount of data is not limited.

Azure Storage pricing

Azure Storage is not free (as well), but it costs much less than SQL Azure. Think of 10-times less depending on your usage behaviour! Azure storage costs you 0,106 € / GB and you also have to pay for every transaction on the storage. One million transactions cost you additional 0,71€.

Azure Storage for my project?

I will use Azure Storage in all its flavors in my project. Why, you ask? It is the solution I have the least experience with but I have the desire to change this! It will also save money in the long run.

Because of the lack of the experience, I am not that sure, how well queries will work if they contain only the partition key but not the row key. This could become a performance killer. I was thinking about this for a longer time. I will wait for this to show up as a real bottleneck.

If performance really becomes critical then caching is my first choice here. If this is not going to work good enough I will implement secondary tables as some kind of persisted views on the data. This introduces more complexity in the data access but it will be the way to (re-)gain performance at the cost of some extra storage.

Source of the used Azure Icons

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

While I was considering RavenDB as an actual choice for my project I was stumbling about the bad performance on big (1-5 MB) blobs. Shortly after I learned about attachments in RavenDB which are designed for exactly this case except it is not possible to include them in transactions. This is fine for me anyway.

Sql Azure

The next best choice is Sql Azure. It feels like having a SQL Server in the cloud with all its pros and cons. I have quite good knowledge in designing and using relational databases and especially storing blobs in them. But this is no NoSql at all

Some whitepapers suggest to use XML document columns to store schema-less documents inside SQL Azure to simulate a NoSql database. While technically possible I cannot imagine someone really doing this.

Sql Azure is not free as well. You don’t pay for licences but you pay for the size of your database. It costs about 7€ per month and GB. This is too much for me to use it to store my blobs and as of now I have no idea how much metadata I need to store to run my service.

My decision

Sql Azure could fulfil all my needs. I could store the blobs inside Azure Blob Service to reduce the database size and to use the tools in the way they work best. But I will not use Sql Azure. Why? I am quite sure that Sql Azure is much more capable of scaling than my application would need it. It basically comes down to my desire to learn something new and to design the service in the way it fits best into the cloud.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Requirements

Because of my .Net background I am going to use Windows Azure anyway.
Furthermore I want to have an architecture which is scalable as much as possible. The application should be able to run on only one extra small instance and should be able to scale using many instances in a seamless and efficient ways.

RavenDB as a solution

I am following Ayende for quite a long time now and I appreciate his skills and knowledge. He made me start diving into the NoSql-Space some time ago with his document database RavenDB. I am quite impressed by it. I was thinking about using it for my service but there are some issues:

• RavenDB is not free. It’s available under the AGPL license but I am not going to release the source of my own stuff so this is not an option. I have some money available and Ayende offers free licenses to startup companies as well so I basically could go for it nevertheless.
• RavenDB uses the local filesystem as the underlying storage. Is this possible on Azure? Yes of course. The feature is called Windows Azure Drive. The compute instance gets a simulated local drive which is stored in the Azure Blob Storage. This is somehow great if you want to run some legacy stuff in the cloud but it feels like a huge crook doing this to run a software which is designed with Azure in mind.

Think about scaling: RavenDB is able to shard and replicate but do you really want to setup another instance of RavenDB and Azure Drive just to scale up?
Scaling down is even worse: You would either need a way to run both Raven-Instances on a single compute instance or you would need to copy the data to free one instance of RavenDB completely. I simply want to change the number of instances in the Azure configuration and it should “just work”.

Solutions?

Is running a database product on top of Azure compute instances a great idea at all? Particularly the last part about scaling leaves the opinion in my head that this is not what I want to deal with.

Should Ayende implement Azure Blob Storage as a supported underlying storage system for RavenDB? Probably not. You would still have the burden to setup and configure RavenDB instances.

My decision

It is a somewhat hard decision because I really like RavenDB but I think I will not use it.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Nur verstehen die Cloud Computing nicht bzw. ganz anders als ich das tue. Für mich gilt:

Cloud Computing = Amazon EC2&S3 + Google AppEngine + Windows Azure;

Während des kompletten Podcasts (fast 2h!) werden diese 3 Dienste aber nicht einmal erwähnt, was für mich eindeutig als Thema verfehlt gewertet wird! Schade und dabei mag ich /Dev/Radio eigentlich.

Cloud Computing ist doch gerade der Trend,

• diese ganzen hardwarenahen Geschichten (Security, Load Balancing, Netzwerkkonfiguration, Backups, …) an Dienstleister abzugeben,
• nur noch dafür zu zahlen, was mach auch wirklich nutzt und
• im Zweifelsfall auch mal mehr Power nehmen kann, als man mit eigenen Servern hätte haben können. (Scale-Out durch zusätzliche Server per Mausklick)

Stattdessen gehen die beiden auf Themen wie Peer-to-Peer-Computing (kein Filesharing!), MapReduce und Grid Computing ein. Diese Aspekte sind sicher genauso interessant, sollten aber in der Themenstellung “Cloud Computing” höchstens eine Nebenrolle spielen.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)

Supported Operating Systems: Windows Server 2008; Windows Vista Service Pack 1

Dummerweise nutzen unsere Arbeits-PCs noch XP und ein Image vom 08er Server konnte ich so schnell auch nicht auftreiben.

---
Unterstütze mich und meinen Blog und kauf dir was Nettes (über diesen Link)