It looks interesting enough, and the sort-of SQL language looks OK, but I have to ask: why would anyone use a young project (with only one developer?) rather than something really well supported like MongoDB or Cassandra? That said, interesting looking work.
why would anyone use a young project (with only one
developer?) rather than something really well
supported like MongoDB or Cassandra
I don't know either of the systems you mention - and should have a look into them. I have some experience with couchdb.
I've got an app in mind, and have some experience with couchdb but not with the systems you mention.
Orient interested me because I'm constantly on the lookout for something with these features:
* Key/value database.
* Straightforward to install on linux and darwin.
* Able to push data into it through high-bandwidth
* Queries give result sets that are reliably correct for a moment in time.
* Doesn't take up large amounts of disk space.
* Straightforward to get started with and evaluate without large time investment.
Couch fails a few of them, but I didn't know they were requirements until I'd started playing with it.
Orient seems to be very easy to set up, and supports a binary input protocol which might be faster than the HTTP drop mechanism I've been using against couchdb.
Thanks. I've had a look and from what I can see insertion is by HTTP or JSON only, and not over persistent connection. I expect this will be too slow for the volume of data I have.
Ah yes that's true. You can use Protocol Buffers but still over HTTP. You'd have to use Erlang to get around HTTP, which obviously won't work for everyone.
Other option may be BerkleyDB/Java. It should be pretty easy to get started. In terms of querying things may be a bit more difficult (as for any KV store), but as far as I remember there are ways to programmatically define secondary indexes. (note: I'm not affiliated with Oracle/Sun/Berkley/etc. :-)
I did not really intend to be too critical: I would never discourage someone from doing a major open source project because just the learning experience is rewarding enough for the developer.
I will keep an eye on it also, especially if there are nice Clojure and JRuby wrappers.
I would be more enthusiastic but all of my current needs are very well met using PotgreSQL, MongoDB, and either AllegroGraph or Sesame as RDF data stores.
I came across OrientDB a week ago, while looking for a Document DBMS that could be embedded in a client side application. Sadly haven't had time to fully check it out yet, but it looked the most promising of the options out there.
The Java/Hibernate pattern seems to be common for java applications, but there's doesn't seem to be (as far as I can see) for a document/object based alternative. I'm currently working with an object graph that translates very poorly to a relational DB, does anyone have any experience with any non-relational alternatives?
There are a ton of JSON stringifications libs for Java, some of which can handle complex object graphs (circular dependencies, etc.). Have a look at Google GSON. Once you can turn your jobs into JSON strings and vice versa, persisting them in a document store should be trivial.
13 comments
[ 2.7 ms ] story [ 36.4 ms ] threadI've got an app in mind, and have some experience with couchdb but not with the systems you mention.
Orient interested me because I'm constantly on the lookout for something with these features:
* Key/value database.
* Straightforward to install on linux and darwin.
* Able to push data into it through high-bandwidth
* Queries give result sets that are reliably correct for a moment in time.
* Doesn't take up large amounts of disk space.
* Straightforward to get started with and evaluate without large time investment.
Couch fails a few of them, but I didn't know they were requirements until I'd started playing with it.
Orient seems to be very easy to set up, and supports a binary input protocol which might be faster than the HTTP drop mechanism I've been using against couchdb.
It still seems a little too young a project for me to want to use. I will definitely keep an eye on it though.
I will keep an eye on it also, especially if there are nice Clojure and JRuby wrappers.
I would be more enthusiastic but all of my current needs are very well met using PotgreSQL, MongoDB, and either AllegroGraph or Sesame as RDF data stores.
The Java/Hibernate pattern seems to be common for java applications, but there's doesn't seem to be (as far as I can see) for a document/object based alternative. I'm currently working with an object graph that translates very poorly to a relational DB, does anyone have any experience with any non-relational alternatives?
I don't mean to be snarky or anything, but I fail to see what's so impressive about using 64-bit integers.