So I dug a bit deeper into MongoDB and NoRM, which is a nifty C# driver for MongoDB developed by Andrew Theken and several others. You might want to grab a copy at github, where you can see how incredibly active the project is! Now, back to the evaluation: what is the best way to evaluate a database? Of course, build a live product using it!

Since I was completely abusing db4o for said project (in fact, I am storing something you’d call documents there), I decided that this would be a great candidate for a migration. So now we’re migrating from an object database to a document database and from an ACID database to a NoSQL solution.

MongoDB is considered a NoSQL solution, while db4o is considered ’soft’ NoSQL – see Stefan’s comment at the bottom. Why the distinction – both do not rely on, support or use SQL whatsoever?! But then again, that is not what the Term »NoSQL« is all about. It’s probably one of the most misleading terms ever coined and perhaps it should read »Not ACID« or just »Persistence without Prejudgement, PwoP«. db4o makes ACID guarantees, comes from an embedded background and offers single-server durability while MongoDB is made for the net, does not have single-server durability, supports MapReduce and is driven by JavaScript.

Hell, they couldn’t be more different. But then again, I can access both using identical interfaces:

// Linq is understood by both, so you could use the lines in both:
var u = (from Note n in container
         where n.Text == null select n).ToList();
var v = session.Query<Tag>().Where(p => p.Name != null);
// Store an object graph to Mongo using NoRM:
session.Add(testNote);
// Store an object graph to db4o:
container.Store(testNote);

Don’t be fooled – although these lines could all be used with MongoDB or db4o and all of them could even be used with the very same classes, they are still fundamentally different in behavior. Also, for anything but the most simple problems, you can’t just persist the same domain models.

What is a document now?

A document is not just an unstructured piece of data. It’s not a BLOB. Instead, an instance of a class, plus all it refers to, could be a document:

class UniqueIdObject
{
    public Guid Id { get; private set; }
    public UniqueIdObject() { Id = Guid.NewGuid(); }
}

class Report : UniqueIdObject
{
    public Report() : base() { Tags = new List<Tag>(); }
    public string Text { get; set; }
    public List<Tag> Tags { get; set; }
}

class Tag : UniqueIdObject
{
    public string Name { get; set; }
}

Now we might want to store a note in the database, and the code needed is just

using (NoRMSession session = new NoRMSession())
{
    Report newReport = new Report() { Text = "Hello World, MongoDB!" };
    newReport.Tags.Add(new Tag() { Name = "Tag 1" });
    newReport.Tags.Add(new Tag() { Name = "Tag 2" });
    session.Add(newReport);
}

That’s it! Wow! Of course, we haven’t taken care of indexation and stuff and since MongoDB is schemaless (or better, has a dynamic schema) we need to do that in code. But still, this is essentially all you need.

The important thing now is: What happens to those little `Tags` we deliberately put into a separate class? Now the mapper hides a bit of truth from us, because MongoDB works on so-called “Collections”. session.Add(newReport) will be session.Add<Report>(newReport), which will in turn put the newReport object into the Report-Collection! So the object graph, as it is, will be serialized into the Report collection, including our little Tag objects!

Each item with an orange border is an ‘atomic’ item in its respective data store:

db4o serialized graph

mongo serialized document

Let’s naively try to fetch all tags:

var v = session.Query<Tag>().Where(p => p.Name != null);

This does not work, v is null because there is no tag collection! Instead, the tag lists are part of the reports we put into the Report collection. Note that this would work in db4o, because db4o will store references as references, while ‘documents’ store the contained data instead of references. This is beautifully simple, but it’s also very different from what you might expect and it has lots of implications for your object structure.

Thoroughly think through your schemaless schema

MongoDB is made for scalability and simplicity, so it does not care for our foolish approach to fetch tags directly. There are ways to access that data directly, however. We could use a deep-graph query or write a javascript Map/Reduce instruction, but that is a bit out of scope right now. What’s more important is that it calls for changes to our domain model objects: If we really want to store a reference, we need to do so manually, in ye olde sql-way, by storing the associated Id instead of the object. Of course, that makes deserialization a bit more complicated because the object we now retrieve from the database aren’t ready-to-use as they come.

However, automating that process will induce several complications, among them the need to handle cyclic references, a concept for fetching or activating objects on-the-fly, called Transparent Activation in the db4o world and making sure we’re not inducing a massive performance hit along the way.

