Moving webshop storage to NoSQL solution

Question

If you had a webshop solution based on SQL Server relational DB what would be the reasons, if any, to move to NoSQL storage ? Does it even make sense to migrate datastores that rely on relations heavily to NoSQL? If starting from scratch, would you choose NoSQL solution over relational one for a webshop project, which will, after a while, again end up with a bunch of tables like Articles, Classifications, TaxRates, Pricelists etc. and a magnitude of relations between them?

What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0? Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.

Your answer to this question will help me make the right infrastructure design decisions.

UPDATE: If I was developing my solution around ASP.NET MVC and rely heavily on Model classes, would it be the easiest way to go to choose DB4o to simply serialize and deserialize my objects to and from datastore?

Answer 1

OK, that's a lot of questions, let's see which ones I can really address.

Does it make sense to migrate existing relational datastores?

Not unless you have a really big performance problem. Here's the deal, "web-scale" performance problems are typically solved by denormalization. MongoDB is an inherently denormalized database.

If starting from scratch, would you choose NoSQL solution over relational one for a webshop project...

Yes. MongoDB is a very natural fit for typical web-based projects. However, if you have lots of SQL experience, you'll probably find the reporting a little awkward.

.NET 4.0 support? Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

Mongo has a driver available for .NET.

There's no L2SQL or EF wizard for Mongo, but there really shouldn't be. Honestly, what you'll probably miss most is Enterprise Manager for analyzing the DB.

MongoDB doesn't really need an EF wizard. EF is MS's solution for the "impedance mismatch" between DBs and objects. MongoDB doesn't have the "impedance mismatch", just stuff the objects in the DB and go. Much of the same goes for L2SQL. People have built some Linq support (just a quick google), but things like joins won't work b/c Mongo doesn't do joins.

From a "data objects" standpoint, Mongo only needs a very lightweight framework. Honestly it's as simple as stuffing the properties into the DB. If you want to "add a column", you simply add the property to your object and it starts saving in the DB. So things like L2SQL start becoming really unecessary.

Don't get me wrong, there's room for a different querying paradigm, but in that regards you're in new territory. (you will be for all key-value and document-oriented stores).

Answer 2

Well quite a open-ended question.

Migration to a NoSQL-datastore for an existing software

Well often there's a lot of experience and knowledge for the existing relational technologies. When you're application runs fine, its probably not worth the effort. However when you have unsolvable issues with the current solution, then it's an option.

Does it even make sense to migrate datastores that rely on relations heavily to NoSQL?

Well you have to consider that the three technologies (Document-DB, RDBMS, Object Database) are very different from each other.

• In the relational world you normalize data and join them at runtime together. This works fine, as long as the data-sizes are not to big. Here often the issues starts: When you have lot of normalized data you need to do a lot of joins, which costs a lot of performance. And of course mapping between your objects and your tables can be quite tricky.
• In a object-database the each object is stored individually and the 'relations' are stored in forms of pointers. So when a object A has a reference to object B, the object-database stores this reference. So to retrieve the 'relation', no join operations are necessary. Therefore 'relations' are cheap. In conclusion object-databases are really good at handling relations.
• In a document-database like MongoDB a complete object-graph is stored as a document. The document-database works with a the document-level. So here there are no real 'relations'. You normally just store/load documents. So when you can model you scenarios so that most of your operations only work on a single document, it's very performant and easy.

Here's a good blog-post which compares the design-difference of MongoDB (document database) and db4o (object-database)

In the end you model should fit to your database. For example, don't try to use a model for a relation database and store it 1:1 in a document database. See also Ayende's blog about modeling for a object-database.

What's the support like in .NET (4.0) for MongoDB or MongoDB's support for .NET 4.0?

Gates VP has already answered this for MongoDB. The .NET 4.0-version of db4o is in development. Meanwhile the 3.5 version also works fine on the 4.0 framework.

Can I count on rich code generation tools similar to EF wizard, L2SQL wizard etc. for MongoDB?

For both, MongoDB and db4o you don't need to generate code. Your classes are the schema. You just store you objects and the database takes care of the rest. See also Gates VP answer

Because as what I have read so far, NoSQL's are mostly suited for document storage, simpler object models.

Well the range is quite big. From really simple key-value-stores, to more advanced document-databases, colum-oriented-databases, graph-databases and object-databases.

Of course the document-database work excellent when you have store document-like data (for example a blog-software). While graph- and object-databases are good at handling extreme complex data structures.