Hi Mike, graph database support is not quite as easy as it seems. Unlike relational databases, graphs have not only defined vertices and edges (labeled vertices and edges), they are directed or not and might have attributes at the nodes and edges, too.
This makes it a bit confusing for a general interface. In general, a graph database should always be accessed via TinkerPop 3 (or higher), since every professional graph database supports TinkerPop. TinkerPop is for graph databases what jdbc is for relational databases. I tried to create a general NiFi processor for graph databases myself and then quit. Unlike relational databases, graph databases usually have many dependencies. You do not simply create a data set but search for a particular vertex (which may still have certain edges) and create further edges and vertices at that. And the search for the correct node is usually context-related. This makes it difficult to do something general for all requirements. In any case I am looking forward to your concept and how you want to solve it. It's definitely a good idea but hard to solve. Btw.: You forgot the most important graph database - Janusgraph. Mit freundlichen Grüßen / best regards Kay-Uwe Moosheimer > Am 12.05.2018 um 13:01 schrieb Mike Thomsen <mikerthom...@gmail.com>: > > I was wondering if anyone on the dev list had given much thought to graph > database support in NiFi. There are a lot of graph databases out there, and > many of them seem to be half-baked or barely supported. Narrowing it down, > it looks like the best candidates for a no fuss, decent sized graph that we > could build up with NiFi processors would be OrientDB, Neo4J and ArangoDB. > The first two are particularly attractive because they offer JDBC drivers > which opens the potential to making them even part of the standard > JDBC-based processors. > > Anyone have any opinions or insights on this issue? I might have to do > OrientDB anyway, but if someone has a good feel for the market and can make > recommendations that would be appreciated. > > Thanks, > > Mike
