1
votes

I m developing an application using SignalR to manage websockets and allow my clients to dialog between each other.

I m planning to host this back-office on an Azure worker role. As my SignalR requests carry data that is most of the time saved in the database, I m wondering if NoSQL's MongoDB instead of the classic SQL Server/Entity Framework couple should be a good approach.

Assuming that my application's data types will be strings for most of them, I think MongoDB will be a reliable and a performant solution, and it will allow me to get rid of Azure's SQL's database costs.

For information, the Azure worker role will be running on a machine with the following hardware: 1 core CPU, 3.5GB RAM and 50GB SSD storage.

Do you think I m on a good start with this architecture ?

Thanks

2
The issue with a MongoDB instance or cluster running on worker roles is that the machines are stateless. You don't want to rely on having active nodes and an arbiter up - if nothing else, consider a SaaS solution (MongoLab/MongoDB). I've run an Azure VM cluster for MongoDB pretty successfully, but I have to keep the Linux image patched pretty regularly. - Jeff Wilcox

2 Answers

2
votes

Do you think I m on a good start with this architecture?

In a word, no.

A user asked a similar question regarding running Redis on Worker Roles - Setting up Redis on Azure cloud service worker role - all of the content on that Q/A is relevant in the MongoDb context.

I'd suggest that you read my answer as it goes into more detail, but as an overview of why this is a bad architectural approach:

  1. You cannot guarantee when a Worker Role will be restarted by the Azure Service Fabric.
  2. In a real-world implementation of Mongo, you would run multiple nodes within a cluster, with a single Worker Role (as you have suggested in your question) this won't be possible.
  3. You will need to manage your MongoDb installation within the Worker Role and they simply aren't designed for this.

If you are really fixed on using Mongo, I would suggest that you use a hosted solution such as MongoLabs (as suggested in earlier answers), or consider hosting it on Azure IaaS VM's.

If you are not fixed on using Mongo, I would sincerely suggest that you look at Azure DocumentDb (also suggested above), Microsoft's Azure NoSQL offering - I have used it in several production systems already and it is certainly a capable NoSQL solution; granted, it may not have all of the features available with MongoDb.

If you are looking at a NoSQL solution for caching of data (i.e. not long term storage), I would suggest you take a look at Azure Redis Cache, which is a very capable Redis offering.

0
votes

Azure has its own native NoSQL Document database called DocumentDB, have you had a look at it? If I were you I would use DocumentDB unless there are some special requirements that you have that you have not mentioned, but from what little requirement info that you have posted DocumentDB would do just fine. I don't think that it is quite similar to MongoDB in terms of the basic functionality, see this article for a comparison between Azure DocumentDB and MongoDB.