How Intersystems Caché fits in the Graph Database Arena !

Hi,

I would like to draw your attention on a recently published article, titled "A Quick Guide on How to Prevail in the Graph Database Arena", that has been posted also at LinkedIn. Intersystems Caché has been referenced several times. In the "Multi-model Database Engine" section of this article, there is a quick description of Caché  as an

object database with relational access, integrated support for JSON documents and a multidimensional key-value storage mechanism that can be easily extended to cover Graph data model

I believe strongly that Intersystems Caché is an exceptional database product. Its architecture is unique and powerful. I have emphasized this in the following section of the same article,

No matter what is their physical implementation, i.e. hash tables or trees, based on this abstract data type you can model all four NoSQL database types, (Key/Value, Tabular/Columnar, Document, Graph). For one reason or another, we are of the opinion that associative/multidimensional arrays will eventually prevail in the world of databases.

These two key points justify that graph data model can be a perfect fit on the architecture of Intersystems Caché. Although I have not seen any movement  from Intersystems towards that area, I am confident there is a great potential in business value by integrating/expanding the multi-model functionality of Cache. I presume the database market is matured enough for graph databases.

But the problem with this database sector is that it is both cluttered and perplexed with many different kinds of graph databases. Let me focus on the conceptual/logical layer where my work is based. Depending on the structure of nodes and edges you get different graph topologies and stores.

1. Property Graph Data Model
   1. Entity centric with Embedded Properties and edges with BIDIRECTIONAL LINKING, Directed Labeled Graph
   2. Neo4J, OrientDB, ArrangoDB, etc...
2. Triple/Quadruple Data Model 
   1. Edge centric with UNIDIRECTIONAL LINKING on vertices, Directed Labeled Graph
   2. GraphDB, AllegroGraph, OpenLink Virtuoso,
3. Associative Data Model
   1. Hypernodes, Hyperedges, BIDIRECTIONAL LINKING, Hypergraph/Bipartite Graph
   2. Topic Maps, R3DM/S3DM, X10SYS (AtomicDB), HypergraphDB, Qlik

I will not get into analyzing their differences in detail here, I have covered to some extend their differentiation criteria in my article mentioned already. My research work and development has been on the third type above, the Associative Data Model also known as hypergraph or bipartite graph. Currently there are only two major players in the market with products that are based on associative technology.

In "Associative Data Modeling Demystified" series of posts that is written with a hands-on practice style, I introduce my audience to the design of R3DM/S3DM and I am making an attempt to clear the information glut of many-to-many relationships (a.k.a associations) with a thorough examination of well-known data models and graph/associative software products.

Part 6 - R3DM/S3DM: Build Powerful, Meaningful, Cohesive Relationships Easily

Part 5 - Qlik Associative Model

Part 4 - Association in RDF Data Model

Part 3 - Association in Property Graph Data Model - (Intersystems Caché is mentioned at this section)

Part 2 - Association in Topic Map Data Model

Part 1 - Relation, Relationship and Association

So what is the objective of writing in this community ? 

Well there is a two pronged approach,

• To promote the fundamental principles of R3DM/S3DM framework in the design of hypergraph-associative based DBMS
• To implement this technology on top of suitable DBMS.

What is the ultimate goal ?

The ultimate goal is to have a single operational database that acts as a unification platform for all data from other data sources and enables a 360 degrees self-service dynamic data visualization and analysis with any part of the database without ETL and without queries. 

What is the current status of R3DM/S3DM  ?

There are currently two implementations :

• A working prototype with OrientDB as the back-storage and Wolfram Language as the front-end API
• A partial implementation with Intersystems Cache as the back-storage and the construction of R3DM/S3DM subsystems and low-level commands with Cache ObjectScript.

In the sixth and last part of our series detailed information about the architectural design and API commands of R3DM/S3DM are exposed to the public. 

How you can help ?

You may actively take part in any discussion within this community about graph data modeling with Intersystems Cache. Make a start here. In particular, you may be interested in R3DM/S3DM project, then I suggest you get connected with me at LinkedIn.

I am also actively looking for partners and investors for this technology so perhaps you would like to discuss your role or contribution.

Vendors and experts of the database domain are interested in this project. This is encouraging but the plan of course is to reach production and deployment level and that is where they can help.