Also, updating objects can be painful. Suppose we stored a list of Reports for each user. Now we might want to put the list of reports directly into the user object, or store a list of ReportIds for each users and put the Reports into their very own ReportCollection. As usual, there is no silver bullet, so this decision depends on the specific needs of the application, but whatever decision we take will not be visible to users of the resulting objects. In fact, it leads to some unwanted strong coupling:

class ReportService
{
  private NoRMSession _session;

  // ...
  public void UpdateReportDetail()
  {
    this.ReportDetailXY = ComplicatedCalculation();
    this.LastChanged = DateTime.UtcNow;

    // If the reports are in their very own Report Collection, this
    // is fine. However, if they are contained as lists in the user
    // who owns them, we're in trouble and this will fail!
    _session.Update(this);
  }
}

This might not be a big problem for really small applications, and if you really need performance (why else would you choose a NoSQL system?) you have to fine-tune your objects anyways. Still, I have the feeling that there is some space for improvement here, and a basic wrapper could help in overcoming some of the issues raised. Some basic ideas on how to approach this will follow shortly.

Wrapping it up

Obviously, I’m comparing Apples and Oranges here: db4o is made to make persistence easier, especially with complex domain model objects. db4o, being an object database, behaves exactly the way you’d expect objects under serialization to behave, but that makes it quite complex. MongoDB is focused on simplicity and scalability. Through the document concept, you gain simplicity on the database, administration and wrapper (driver)-side, but you have to struggle with a slight impedance mismatch in code, especially against Linq, again.

Just to get that straight: I’m an avid db4o user and really love it. These issues are not critical and they don’t stop me from using or evangelizing db4o. However, I think there is some lack of awareness of some issues.

Also, I’d like to spawn some discussion about the issues below. Unfortunately, due to their changes to the forum system, most of the original discussions on the db4o forum are hard to find or possibly lost. You may want to vote on the issues you deem most pressing, which you can easily do in their issue tracker! I’m very interested in what you think about this little selection.

Selected Issues

» Don’t run SODA when no more constraints are present
I blogged about this already, because you experience this in very common scenarios, namely whenever you query a small subset of a larger candidate set. For example, consider selecting the last 50 posts on a blog/qa-site/etc. What will happen is that db4o runs the BTREE query for the sort operation (blazing), then hydrates (?) all objects, the returns the first 50 of them and throws away the rest. Thing is that there is no need to further inspect the items, and activating all them is basically a linear operation. Thus, this common type of query currently runs in O(n) instead of O(log n) which is an incredibly dramatic difference.

» LINQ-Implementation is not ‘thread’-safe
A very similar issue has been on LINQ-to-SQL’s todo list some time ago.
I’m not sure whether this is so much the typical use case. For the db4o case, it teaches us two things right now:

• Container reuse is non-trivial and should be approached with extreme care. You don’t want to run into this kind of byzantine error in a live app.
• The object identity problem is similar in both Object-Relational Mapping and OODBMS

» Scalable server architecture: multiple readers against the same file, transactional files
This sounds daunting, and it’s probably a huge one, as you can see from its age. I also believe this might be politically challenging, because this moves into the direction of Versant’s large-scale object database. However, there is a lot of movement into that direction from the user-side it seems – people are asking for features of this kind more and more lately, largely due to the ultra-cool LINQ integration db4o has. I suppose I’d be wise to focus on this kind of scenario as it could really become the preferred way of writing web applications: it’s extremely agile, supports rapid development, is flexible in that the same (LINQ) code could be used for different persistence layers if that should ever be needed and leads to clean, compile-time checked, type-safe code.

» Sanitize reflector design – remove core dependencies on generic reflector
Being able to get rid of the generic reflector seems important, I’m already building my own code for this. Here we have conflicting requirements: The GenericReflector makes db4o very easy to use and may help beginners. It is also required in client-server scenarios where the server doesn’t have the necessary model dlls, but for most applications I think you should try to avoid it. Storing data in a generic manner is slow and requires a lot more space, making it highly inefficient.

Current attack vector: Throw a Listener on the object created event on the server and make sure the server knows the type.

» Allow immediate TCP port reuse
When opening a server, the TCP port will be blocked in case the server crashes, the app is terminated, etc. Since that might happen quite often when you use the ‘integrated server’ where the server is actually created in your web application, a restart of the web application will fail because the TCP port is blocked. In a client-server scenario, on the other hand, a simple restart wouldn’t be possible because you need to assign a new port to clients or wait 6 minutes. This should be fairly simple, but I don’t know if that comes with any side-effects.

