First toe in the water with Object Databases : DB4O
- by REA_ANDREW
I have been wanting to have a play with Object Databases for a while now, and today I have done just that. One of the obvious choices I had to make was which one to use. My criteria for choosing one today was simple, I wanted one which I could literally wack in and start using, which means I wanted one which either had a .NET API or was designed/ported to .NET. My decision was between two being: db4o MongoDb I went for db4o for the single reason that it looked like I could get it running and integrated the quickest. I am making a Blogging application and front end as a project with which I can test and learn with these object databases. Another requirement which I thought I would mention is that I also want to be able to use the said database in a shared hosting environment where I cannot install, run and maintain a server instance of said object database. I can do exactly this with db4o. I have not tried to do this with MongoDb at time of writing. There are quite a few in the industry now and you read an interesting post about different ones and how they are used with some of the heavy weights in the industry here : http://blog.marcua.net/post/442594842/notes-from-nosql-live-boston-2010 In the example which I am building I am using StructureMap as my IOC. To inject the object for db4o I went with a Singleton instance scope as I am using a single file and I need this to be available to any thread on in the process as opposed to using the server implementation where I could open and close client connections with the server handling each one respectively. Again I want to point out that I have chosen to stick with the non server implementation of db4o as I wanted to use this in a shared hosting environment where I cannot have such servers installed and run. public static class Bootstrapper { public static void ConfigureStructureMap() { ObjectFactory.Initialize(x => x.AddRegistry(new MyApplicationRegistry())); } } public class MyApplicationRegistry : Registry { public const string DB4O_FILENAME = "blog123"; public string DbPath { get { return Path.Combine(Path.GetDirectoryName(Assembly.GetAssembly(typeof(IBlogRepository)).Location), DB4O_FILENAME); } } public MyApplicationRegistry() { For<IObjectContainer>().Singleton().Use( () => Db4oEmbedded.OpenFile(Db4oEmbedded.NewConfiguration(), DbPath)); Scan(assemblyScanner => { assemblyScanner.TheCallingAssembly(); assemblyScanner.WithDefaultConventions(); }); } } So my code above is the structure map plumbing which I use for the application. I am doing this simply as a quick scratch pad to play around with different things so I am simply segregating logical layers with folder structure as opposed to different assemblies. It will be easy if I want to do this with any segment but for the purposes of example I have literally just wacked everything in the one assembly. You can see an example file structure I have on the right. I am planning on testing out a few implementations of the object databases out there so I can program to an interface of IBlogRepository One of the things which I was unsure about was how it performed under a multi threaded environment which it will undoubtedly be used 9 times out of 10, and for the reason that I am using the db context as a singleton, I assumed that the library was of course thread safe but I did not know as I have not read any where in the documentation, again this is probably me not reading things correctly. In short though I threw together a simple test where I simply iterate to a limit each time kicking a common task off with a thread from a thread pool. This task simply created and added an random Post and added it to the storage. The execution of the threads I put inside the Setup of the Test and then simply ensure the number of posts committed to the database is equal to the number of iterations I made; here is the code I used to do the multi thread jobs: [TestInitialize]
public void Setup()
{
var sw = new System.Diagnostics.Stopwatch();
sw.Start();
var resetEvent = new ManualResetEvent(false);
ThreadPool.SetMaxThreads(20, 20);
for (var i = 0; i < MAX_ITERATIONS; i++)
{
ThreadPool.QueueUserWorkItem(delegate(object state)
{
var eventToReset = (ManualResetEvent)state;
var post = new Post
{
Author = MockUser,
Content = "Mock Content",
Title = "Title"
};
Repository.Put(post);
var counter = Interlocked.Decrement(ref _threadCounter);
if (counter == 0)
eventToReset.Set();
}, resetEvent);
}
WaitHandle.WaitAll(new[] { resetEvent });
sw.Stop();
Console.WriteLine("{0:00}.{1:00} seconds", sw.Elapsed.Seconds, sw.Elapsed.Milliseconds);
}
I was not doing this to test out the speed performance of db4o but while I was doing this I could not help but put in a StopWatch and see out of sheer interest how fast it would take to insert a number of Posts. I tested it out in this case with 10000 inserts of a small, simple POCO and it resulted in an average of:
899.36 object inserts / second.
Again this is just simple crude test which came out of my curiosity at how it performed under many threads when using the non server implementation of db4o. The spec summary of the computer I used is as follows:
With regards to the actual Repository implementation itself, it really is quite straight forward and I have to say I am very surprised at how easy it was to integrate and get up and running. One thing I have noticed in the exposure I have had so far is that the Query returns IList<T> as opposed to IQueryable<T> but again I have not looked into this in depth and this could be there already and if not they have provided everything one needs to make there own repository. An example of a couple of methods from by db4o implementation of the BlogRepository is below: public class BlogRepository : IBlogRepository
{
private readonly IObjectContainer _db;
public BlogRepository(IObjectContainer db)
{
_db = db;
}
public void Put(DomainObject obj)
{
_db.Store(obj);
}
public void Delete(DomainObject obj)
{
_db.Delete(obj);
}
public Post GetByKey(object key)
{
return _db.Query<Post>(post => post.Key == key).FirstOrDefault();
}
…
Anyways I hope to get a few more implementations going of the object databases and literally just get familiarized with them and the concept of no sql databases.
Cheers for now,
Andrew
