MongoDB ASP.NET Session Store Provider v1.1.0

Since I created the MongoDB ASP.NET Session State Store Provider (v1.0.0), a few things have moved on in the MongoDB C# Driver. I’ve pushed a number of changes up to the project on GitHub (which I’ve incremented to v1.1.0), so it now uses v1.7.0.4714 of the driver. There is no change to way it is configured in web.config, so if you are using v1.0.0 of my provider it should be painless. [Read More]

The importance of "Working Set"

One of the things that I see cropping up pretty often is this thing called “working set”. After recently chipping in on another StackOverflow question on the subject of “What does it meant to fit ‘working set’ in RAM?”, I thought it was a good subject for a blog post. This is really just a copy and extension of my input on that question and focused in certain parts on MongoDB, but is also as relevant to other databases. [Read More]

MongoDB ASP.NET Session State Store Provider

Please note: v1.1.0 of this Sesssion State Provider is now available. See blog post: I’ve pushed up an initial drop of a custom ASP.NET session state store, backed by MongoDB, to my GitHub repository. After a quick test it seems OK, though could do with a real hammering before being deemed production worthy! So if you want to use it, just make sure you give it a good test through and most importantly, let me know how it goes! [Read More]

MongoDB Journaling Performance - Single Server Durability

Note: Relates to v1.8.0 release. v1.8 of MongoDB (production release hot off the press, available from here) brings single server durability to MongoDB via its support for write-ahead journaling. The following summarises the key points from the journaling documentation, administration guide and from my initial playing around. you have to specify the –journal switch for mongod in order to enable journaling (was previously –dur prior to production release) journal files are created within a journal subfolder of your dbpath, up to 1GB each in size in the event of a crash, when mongod restarts it will replay the journal files to recover automatically before the server goes online if mongod shuts down cleanly, the journal files are cleared down. [Read More]

Thoughts on MongoDB from a SQL Server Dev

As someone with a background in SQL Server development dating back to 2000, the whole NoSQL jazz has been something that’s been on the radar for a while but never made it under the microscope so to speak. Partly because SQL Server is my comfort zone and there’s plenty more to still learn about that; partly because I’ve had my career mapped out in my head and NoSQL didn’t feature much in that vision; partly because until you have something real-world driving a push into a technology then you tend to have that technology remaining as a distant dot on the radar. [Read More]

MongoDB 1.8.0 Release Candidate is out

MongoDB 1.8.0-rc0 is now available, you can download from here and find the release notes here. The main changes over the current 1.6 production release relate to: durability, a much talked about topic (!), with support now for write-ahead journaling (docs) sparse and covered indexes (on my radar to try out) support for more Map/Reduce functionality (note there are some breaking changes in this area) The full info on the changes is in the Release Notes document. [Read More]

MongoUK 2011 - Upcoming MongoDB event

There’s a one day conference on MongoDB coming up, being held at the Skills Matter eXchange in London on Monday 21st March 2011. If you’re interested in MongoDB or even just curious as to what it’s all about, then it’s worth registering for it based on what’s on the agenda - it’s going to be tough to choose between the different sessions, which include ones on: schema design storage engine internals indexing and query optimiser scalability map/reduce & geo indexing It will also be a good chance to hear from speakers outside of 10gen such as Thoughtworks, Guardian and Boxed Ice. [Read More]

MongoDB replication - oplogSize

Background An oplog is a write operation log that MongoDB uses to store data modifications that need to be replicated out to other nodes in the configured set. This oplog is a capped collection which means it will never grow in size beyond a certain point - once it reaches it’s max size, old data drops off the end as new data is added so it keeps cycling round. The size of the oplog basically determines how long a secondary node can be down for and still be able to catch up when it comes back online. [Read More]

MongoDB - Does My Data Look Big In This?

You have an existing relational database containing x amount of data and you decide to migrate that data, for whatever reason, into MongoDB. You may have an pre-conceived belief that as your relational database is x GB in size, that after loading that data into MongoDB your NoSQL database size will be around about x GB too - after all, you’re loading exactly the same data from one to the other right? [Read More]