» Fast Collections
This is a huge one. The cool thing is that this could allow much more complicated queries to be executed in reasonable timeframes. However, I’m a bit worried about the issue “FastCollections: Inside BTree List implementation”, because that sounds really important, but is in state “Won’t fix”.

» Locking
Optimistic locking would be a nice-to-have thingie, but you do this yourself rather easy I think.

» A new object is stored upon value type updates
This is rated critical, so it’s not an item for a “wishlist”. I’m not sure if I understand its implications and I rarely use value types apart from Guids, and updating Guids is pointless – still a db4o user should probably know this and keep this in mind, so I felt it should go here ☠.

db4o Configuration

This one is not really in the issue tracker as a single item, and it’s more of a general remark. One of the rather messy things in db4o is configuration. Even with the new configuration interface, there is quite a bit of confusion among users. The reason, in my eyes, is mostly a combination of incomplete documentation and unexpected behaviour. Examples:

• The indexation setting for fields is the only configuration setting that is persistent. Everything else, including unique constraints, needs to be re-set when (or – more precisely – before) opening the ObjectContainer.
• Applying an option to a field that doesn’t exist will not trigger a warning or an Exception
• Some settings simply won’t have any effect when you perform them after opening the ObjectContainer, but they do not warn you.
• Certain settings must be applied on the server, a few must be applied on the client and with some … well, you just set them on both just to make sure. Here, db4o does throw exceptions, however!
• Several options need to be set before creating the object container (e.g. string encoding) and cannot be reset afterwards, again being completely silent about the ineffectiveness of the respective settings.
• Some settings, such as field-based cascade-on-activate, simply don’t seem to work at all

This leads to lots and lots of confusion. Most importantly, it is often hard to determine whether a certain setting was successfully applied, or not. Also, some defaults are unexpected:

• Default ActivationDepth is (completely random) 5. Why not 8? Or 2? This troubles beginners a lot. Either set it to infinity, or to zero. Everything else feels just random. You can still include a line ActivationDepth = 5; in beginner’s samples, thereby showing them that the setting is there and that they need to be aware of it.
• Default string encoding seems to be UTF-16 or UCS-2, probably the most useless encodings around, despite the Windows Kernel working with it. UTF-8 would come in as a reasonable default, but with UTF-16 half of your database is probably zeros, because even in non-english environments, there is still a lot of mostly ASCII-data to be stored (such as URLs, Email addresses, base64 encoded information, SHA-hashes, etc.). Also many languages have non-ASCII characters only sparingly, German being one example.

I think it’d be really cool if the configuration interface was a little more explicit and would throw Exceptions instead of silently ignoring requests that cannot be fulfilled.

Talking about speed and performance, I just came across an issue that was also discussed in db4o forums very recently: Sort operations on large datasets.
Note: This has nothing to do with linq or linq to db4o, it’s just the same for SODA queries.

Let’s take a very common example: Find some most recent items, for example most recent blog/forum posts or some other ‘top list’ on a very large amount of entries N:

        var mostRecentPosts = (from Posts o
              in ObjectContainer
              orderby o.Created descending
              select o).Take(100).ToList();

This query will be really really slow on a large amount of objects. Why? Essentially, the BTREE operation is very fast as it should be, but unfortunately db4o will invoke its SODA system on each of the objects, even if they are already outruled by the BTREE operation.

See this discussion on the db4o forum and the associated Jira-bug.

This is somewhat sad, because a query on a previously filtered set of items is blazing, about 100x faster:

        var mostRecentPosts = (from Posts o
              in ObjectContainer
              where o.Created > yesterday
              orderby o.Created descending
              select o).Take(100).ToList();

The latter operation plays roughly in the same league as SQL Server (don’t flame me – performance comparisons and profiling is really complicated and there is a zillion of factors that influence it, I know. That’s why I say ‘roughly the same league for this query’ and I’m talking about default setups).

This is a somewhat unfortunate situation, because it produces slow queries for many typical applications – unless you have a strong where clause that cuts down N from millions to hundreds. If you’re interested in seeing this issue fixed, head over to their issue tracker and vote for the issue to be fixed! Thanks!

I’ll be posting a bit more on db4o over the next few days I hope.