[orient-database] Production use of OrientDB, and a few other questions

[Alf]

Hi guys. First, thanks for developing OrientDB, it seems like a great
product. We are considering using it, but we have a few questions.

Do you know if the storage format will change from now until version
1.0? The reason I am asking is that the project we are doing will, be
in production within about 4 months, and we do not have control over
the install bases. That is, the software will be installed at multiple
clients and we don't have access to their production environments.
Hence we won't be able to do db migrations if necessary. I guess a
related question is if there is a road map for version 1.0, or is
there an approximate date for the release?

We are considering using OrientDB because of it's flexible licensing,
possibility of running embedded, and of course its performance
characteristics. The reason we would like for it to be embedded is
ease of installation for the clients. Most clients won't need to scale
very much, and for them easy installation and maintenance is key. For
the larger clients it would be nice to set up a db cluster without too
much hassle.

We plan on making two installation options for the clients, a war for
containers, and a jar (with embedded jetty) for standalone
installation. Which artifacts would we require to runt the key-value
server? The download contains:

* hazelcast.jar
* orient-commons.jar
* orient-database-core.jar
* orient-database-kv.jar
* orient-database-server.jar
* orient-database-tools.jar

We would like a minimal distribution, and hence we don't want to
include anything we wouldn't need. Perhaps documenting each artifact
and it's purpose on the wiki would be a good idea?

We think we will be using it as a key-value store. Is it problematic
running that embedded? Do we need to make and actual HTTP call using
the TCP/IP stack, or is there a shortcut for calling it locally? I
guess performane won't actually be in issue here, it just seems that
using it as a document db, you can actually do local calls.

Is there an way to query the key value store, except from using the
basic REST/HTTP mechanism?

The artifacts are not available in a maven repository (as far as I can
tell), any plans on doing that sometime soon? I guess it would be OK
for us to install it locally in our maven proxy?

One final question. Would it be a problem doing file based backup of a
running OrientDB instance? Since we don't have control over production
environments it would be nice for us to give the clients several
options for making backups.

Lots of questions in one post, hope that is OK. Thanks for your time.
Cheers,
Alf Kristian Støyle

[Luca Garulli]

On 29 April 2010 11:14:55 UTC+2, Alf <alf.kr...@gmail.com> wrote:

Hi guys. First, thanks for developing OrientDB, it seems like a great
product. We are considering using it, but we have a few questions.

 
Hi Alf

Do you know if the storage format will change from now until version
1.0? The reason I am asking is that the project we are doing will, be
in production within about 4 months, and we do not have control over
the install bases. That is, the software will be installed at multiple
clients and we don't have access to their production environments.
Hence we won't be able to do db migrations if necessary. I guess a
related question is if there is a road map for version 1.0, or is
there an approximate date for the release?

 
Yes, the format could change. This is the reason why we provide the "export" tool to export the database to being imported using last version of Orient. In this way you have to export with the running version & import with the new one in order to start using it. But please keep in mind that the format is never changed since we've published the public version, so I expect to be very very rare.

The roadmap is the issue list of the new features. We are using tags to mark the milestone where to release that feature.

http://code.google.com/p/orient/issues/list?can=2&q=db&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles

We are considering using OrientDB because of it's flexible licensing,
possibility of running embedded, and of course its performance
characteristics. The reason we would like for it to be embedded is
ease of installation for the clients. Most clients won't need to scale
very much, and for them easy installation and maintenance is key.

Yes, the embedded "local" version works inside the same JVM offering incredible speed.
 

For
the larger clients it would be nice to set up a db cluster without too
much hassle.

We're still working to the clustered version of OrientDB, while the Key/Value server is already clustered using thr Hazelcast library. But for the OrientDB the Hazelcast ways is not enought and we need to use & implement the best of features for the higher scalability and performance.

We plan on making two installation options for the clients, a war for
containers, and a jar (with embedded jetty) for standalone
installation. Which artifacts would we require to runt the key-value
server? The download contains:

Please keep in mind that the K/V server has a different model that OrientDB server and check if the bucket/key/value model is enought for you.
 

* hazelcast.jar
* orient-commons.jar
* orient-database-core.jar
* orient-database-kv.jar
* orient-database-server.jar
* orient-database-tools.jar

We would like a minimal distribution, and hence we don't want to
include anything we wouldn't need. Perhaps documenting each artifact
and it's purpose on the wiki would be a good idea?

 
Good idea! I'll update asap. For now I can tell you that the:
- to use it as embedded db you need to link about 450Kb as 2 files:

* orient-commons.jar
* orient-database-core.jar

