How to categorize ModeShape in the world of NoSQL database?

[ozhou]

These days I am reading Martin Flower's "NoSQL Distiiled" book. In that book, it categorized NoSQL databases into Key-Value/Document/Column Family/Graph.

I'm wondering which category ModeShape may fit in?

For me, it is more like Document Database, however, ModeShape is using Infinispan (Key-Value store) as cache and peristence layer.

[hchiorean]

Personally, I think ModeShape is a hybrid storage solution, which can fall in some/all of the taxonomies described by Martin Fowler in the above mentioned book, dependending on which "lens" you look through:

• schema - one of the main "marketing" points of the NoSQL hype is the lack of / the existence of a very loose schema for your data. Being a JCR spec implementation, ModeShape actually offers both options: you can store data without any kind of schema constraints using the standard JCR types (e.g. nt:unstructured) or you can define gradually constraint-increasing schemas which meet your particular needs. From this perspective, you can see ModeShape as both NoSQL and SQL.
• client API - again driven by the JCR spec, the way clients interact with ModeShape in order to manipulate data, is via a "hierarchy oriented" API. For me, this falls somewhere in between a Graph Storage solution (we don't really have edges/relations, but you could see Nodes as vertices) and a Document Storage solution (you can see each Node with properties as a document with attributes)
• data storage implementation - I think that there is a "missmatch" between the client API (which is hierarchical) and the way data is actually stored, which is esentially using Key-Value pairs in Infinispan. Given the "nature" of Infinispan, if you only think of ModeShape from this perspective, you could call it a "Key/Value store"

So I would see ModeShape as sort of a "Rubik's Cube" for persisting data, where depending on any given context, you can use a certain "face" (or a combination of faces) which suits your needs. 

[ozhou]

Thanks for your reply.

I think you are right. It's hard to categorize ModeShape into a specific category of NoSQL.

To me, the most attractive part of ModeShape is the above three you mentioned, plus fully ACID support and powerful query (especially it has a syntax similar to SQL).

I don't even have time to try clustering before finishing the features. But I think in the production enviorment, it's neccessary. I'll give it a try in next month.

Before end of month, I should be able to finish the transition from Hibernate/JPA to ModeShape/JCR for our persistence layer.

I have to say that I'm very happy with ModeShape so far. I have to admit that I have ever been worried about the quality and performance.

But I found Randall and you are very active to answer the questions and fix the critical bugs very soon especially the latest 3.2 version fix critical transaction and indexing performance issues.

The reason why I ask such question is because I need to explain why we should make such transition from Hibernate/JPA to ModeShape/JCR to my colleagues and product manager

[rhauch]

I agree with Horia. Just because Martin Fowler puts all NoSQL databases (there are lots!) into four categories doesn't mean those are the only ones. It's useful to consider his categories, but don't try to make everything fit.

Also, while many NoSQL databases are not consistent and are not characterized as ACID stores, other are. One of Martin's presentations talk about this, and he uses the term "aggregate-oriented" to nicely explain why this is true. Column-oriented, document-oriented, and key-value databases all operate upon single data structures that aggregate different parts of information about a single thing. Because they and clients operate upon "aggregate" things as a whole, there is far less need for consistency since the aggregate is itself a container, and the database updates the whole aggregate atomically. However, graph databases (and I'll throw in hierarchical databases like ModeShape) do not work with aggregates but instead work with multiple parts at once (e.g., nodes and edges in a graph database, nodes and properties in a hierarchical database) and therefore must be strongly-consistent.