Azure table vs MongoDB on Azure

Question

I want to use a NoSQL database for Windows Azure, and the data volume will be very large. Is the Azure Table repository or the MongoDB database running as the Worker role can provide better performance and scalability? Has anyone used MongoDB on Azure using the Worker role? Share your thoughts on using MongoDB on Azure over Azure Table Storage.

Answer 1

Table storage is the main storage function of Windows Azure, designed to scale ( 100TB 200TB 500 TB per account), durable (triple replicated in the data center, optionally geo-replicated to another data center) and schematically (each row can contain any properties, which you want). The line is located with the section key + line key, providing a very fast search. All access to the table storage is through a well-defined REST API that can be used in any language (with an SDK built on top of the REST API already installed for .NET, PHP, Java, Python and Ruby).

MongoDB is a document-oriented database. To run it in Azure, you need to install MongoDB as a web / worker or virtual machine, point to a cloud drive (thus the drive letter) or a mapped drive (for Windows / Linux Virtual Machines), it is not necessary to enable logging (which I would recommend), and possibly define an external endpoint for your use (or access it through a virtual network). By the way, the cloud disk / attached disk is actually stored in Azure Blob, which gives you the same durability and geo-replication as Azure Tables.

When comparing the two, remember that table storage is storage as a service: you just go to the well-known REST endpoint. With MongoDB, you are responsible for maintaining the database (for example, whenever MongoDB Inc (previously 10gen) pops a new version of MongoDB, you need to upgrade your server accordingly).

As for the alpha version of MongoDB Inc, which jtoberon points to: if you look carefully at it, you will see a few key points:

• Customization is done for a standalone mongodb instance without replica sets or skulls. Regarding replica sets, you still get several advantages using the standalone version because of how the Blob repository works.
• To ensure high availability, you can run multiple instances. In this case, only one instance maintains the database, and the other is the “warm standby”, which starts the mongod process as soon as another instance fails (to restart maintenance, hardware failure, etc.).

While the 10gen Windows Azure shell is still considered alpha, mongod.exe is not. You can run mongod exe in the same way that you run any other Windows exe file. This is just the control code around the launch, and what the alpa implementation demonstrates.

EDIT 2011-12-8: This is no longer in alpha state. You can download the latest MongoDB + Windows Azure project here , which provides replica set support.

For performance, I think you will need to benchmark. Having said that, consider the following:

• When accessing a table storage or MongoDB, say a web role, you still access the Windows Azure storage system.
• MongoDB uses a lot of memory for its own cache. For this reason, many high-scale MongoDB systems are deployed for larger instance sizes. You will not have the same memory size to access the table storage.

EDIT April 7, 2015 If you want to use the underlying database as a service, Azure now offers DocumentDB.

Answer 2

I used both.

Azure tables: dead simple, fast, very difficult to write even simple queries.

Mongo: Works well, has many querying capabilities, requires multiple instances to be reliable.

In a nutshell, if your queries are really simple (key-> value), you should compare costs (basically, the number of transactions against storage and the cost of placing Mongo on Azure). I would rather go to the table store for this. If you need more complex queries and don’t want to go to SQL Azure, Mongo is most likely your best bet.

Answer 3

I understand that this question is dated. I would like to add the following information for those who can find this question in their searches.

Please note that MongoDB is now offered as a fully managed Azure service. (officially on Beta as of April 15)

See: http://www.mongodb.com/partners/cloud/microsoft or https://azure.microsoft.com/en-us/blog/announcing-new-mongodb-instances-on-microsoft-azure/

See (including pricing): https://azure.microsoft.com/en-us/marketplace/partners/mongolab/mongolab/

Answer 4

My first choice is AzureTables because the SAAS model is both low cost and 99.99% SLA
http://alexandrebrisebois.wordpress.com/2013/07/09/what-if-20000-windows-azure-storage-transactions-per-second-isnt-enough/

some limitations .. http://msdn.microsoft.com/en-us/library/windowsazure/jj553018.aspx

http://www.windowsazure.com/en-us/pricing/calculator/?scenario=data-management

or AzureSQL for small business

DocumentDB http://azure.microsoft.com/en-us/documentation/services/documentdb/ http://azure.microsoft.com/en-us/documentation/articles/documentdb-limits/

second choice - many cloud providers, including Amazon, offer S3

or google spreadsheets https://developers.google.com/bigquery/pricing

nTH the choice to manage the SHOW alone does not sleep MongoDB well, I will look at the first two SAAS again

My choice, if I run "CLOUD", I will go to the SAAS model as much as possible "RENT-IT" ...

The question is what my application needs - is it AzureTables or DocumentDB or AzureSQL
Documentation DocumentDB http://azure.microsoft.com/en-us/documentation/services/documentdb/

How the Azure price works http://azure.microsoft.com/en-us/pricing/details/documentdb/

This is fun http://www.documentdb.com/sql/demo

Answer 5

Everything is fine above the answers - but the real answer depends on your requirements. You need to understand what size of data you are processing, what types of operations you want to perform on the data, and then choose the solution that suits your needs.

Answer 6

At Build 2016, it was announced that DocumentDB would support all MongoDB drivers. This solves some of the tool issues in DocDB and also makes it easy to migrate Mongo applications.

Answer 7

Keep in mind that Azure Table Storage does not support complex data types . It supports each property in essence as a string or number, a boolean or date, etc. You cannot store an object against a key, which, in my opinion, is necessary for the NoSql database. https://docs.microsoft.com/en-us/rest/api/storageservices/fileservices/understanding-the-table-service-data-model highlight Property Types