Neo4j

Started by Phil Beauvoir, August 26, 2014, 07:51:51 AM

Previous topic - Next topic

Phil Beauvoir

I'm interested in looking at Neo4j again for ArchiMate persistence.

The idea originated from Olivier Rey, in the old forums:

QuoteThe ultimate storage for Archimate is Neo4j the graph database.

In one shot, you solve many problems:
-Archi becomes scalable with a performance not based upon model size;
-Archi becomes team enabled;
-We can query the models in Cypher and perform advanced analysis.

With this persistence layer, both Archi and Neo4j can make an annoucement and provide the most straightforward and powerful product ever.

Have a look at it guys, it is worth the shot.

Bye,
Olivier

And in this LinkedIn thread:

QuoteTake a look at Neo4j database. The use of this storage to persist Archimate models would enable easily:
-scalability (a view is a one depth request inside the DB) and requests are not dependent on the size of the model;
-team support (due to ACID support, team support is built in);
-easy impact analysis and reporting (using Cypher language for instance);

Using a graph database would enable the hard-to-implement following functionality:
-model annotations and comments,
-workflows on models, where some lead architect can validate the main repository updates,
-easy models comparison and fusion
-management of a huge repository of models,
-sharing of some common objects that were validated by a specific workflow but which "outgoing" structure cannot be modified without the lead architect validation,
-project spaces in which teams can create temporary models using sharing validated objects and relation instances,
-alternate architecture scenario management,
-etc.

Graph databases seem to open new ways of seeing things, especially for Archimate model persistence and management. Any opinions?



If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

fajar

How's that compare with CDO?
Is there any IStore implementation in CDO for Neo4j?

Phil Beauvoir

Quote from: fajar on August 29, 2014, 21:55:55 PM
How's that compare with CDO?
Is there any IStore implementation in CDO for Neo4j?

I don't know enough about it at this stage. You may be interested in Neo4EMF:

http://neo4emf.com/
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

kdwykleingeld

Hi, this would really be great!. I was already preparing a sample data set (based on an archi csv export)  for neo4j import (through its jexp batch importer) so that i can do some cypher querying .. storing the data natively in a graph database would prevent that step...
reg koen

Bart Ratgers

#5
I think the adoption of Neo4j is step forward for market adoption and gives you also another possibilities. For the long term it gives you the possibility to adopt another parts of the TOGAF repository concept. For example adopt a discussion log (for example by adopting standard eclipse plugins) or add Reference libraries and Standards Information base. I'm not sure if this matches the ideas of Phill, but I think with these enhancements it must be possible to create a tool that support the architecture process of a company.

Jean-Baptiste Sarrodie

@All,

Can someone explain me the real (not marketing) advantage of using Neo4J ?

I must admit that for the moment I only see it as another DB to persist model, but I see absolutly no advantages over "classic" SQL DB. I also fear that really few people would learn its specific query language.

Is it only a geek thing or do I really miss something ?

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

For me it sounds interesting for its own sake. The main thing is ACID.  :)

And much faster for querying on relationships rather than usual Join type queries.

It's not something I'm necessarily endorsing for Archi, it just looks quite cool.  8)
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

Quote from: Phil Beauvoir on September 09, 2014, 10:02:52 AM
For me it sounds interesting for its own sake. The main thing is ACID.  :)

SQLite is ACID too ;-)

Quote
And much faster for querying on relationships rather than usual Join type queries.

I'm not against speed, but I'm not sure this is a key point in our usage.

Quote
It's not something I'm necessarily endorsing for Archi, it just looks quite cool.  8)

Thus the "geeky" part of my remark ;-)

To be clear, I'm not against Neo4j, it's just I don't understand its real power (yet?).
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

Quote from: Jean-Baptiste Sarrodie on September 09, 2014, 12:24:34 PM
To be clear, I'm not against Neo4j, it's just I don't understand its real power (yet?).

That's how I feel. I have an interest in it from the point of view of the "Archi R&D department".
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Bart Ratgers

I think the biggest advance to use neo4j as storage engine (or another form of document or graph database) is the flexibility and scalability in a larger environment. You can easily create a cluster environment with an increased availability and performance. If you existing data doesn't  require a relational database then a document or a graph oriented database (NoSQL) are good alternatives.


Another advance I see is the re-use of an existing library and solution. I think that beside the storage engine a lot of work needs to be done to manage the integrity of the complete model and signaling when more users are working together on one project.


I have some experiences as architect (and not as software developer) with the use of NoSQL storage engine, and the ease of management and scalability are big pros. 

techlogix

In enterprise environments it would be possible (easier) to write a more performant Visualizer outside the IDEs. E.g. a single page application that could navigate like a visualizer in a read only made on a web-site with very high performance.

dknol

I've started to investigate the usage of EMFStore from an Archi plugin. I am able to store the model, including changes.

EMFStore should be one of the easiest ways to accomplish shared working, versioning etc.

What I've done is to create a EMFStore "project" and attach the archi model. This basically works, but there are issues with ID's and at some point (no clue why or how) the archi model is corrupt when I want to save it.

I can share my code if someone is interested.

Jean-Baptiste Sarrodie

Quote from: dknol on September 26, 2014, 17:46:29 PM
I can share my code if someone is interested.

Hi, That would be great. I can create a git repository under https://github.com/archi-contribs and provide you right on it. If you're OK, I would suggest "archi-emfstore-plugin" as repository name and "org.archicontribs.emfstore" as base for code (not mandatory at all, just a proposed convention if you don't have one already).

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

adeze

by leveraging the archimate exchange format (https://www2.opengroup.org/ogsys/catalog/S142), and the code from the plug in, a lot of the work conceptually has been done-- all thats needed is a mechanism to CRUD the nodes in neo4j.
i've been contemplating the analysis of models for quite a while, and whilst the queries could be very clever, you could also consider syncing with a CMS like structr.org as the analysis tool/viewer, rather than a static report.