Rob pointed out that my last post didn’t really make a strong case for using ESENT.  Why would someone want to jump through the extra hoops when they could just use NHibernate to store their data?  In it’s current form, I would have to agree that NHibernate is probably a better solution than using the very low-level ESENT API.  In its current form, there are two times when I would consider using it:

When I need blazing-fast access

Relational database operate in the millisecond range (if you are lucky).  That sounds fast, but compared to most operations in your application, it’s probably the slowest thing you are doing.  On the other hand, ESENT operates in the microsecond range, and it does so while still providing a lot of the core functionality you would expect from a data store: ACID compliance, transactions, etc.  When milliseconds are unacceptable, ESENT might be a good fit.

When I need to store large objects

Relational databases suck at storing blobs.  It doesn’t matter if they’re blobs of  binary data or blobs of text data, they aren’t good at it.  People have resorted to a variety of hacks, the most popular of which is to serialize the data to the file system and store only the path in the DB.  I don’t like this approach because you lose some of the benefits of a relational DB and now have to make two requests to load your data: one to the DB, and then one to the filesystem. 

ESENT is quite good at storing large objects.  Individual columns can have values of up to 2 GB, and it has been used in applications that have terabyte-sized datasets. 

Moving forward

For me, the major limiting factor in using ESENT for other applications is the API.  If the API was more abstracted, I would be much more likely to use it.  I’d like to see an API that supports a fluent or convention-based approach for creating the database, and I’d like to see operations generalized to the point that storing an object is nothing more than Put(id, object).  In what little free time I’ve had lately, I’ve been thinking about building such an API.  Features I’m considering are:

  • Fluent database specification
  • Implement the generic repository pattern
  • Basic LINQ support

As always, time is not something I have lots of, but I’m very interested in this topic right now, so hopefully that will motivate me to at least get something basic out there for use.  I’ve already done the most important step in any software project, and that’s picked a clever name: Jufresto, derived from the goal of this project, which is to Just Freakin’ Store it (it being anything you want to throw at it).