I’m attempting to use MongoDb as a session manager for Asp.Net and I’m seeing some immediate issues. Consider:
- ASP.Net state is not stored and used in set based operations. All queries from the webserver are key-based, which makes a NoSQL storage option ideal.
- MongoDb stores most of its data in RAM, which makes the queries lightning fast
- MongoDb can be sharded, allowing for the session data to be spread across multiple servers as your application grows.
The scalability of MongoDb lies in the 3rd item there – sharding. When we refer to sharding the database, what is meant is that the database will split the contents of a database or even and individual table (or collection in the case of MongoDb) across multiple service instances.
The challenge with MongoDb is that the database service has a single write-lock. This means that in high-write scenarios there can be contention for writing to the data-store. The Gilt Groupe recommends keeping requests under 50/second:
http://tech.gilt.com/post/32734187989/mongodb-performance-at-gilt
Still others demonstrate performance that indicates we should keep our writes under 25/s:
In my state server scenario, we need to keep all writes “safe” – that is, they need to be written so that the next read will find the changes. Using the numbers from the last benchmark, we should be able to see writes to a single MongoDb node in the neighborhood of 5000 per second.
In a very high-throughput application with several hundred thousand users accessing it concurrently, we will not be able to keep up with a single Mongo node. This is where sharding will help us. To manage 100,000 hits per second, we should distribute those writes across a 20-node MongoDb deployment.
Is this good performance? Is this a valid scalability solution? I look forward to your comments