3

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?

mare
  • 13,033
  • 24
  • 102
  • 191

2 Answers2

8

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.

Community
  • 1
  • 1
Gamlor
  • 12,978
  • 7
  • 43
  • 70
3

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).

Gates VP
  • 44,957
  • 11
  • 105
  • 108
  • MongoDB doesn't support transactions. Isn't this critical for a webshop? – User Mar 28 '14 at 01:56
  • MongoDB can atomically update a Document and its sub-objects in a transaction. This _may_ be enough for your needs. If you need to update multiple separate (_not nested_) Documents or Documents across multiple collections/tables all at once, then MongoDB is not for you. However, regardless of the DB you use, it's worth looking at 2-phase commit to see if this doesn't satisfy your needs as well. – Gates VP Mar 28 '14 at 21:17
  • The problem with Mongo is that you frequently can't store everything in a document. E.g manipulation of objects in nested arrays is not supported (see http://stackoverflow.com/questions/4669178/how-to-update-multiple-array-elements-in-mongodb). Document size is also limited. I had a case with article + comments - so initially put comments in an array in the article document. Ended creating different collection for the comments, and article holds array with only references. But then, it was not possible to update article + comments in a transaction, etc. – User Apr 03 '14 at 14:02
  • Yep, there is absolutely a limitation here. The comments example is a very common one. Most blog posts don't need 16MB of comment text. But you absolutely have to design for it. One of the big MongoDB trade-offs is designing for the common case and then writing out handlers for the rare cases like going over size. – Gates VP Apr 07 '14 at 22:46
  • And as described, the problem with limited nested update operations. IIRC e.g. when a user changed the picture (I was storing the picture url in each article/comment for performance reasons) I needed to go through all comments, which were stored in the article documents, in order to update. Not possible, since update of objects inside array is not supported. Maybe they'll change this in future though. – User Apr 08 '14 at 23:48