OrientDB 1.7 is out | Hacker News Reader

OrientDB 1.7 is out

orientechnologies.com

46 pointsSanderMak15 comments

The last time I tried OrientDB was about 2 years ago. I really liked the idea of an all Java DB. But somehow I could not get it work the way I wanted and struggled with the lazy/eager loading.

I guess now is a good time to try it again and see how it goes.

I've been a fan of orient for a while, although I have never actually used it. IMHO, graph features are pretty critical for a document store to be very useful. With full text search and extensible schemas, Orient has a very unique and kick-ass design.

As much as I know about it, I have never actually used it. I want to play with it, but I don't want to bother with all of the necessary sysadmin.

Does anybody offer OrientDB as a service?

Orient themselves used to offer a hosted service, but they shut it down. IMHO there are some things that need to be ironed out before a hosted version is really viable.

In terms of sysadmin, it works pretty well out of the box for all but the hugest of datasets and busiest sites, and the configuration is well documented. It's no more difficult to set up than mysql for instance.

I notice that a Lucene-powered index is now included. I can see from the git repo's wiki how to structure a query, but what seems to be missing is how to return, or sort using, relevance information.

Can you chime in on how that works?

Is the documentation any better now? It was confusing when I tried to use before.

it's improving, but is still very focussed on the official Java client. Would expect this to get better before 2.0 comes out.

It's fantastic. One of the areas where it has improved by leaps and bounds is in the documentation of it's "sql" like query language.

The tcp api and the http api are well documented as well. And if you are learning to use orient db for the first time. The getting started guide, and the wiki on main concepts is great and you will get up to speed pretty quickly. There are 240 pages(!) in the wiki so it is pretty exhaustive in case you need to know about orient db more ddeply.

Where I feel it lacks is in the documentation of client libraries. since orient db could be used both using http and the client libraries I was not sure which one would be the best choice. I had a good experience using the http api in couchdb and elastic search so my first instinct was to use that but I am still not sure if it is the right way?

Any way I think the orient db documentation is fantastic but it could do with better organization and probably some tips from devs on how to use it best. If I ever need a graph database I am definitely using orient db.

As a side note I think orient db's reputation of a graph database might be doing it more harm than good since it is really much more than that. It can save data as documents, build relationships on them and even do full text search. I think the orient db guys should focus efforts on marketing other aspects of orient db (like the awesome sql language) besides the graph part.

Regarding the choice between the REST API and the binary protocol - it depends :) If you're using a client library that supports the binary protocol it's probably worth using that because it exposes every feature of orient and it's the more efficient option. However, if you're writing a client library from scratch, you'll find the REST version a whole lot simpler to implement - the binary protocol has a few awkward edge cases. There are actually some hidden gotchas with both the binary and REST transports, but they are not show stoppers and they're being actively worked on.

Disclaimer: I wrote a client library for node.js[0] and am in the process of writing one for php[1].

[0] https://github.com/codemix/oriento

[1] https://github.com/codemix/php-orientdb

For those wondering, this is a variant on the MongoDB document database approach... http://www.orientechnologies.com/orientdb-vs-mongodb/

It's not really fair to call it a variant of Mongo's approach, OrientDB is an SQL powered, NoSQL document-graph database which can model relationships without requiring joins. It's quite different from Mongo in many ways.

Arguably OrientDB is the only data store on the market which actually matches the web's data model - Documents + Links.

So does that make it similar to Neo4j? Or is this more of a hybrid document database with graph capabilities?

it's also quite different from Neo4j which is a graph only database and is poor at representing normal documents. Neo4j is also very expensive if you want to use it in a cluster, whereas OrientDB imposes no such restrictions.

Orient is definitely a hybrid - it was a document database before it became a document-graph database, but I believe it can still do everything that n4j can. One of the nicest things about it is that it is object oriented - you can define classes and then extend them, something you cannot do in mongo or any RDBMS that I know of. This makes it very simple to use, because the database structure can accurately reflect your application class structure, without any need for leaky abstractions such as ActiveRecord.

Nice! I'll definitely look into it in my next project.

I'd say its a document database with direct links between documents, which can be quickly and easily traversed like a graph database.

The graph API that OrientDB exposes (the TinkerPop api, basically) seems to be built almost as a convention of which links should exist, on top of the document database.

OrientDB is very flexible and powerful because of this: representing your data as linked documents feels really natural.

I've been using RethinkDB lately, and I love it, but having used OrientDB previously, I find the lack of direct links between documents makes for complex and awkward nested queries. I'll continue to happily use RethinkDB, but I'm also eagerly watching OrientDB's progress and expect I'll be using it some more soon.

While in some ways quite different from Mongo, it's also used for many of the same purposes. Hence my comment, and hence the article I referenced. The goal of my comment, btw, was to provide some context for the top link, which didn't really describe what the product was; I didn't intend to have anyone think I was disparaging either product.

OrientDB can do some things that Mongo cannot (as you mention, SQL access, and the great linking), but when I have seen Orient used, it's in an almost interchangeable way to how one would use Mongo (ie, folks not using the linking and leveraging the SQL just to ease querying). So, variant may not be the right word, but it's an open source NoSQL document oriented datastore, like Mongo, with the additional features you refer to which, for some use cases, make it a superior offering.

Reply on news.ycombinator.com