| NoSQL support with TinkerPop [message #1716015] |
Mon, 30 November 2015 15:22  |
 Georgi Pavlov
Messages: 39
Registered: October 2014 |
Member |
|
|
Hi Dirigibles,
Apache TinkerPop is a set of blueprints (and a community by some claims) for graph applications. Without being an official standard or something, it standardizes the handling of graph data and computations on it allowing abstraction of concrete technology providers and sharing common best practices. In fact, by now there is quite some adoption for example as far as graph NoSQL databases are concerned. For example, the top 3 popular graph storage systems are compliant:
# Neo4j
# Titan
# OrientDB
Details can be found on the project page: http:// tinkerpop.incubator.apache.org/ and documentation: http:// tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#implementations
But the very brief intro is that when you have a compliant system, you can start a Gremlin console, connect to it, and using a standard API you can create a graph, manipulate it and traverse it.
With a Gremlin server (available in Tinkerpop 3.x , or Rexter in case of Tinkerpop 2.x) there is also a REST API for a number of operations too.
All that is quite, quite simplified. There is a myriad of things you can do for example only in the area of graph traversal (http:// tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/#traversal)
How does that concern Dirigible? Currently, Graph DBs are in their top hype according to Gartner's analyses largely because of the large potential in uses with BigData analytics. We definitely should explore integration options as this may be the next big thing in the Dirigible evolution!
At a glance, I can speculate about adopting Gremlin as a standard language/API for handling NoSQL graph databases and experimenting with OrientDB's value propositions (which by the way provides an SQL-ish query language too) for graph and document store (with a friendly Apache license unlike Neo4j). MongoDB is also quoted as Tinkerpop 2.x compliant so it could provide an alternative document store (in addition to OrientDB) by popular demand.
I can see quite of a showcase for example with Gremling directly into a groovy or javascript service with an injected API! Or maybe even eliminating completely the business logic implementation in the middle layer and developing more data-centric service apps?
Anyone interested in exploring opportunities of provisioning OrientDB (Apache license, http:// orientdb.com/) with Dirigible and figuring out how deeply can we mix the two systems for what applications and benefits?
|
|
|
| Re: NoSQL support with TinkerPop [message #1716101 is a reply to message #1716015] |
Tue, 01 December 2015 09:58  |
Eclipse User |
|
|
|
Hi Georgi,
This is great idea!
So far we have not explored the noSQL databases usage in Dirigible, but it will be very valuable to developers to have such a feature. There could be many use-cases from the general purpose usage of noSQL in the Dirigible's applications as a different kind of datasource, thru kind of execution engine (?), to internal usage for e.g. Repository implementation.
It will be interesting to see how the noSQL related Injected API would look like.
Regards,
Nedelcho
|
|
|
| Re: NoSQL support with TinkerPop [message #1716105 is a reply to message #1716101] |
Tue, 01 December 2015 10:26 |
Georgi Pavlov
Messages: 39
Registered: October 2014 |
Member |
|
|
Cool! Let's get down to it then. Here's a small roadmap sketch of how things could evolve. Let me know if you have comments and suggestions.
1. Provide Orient DB dialect for the SQL service
Motivation: With this fast-track integration, I would like to check if I can access the graph DB at all and if I can play with it using the available SQL tools in dirigible.
2. Provide a Gremlin Service (execution engine) and expose Gremlin API
Motivation: I would like to develop Graph DB-centric apps in a DB agnostic manner
3. Provide a Gremlin Service (execution engine) and expose Gremlin API
Motivation: I would like to develop Graph DB-centric apps in a DB agnostic manner
4. Expose Blueprint injected API
Motivation: I would like to have a standard injected API for Graph manipulations and query directly in my apps
5. Provide stored procedures artifact per DBType for multiple (active) DBs
Motivation: I would like to be able to store OrientDB functions and RDBMS stored procedures and invoke as required. This is a larger, system-wide refactoring.
a. Companion metadata version, language (java, pl-sql, js,..)
b. Specific file extensions.
6. Project dependencies
Motivation: I can design my app on one Dirigible instance and deploy on another so I need to check that all dependencies are intact, e.g. if I have the right database active. This is a larger, system-wide refactoring. Maybe not necessarily related to this particular topic but becoming important with the projected abundance of database types and vendors.
a. Modules compliance check by their metadata
b. Injected services API check
c. Injected services API check for concrete implementors availability (if I have a stored procedure for Postgre I need precisely Postgre RDBMS and not just RDBMS)
[Updated on: Tue, 01 December 2015 10:28] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.04117 seconds
] 
Search
Help
Register
Login
Home
