Microsoft Azure DocumentDB vs Azure Table Storage

Question

For several recent years, Microsoft offers a "NoSQL" key/value storage, called "Table Storage" (http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-tables/)

Table Storage offers a high performance, scalability (via partitioning) and relatively low cost. A primary drawback of Tables that only Partition and Row keys can be indexed - so making queries on values is very inefficient.

Recently Microsoft announced a new "NoSQL" service, called "DocumentDB" (http://azure.microsoft.com/en-us/documentation/services/documentdb/)

Instead of storing a list of properties (like Tables do), DocumentDB stores JSON objects. The whole object being indexed - so efficient queries may be created based on every property and any nested property of stored objects.

Microsoft says that DocumentDB provides high performance and scalability as well.

If that's so - why anyone would use Table Storage over DocumentDB? It sounds like DocumentDB provides the same functionality as Tables, but with additional capabilities such as the ability to index anything.

I will glad if someone could make a comparison between DocumentDB and Table Storage, highlighting cons and pros of each one.

Solution 1

Both are NoSQL technologies, but they are massively different. Azure Tables is a simple Key/Value store and does not support complex functionality like complex queries (most of them will require a full partition/table scan anyway, which will kill your performance and your cost savings), custom indexing (indexing is based on PartitionKey and RowKey only, you currently can't index on any other entity property and searching for anything other than PartitionKey/RowKey combination will require a partition/table scan), or stored procedures. You also can't batch read requests for multiple entities (through batch write requests are supported if all the entities belong to the same partition). For a real-life application of Azure Tables, see HERE.

If your data needs (particularly around querying them) are simple (like in the example above), then Azure Tables provide what you need, you might end up using that in favor of DocDB due to pricing, performance and storage capacity. For example, Azure Tables performance target is 20.000 operations per second. Trying to get that same level of performance on DocDB will have a significantly higher service cost for you. Also, Azure tables are limited by the capacity of your Azure storage account (500TB), whereas DocDB storage is limited by the capacity units you buy.

Solution 2

Table Services is mainly a key-value type NOSQL and DocumentDB is (as the name suggests) a Document Type NoSQL store. What you are asking is essentially the difference between these two types of NOSQL approaches. If you shape your research according to this you should be able to get a better understanding for sure.

Just to keep things simple I suggest you consider the differences between how DocumentDB and Table Services are priced. Not only the cost of these services vary a lot from each other but the fact that DocumentDB works on a "provision first" model and Table Services are offered on a pure consumption based pricing might give you some clues on your compare/contrast.

Let me ask you this; why would I use DocumentDB if the features in Table Services well serve my needs? ;) I suggest you to take a look at how the current Azure Diagnostics tooling use Azure Storage Services, how Storage Metrics use Azure Storage on itself to get a sense of how useful Table Services would be and how overkill DocumentDB might be in some situations.

Hope this helps.

Solution 3

I think that the comparison is all about trading price for performance. Table Services are just Storage Services, which seem to cap out at 20,000 ops/second, but paying for that kind of throughput all the time (because Storage gives it to us all the time) is $1,200/month. Crazy money.

Table services have simple indexes, so queries are very limited. Good for anything that is written and read via IDs. DocumentDB indexes the entire document, so a query can be done on any property.

And lastly, Table services are bound by the storage constraint of the Storage account it's on (which could get crazy high given negotiation with Microsoft directly), where DocumentDB storage seems unlimited.

So it's a balance. Do you have a LOT of data (hundreds of gigs, or terabytes) that you need in one place? DocumentDB. Do you need to support complex queries? DocumentDB. Do you have data that needs to come and go fast, but based on a 1-to-2 property lookup? Table services. Would you trade having to code around a simple index in order to avoid paying through the nose for throughput? Table services.

And Redis, someone mentioned that... man, I dunno. Even the existence of persistence in a caching framework (which Redis offers) doesn't turn it into a tech of choice... There is a huge difference between a persistent store that holds data that is "often used, but may be missing or time-retired", like a cache would, and a persistent store that guarantees your data to be there.

Solution 4

A real life example:

I have to store some tokens, retrieve them, delete them. Only query ever done will be based on User ID.

So I use Table Storage, as it fulfill my requirement perfectly. I save the token against User ID.

Document DB seemed to be overkill for this.

Solution 5

Here is the answer from microsoft's official docs

Common attributes of Cosmos DB, Azure Table Storage, and Azure SQL Database:

• 99.99 availability SLA

• Fully managed database services

• ISO 27001, HIPAA and EU Model Clauses Compliant

• The following table shows the uncommon attributes of Azure Cosmos DB, Azure Table Storage

View more solutions

Comments

[Illidan]

Thanks for your answer. Could you please provide a real-life example when Table Storage will be better than DocumentDB (aside of pricing aspect)?

[daronyondem]

Sure. Diagnostics data is a real-life example used by Azure right now. Here is another real-life example you might like troyhunt.com/2013/12/working-with-154-million-records-on.htm‌​l

[papadi]

So essentially you are saying that they only good thing about Azure Tables is pricing.

[David B.]

@Luis "most of them will require a full partition/table scan anyway, which will kill your performance and your cost savings" -- This is only true if you design your tables that way. If you know what you're doing, you design the tables in such a way that they are not doing full table scans, just like any other key/value NoSQL database. This is also one of the biggest differences between the two, from reading through the docs, it sounds like Microsoft handles most if not all of that stuff for you with DocumentDB, whereas with Table Storage it's up to you to design it efficiently.

[richard]

Sounds like redis cache would be a better solution for this than table storage.

[Bhavjot]

Thanks for the suggestion. Redis Cache might have been better, but it is more comparison between Table storage and Document DB.

[Mani Gandham]

Redis is not better. It's a cache first, with persistence optional, and requires all of your data to fit in memory, as well as running and maintaining a server. Meanwhile Azure Table Storage would cost pennies, is completely managed, persistent, reliable, and has very low latency when you're running in the same region.