We think we will be using it as a key-value store. Is it problematic
running that embedded? Do we need to make and actual HTTP call using
the TCP/IP stack, or is there a shortcut for calling it locally? I
guess performane won't actually be in issue here, it just seems that
using it as a document db, you can actually do local calls.

I've received a lot of requests to have:
- native API for the K/V together with HTTP ones
- use it as embedded db

I can definitely create a new feature request for it.
 

Is there an way to query the key value store, except from using the
basic REST/HTTP mechanism?

See above.
 

The artifacts are not available in a maven repository (as far as I can
tell), any plans on doing that sometime soon? I guess it would be OK
for us to install it locally in our maven proxy?

 
Not yet, but I can work on it.

One final question. Would it be a problem doing file based backup of a
running OrientDB instance? Since we don't have control over production
environments it would be nice for us to give the clients several
options for making backups.

 
Current export tool works on running instances, so YES.

Lots of questions in one post, hope that is OK. Thanks for your time.
Cheers,
Alf Kristian Støyle

No problem!

Hope to have answered to all your questions.

bye,
Luca Garulli

[Alf Kristian Støyle]

Thanks Luca, good answers to all my questions. But then there are a
few follow-ups :)

I am guessing the db-migration tool is also Java, and could
potentially be embedded in the application? It would be very nice to
be able check the version of the database on start up, and do
automatic migrations if necessary? Since we won't be there (on the
production site) to actually perform the migrations, and we don't want
the clients to mess up, it would be nice to be able to automate
migrations.

We really like the idea and flexibility of a key-value store, and I am
sure we will figure out a way to use bucket/key/value model to fit
with our problem. If not the document db seems pretty flexible as well
:) Anyhow a feature request, and implementation, for using local api's
to talk with the key-value db would certainly beneficial to us.

Is there any documentation on the backup tool yet? Couldn't find any
on in the installation of on the Wiki.

I have to say, that I find this product and its feature list
incredible. So I find it a bit strange that it is not yet more well
known in the community. Have you just recently open sourced it? From
the svn commit logs it seems the first commit was March 29th, but I am
guessing you have been working on it far longer than that.

Also I think you should provide a list of "Who is using it" for
further adoption, and perhaps some info about the team developing the
product.

Anyhow, thank you very much for your answers.

Cheers,
Alf

[Luca Garulli]

On 29 April 2010 15:19, Alf Kristian Støyle <alf.kr...@gmail.com> wrote:

Thanks Luca, good answers to all my questions. But then there are a
few follow-ups :)

I am guessing the db-migration tool is also Java, and could
potentially be embedded in the application? It would be very nice to
be able check the version of the database on start up, and do
automatic migrations if necessary? Since we won't be there (on the
production site) to actually perform the migrations, and we don't want
the clients to mess up, it would be nice to be able to automate
migrations.

The export tool is part of the console (orient-tools.jar) and it's written in Java. So it's callable directly from your application, but it needs to export the database using the old version of the engine, links the new jars, re-start the application and import the db.

I presume this could be done using Java Web Start technology and it's part of the auto-upgrade of your application.

 

We really like the idea and flexibility of a key-value store, and I am
sure we will figure out a way to use bucket/key/value model to fit
with our problem. If not the document db seems pretty flexible as well
:) Anyhow a feature request, and implementation, for using local api's
to talk with the key-value db would certainly beneficial to us.

The Key/Value db is written on top of the document dbms. Document dbms has powerful sql-query capabilities, native concepts of links (taken from graph db), etc. My suggestion is to use the document db unless you need extreme scalability (using the cluster) at the cost of keeping your model simpler (bucket/key/value).
 

Is there any documentation on the backup tool yet? Couldn't find any
on in the installation of on the Wiki.

Course: http://code.google.com/p/orient/wiki/ConsoleCommandExport
 

I have to say, that I find this product and its feature list
incredible. So I find it a bit strange that it is not yet more well
known in the community. Have you just recently open sourced it? From
the svn commit logs it seems the first commit was March 29th, but I am
guessing you have been working on it far longer than that.

 
The aim of Orient is to have a new generation DBMS with the best features of all others NoSQL engines. Yes, Orient is pretty new but has been built from the fast algorithms of the old "Orient ODBMS" (made in C++).

Also I think you should provide a list of "Who is using it" for
further adoption, and perhaps some info about the team developing the
product.

 
Yes, I should.

Anyhow, thank you very much for your answers.

Cheers,
Alf

bye, Lvc@

[Alf Kristian Støyle]

Thanks again for your answers. We are looking forward to getting our
hands dirty with OrientDB!

Cheers,
Alf