

OrientDB: A new Open Source NoSQL DBMS - osmanizbat
http://code.google.com/p/orient
NoSQL document database light, portable and fast. Supports ACID Tx, Indexes, asynch queries, SQL layer, clustering, etc
======
mark_l_watson
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.

~~~
cturner

        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.

~~~
sjs
Have a look at Riak. It scales up (and down) very well. And it's been in
production use for a while now.

~~~
cturner
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.

~~~
sjs
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.

------
plq
"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.

------
linead
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?

~~~
TrevorBurnham
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.

~~~
linead
But actually getting a document store on the client? A lightweight document
store that supports complex object graphs?

------
Desireco
I seriously see no point of this

