
Ask HN: Has anyone used a graph database? - brickcap
Specifically orient db? It seemed pretty interesting to me. I wanted to know if anyone has used it in production and if you liked it.<p>http:&#x2F;&#x2F;www.orientechnologies.com&#x2F;orientdb&#x2F;
======
beginrescueend
I've used OrientDB and ArangoDB, both being graph and document (JSON)
databases.

I had some initial success with OrientDB, under version 1.3. However, after
frustration with the documentation and frustration with having to completely
recode my app in version 1.4, I decided to look again. Versions 1.4 through
1.6 all had problems crashing doing bulk imports, so I gave up on it.

Now, I'm using ArangoDB and am pleased with documentation, stability, and am
liking AQL and Foxx (an API server included with ArangoDB).

While there are some things in OrientDB that don't yet exist in ArangoDB, I am
pleased with ArangoDB.

Try it here: [http://arangodb.org/](http://arangodb.org/)

~~~
brickcap
well I don't know about previous versions, as I only tired it first in 1.7,
but the documentation is fantastic. Maybe it was not so good for previous
versions.

Apart from bulk inserts what other problems did you face. If you don't mind
answering why should I consider orient db over arango db?

~~~
beginrescueend
Databases, of course, are complex software, with a long list of pros and cons.
I prefer ArangoDB over OrientDB, after a multi-month evaluation of both. (I
also considered Neo4J but could not afford it, in production, so it
unfortunately never got a fair evaluation).

As I mentioned earlier, in OrientDB, be careful using the eSQL syntax "INSERT
INTO" and "UPDATE ... SET ..." for graphs, unless you are doing things 1
record at a time. Bulk inserts will cause an out-of-memory crash, as of
version 1.4+. (I have never crashed ArangoDB, including performing 150M JSON
bulk imports).

In OrientDB, "CREATE VERTEX" has a very different syntax than "INSERT INTO"
(and "CREATE EDGE" is very different than "UPDATE ... SET ..." when you add
graph relationships to existing data). Because of this, I don't find that the
eSQL stuff is very useful for more than simple queries.

You can do JSON REST Bulk inserts which are very fast, but I find that
creating graph relationships that way in OrientDB is challenging, unless you
know the ID (###:###) of a vertex. This can be determined programatically, of
course. ("UPDATE ... SET ..." when it worked in 1.2 / 1.3 was much easier).

Oddly, the /etc/init.d/ scripts seemed broken on the Linux version of OrientDB
-- they don't stop the database and are odd to configure. This should be
easier (versions 1.2 through 1.6).

I have mixed feelings about using the Java JVM for OrientDB, as opposed to
native C/C++ used by ArangoDB. (My personal preference leans toward native
C/C++.) ArangoDB seems very light-weight and responsive all the time,
including startup.

Again, documentation was hard-to-find and inconsistent, as of OrientDB
1.5/1.6, but it does seem to have improved since then...

Finally, in my experience, eSQL (OrientDB) does not seem like a logical choice
for JSON Documents or for Graphs. AQL (ArangoDB), after you get used to it,
does seem to be designed for key-value pair queries, graphs, and documents,
but it's query-only. (In ArangoDB, I actually like coding in JavaScript,
mixing a bit of AQL in, when needed).

Otherwise, I really liked OrientDB, at the time I evaluated it; I was actually
hoping to stick with it. Overall, OrientDB has more features. The OrientDB
team, also seems VERY responsive to requests. (I haven't needed to reach out
to the ArangoDB people, yet, since I have been able to figure out everything
myself, so far).

Both OrientDB and ArangoDB _are_ in a state of flux. New features and bug
fixes are being done, all the time.

OrientDB seems like a logical choice to replace SQL databases or for Java
developers (for graphs and JSON documents). ArangoDB seems like a logical
choice to replace MongoDB or for JavaScript developers (for graphs, JSON
documents, and key-value pairs). OrientDB seems designed for scalability and
flexible schema design. ArangoDB should be more scalable, soon (promised in
ArangoDB 2.0).

Back to the issue of query languages... There are other query options.... Both
have Gremlin / TinkerPop. If you're used to that and like it, both OrientDB
and ArangoDB are essentially on equal footing, query-wise.

Looking back, I probably should have tried out Gremlin, whatever choice I
made, during my evaluation of OrientDB vs. Neo4J vs. ArangoDB.

For both OrientDB and ArangoDB I hope for Cypher (Neo4J's native query
language) and for JSONiq (somewhat similar to ArangoDB's AQL, actually) as
query language options.

~~~
brickcap
Many thanks for your detailed response. I have no experience with AQL but the
orient db devs say that they chose SQL because most developers were already
familiar with it. Personally I would like the graph databases agree on one
query language be it cypher, aql or gremlin.

When I was first looking into graph databases the different query languages
caused a lot of confusion.

Your comments are very insightful but they have only made the decision harder
for me :( One on hand I have invested some time into orient db and I think I
am grasping concepts of it well on the other it seems that it requires some
care. But my use case does not require bulk inserts so I guess I will stick
with it for now and keep my eye on arango db.

~~~
beginrescueend
You're welcome! :-)

Yes, if there was a standard query language for NoSQL, that would be
priceless.

Gremlin appears to be closest thing, today. I like what I've seen with JSONiq,
though...

This seems like a good somewhat related link:
[http://stackoverflow.com/questions/12043086/graph-dbs-vs-
doc...](http://stackoverflow.com/questions/12043086/graph-dbs-vs-document-dbs-
vs-triplestores)

------
brickcap
An Update : A lot of people are using orient db as seen from the client list
on the official[1] website but there are no posts regrading the "orient db
expereince"

So I downloaded it and gave it a try last night here are my impressions so
far.

1\. It has got an awesome documentation for both first time users[2] and those
looking for in depth understanding[3] of orient db.

2\. It is very easy to pick up. A no brainer installation, a familiar query
syntax and a small api make it easy to pick up even if you have never
experienced a graph db before.

3\. It has clients in popular languages + an http api. I see that there is no
client for erlang yet so I am planning to write a small http erlang client for
it.

4\. The default console client that orient ships with is very easy to use.

That is about it for the moment. I can't believe I missed this database
before. I plan to write a few blog posts covering the use of orient db. My
first impressions are positive and I am going to use it in a new project.

I would love to hear some thoughts of people who have been using orient db for
a while (assuming they find this thread)

[1]([http://www.orientechnologies.com/](http://www.orientechnologies.com/))
[2]([http://www.orientechnologies.com/getting-
started/](http://www.orientechnologies.com/getting-started/))
[3]([https://github.com/orientechnologies/orientdb/wiki#reference...](https://github.com/orientechnologies/orientdb/wiki#reference-
documentation))

------
beaglebone
yes. I used RDF with owl ontology to define the semantics of the data.

~~~
brickcap
I see. Can you share some more detail about your data model?

