This project has moved and is read-only. For the latest updates, please go here.

NoSQL selection criteria

Jul 30, 2014 at 1:07 AM

I intend to support an ASP.NET MVC application with a back-end repository of some sort, whether it is NoSQL or SQL, so I am checking out BrightstarDB for its NoSQL qualities for the first time.

At the risk of repeating others who have enumerated the features Brightstar is bringing to the show, these are the one(s) that seemed appealing to me anyway. Would anyone mind shedding some light on any nuance, gotchas, things to pay attention for considering its first time adoption.

A little background, I am no stranger to databases, document models is a little new but not insofar as they are an extension of domain model representation and the sorts of questions I might want to ask it, object relational mapping and things of this nature.

I will admit I am somewhat on the fence deciding whether the relationships between objects is more important, and the simplicity of simply updating a relationship, which I go with a more traditional RDMS-ORM approach, or I can satisfactorily insert domain objects into the document store, which they also need to update from time to time.

That being said, the qualities are, but are not limited to:
  • .NET support; not sure that's C# by extension, or written in C#, it would seem the latter
  • provides LINQ support: always a plus
  • Support for EF is attractive, presumably via a BrightstarDbContext (?); that's in latest EF versions, yes (?)
  • Can run as a server (could be a positive), or embedded (more likely what I want to do), depending how well that interacts with MVC
  • RDF triple store; not sure the full extent of that just now, but there are several domain classes which will need to be stored in a variety of "shapes", so to speak, from domain itself, to event and logging docs
  • I'm sure I am underestimating the power of SPARQL (pron, "sparkle"?), analog to embedded SQL or HQL in ORMs like NHibernate (?)
  • What sort of caching support does Brightstar provide? i.e. analog, for instance, to the NHibernate session, or presumably EF DbContext, through which persisted instances are attached, detached, etc?
Some concerns are, domain objects will need to update from time to time. Mostly objects will be inserted, read out and replayed, this kind of thing, but for the occasional update.

In some ways I'm not sure that an RDMS wouldn't be better, for instance if a Child instance changes hands from one Parent to another Parent, just update the relationship, no problem.

Whereas in a NoSQL document store, potentially wholesale replacing whole document objects, if the operation is even supported in the first place.

Looking forward to feedback. Thank you and like I said, apologies if I've repeated anything...
Jul 30, 2014 at 8:56 AM

Thanks for your interest!

BrightstarDB is a little different from many of the NoSQL offerings in that the core model is a graph-oriented rather than a document-oriented one. So in BrightstarDB you are building a network of nodes (roughly = objects / property values) and arcs (roughly = properties). BrightstarDB uses the RDF model and its storage engine is an RDF triple store, you also have the option of using a commercial triple store with BrightstarDB just providing the databinding layer. Because it is graph oriented, an operation like transferring relationship P1 -> C to P2 -> C is simply a question of deleting one arc and adding another, there is no direct containment of nodes so no need to rebuild a document tree.

BrightstarDB is written in C# and targets .NET and Mono. LINQ support can be used when you databind the RDF model to your custom C# domain model. There is flexibility in the RDF model which we try to blend with the convenience of a static C# model. In the RDF world, SPARQL (you got the pronunciation correct!) is the standard query language and it also provides an update dialect, both of which we support using. So you can use LINQ or SPARQL or even a combination of both in your application.

Our "EntityFramework" is really a databinding / repository layer. Its probably named badly because we don't implement the .NET EntityFramework so there is no direct technical comparison - just a more general one that we are trying to do the same thing for RDF data stores that .NET EntityFramework does for relational stores, but because the underlying model is different and because we chose to take a text templating approach to code generation there are some differences both at the API level (they are not API compatible) and the way in which it is used. With the benefit of hindsight, calling it EntityFramework was probably a mistake - perhaps a "rebranding" will be on the cards for a future release. However it does do the things you ask about - caching and support for attach/detatch, but in truth it is more designed for a pattern of CreateContext - Query - Update - Commit - DisposeContext (I guess this is close to the "UnitOfWork" pattern that you will find mentioned elsewhere in this forum).

Hope this helps,