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
