OrientDB: A new Open Source NoSQL DBMS(code.google.com)
code.google.com
OrientDB: A new Open Source NoSQL DBMS
http://code.google.com/p/orient
NoSQL document database light, portable and fast. Supports ACID Tx, Indexes, asynch queries, SQL layer, clustering, etc
4 comments
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'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.
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. :-)
Have a look at Riak. It scales up (and down) very well. And it's been in production use for a while now.
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.
The ability to handle transactions makes it very interesting to me, but your criticisms are valid.
It still seems a little too young a project for me to want to use. I will definitely keep an eye on it though.
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 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 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 transactional engine can run in distributed systems supporting up to 9.223.372.036 Billions of records"
I don't mean to be snarky or anything, but I fail to see what's so impressive about using 64-bit integers.
I don't mean to be snarky or anything, but I fail to see what's so impressive about using 64-bit integers.
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?
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.
But actually getting a document store on the client? A lightweight document store that supports complex object graphs?
I seriously see no point of this