Very good answer Taher thanks!
I plenty agree with you, just a 2 points inline
Le 10/07/2015 14:17, Taher Alkhateeb a écrit :
Hi Damon,
Okay, this makes your question bigger and harder to answer (to me at least) as
lots of PHDs go into this topic. I won't make a recommendation but you should
consider multiple factors in choosing your database. For example:
- Pure Java: I think most of the pure Java databases (Derby, H2, HSQL) are
embedded into applications even though a server exists for Derby for example.
This makes life easier for development and for shipping your application to
end-users but connection pooling becomes a problem and you cannot access your
database from outside your application while it is running.
- Size: embedded databases are usually very small so you can deploy them on
small devices. Apache Derby has a footprint of about 3 MB.
- Setup: again embedded databases require zero setup. You just write code and
go.
- Tool support: Apache Derby does not have GUI tools for example whereas MySQL
and Postgres have many powerful GUI and web DBA tools.
The Derby project recommends
http://db.apache.org/derby/integrate/SQuirreL_Derby.html
http://squirrel-sql.sourceforge.net/
It's not as obvious to use as pgAdminIII (for Postgres for instance) but I
found it pretty useful sometimes, mostly during development time
- Load Balancing: If you use a client-server DB like MySQL or Postgres then you
can load balance your application more efficiently and deploy your database
over the network.
- Features: I think the bigger systems like MySQL or Postgres support more
advanced features like row level locking and all kinds of indexes (especially
postgres)
- Speed & Scale: Lots of studies out there
Overall I usually choose Postgres out of concern for scale on enterprise
systems. I know that postgres was deployed on massive production systems but
cannot recall the same for Derby, H2 or HSQL and I don't want to make a bet on
a production system. I could be wrong though and I'm not an expert in this
area. I would love to hear the opinion of others.
Last time I used HSQL (long ago, years) it was not reliable as Derby is.
Jacques
HTH & Cheers
Taher Alkhateeb
----- Original Message -----
From: "damon henry" <[email protected]>
To: [email protected]
Sent: Friday, 10 July, 2015 2:51:19 AM
Subject: RE: Using Derby in Production?
Nothing to specific. I just realized that I had always been steered away from
using Derby without any solid evidence or reasoning to back it up. So I thought
I would ask the question.
As far as specific problems, I have had a few, but they were not at a point
that made them particularly worth troubleshooting. I do remember having some
problems using MS SQL Server so I struck that off the list. I have been
planning on using Postgres as I read that it is likely the most compatible and
what OFBiz was developed on, but then one of the Dev instances I have been
playing with suddenly developed problems writing records. Again I have not
taken the time to troubleshoot, because I am still at a stage where it is
easier just to spin up a whole new instance and get back to work :)
I am starting to plan a production system, so I thought I would ask the
question before committing to a standalone database.
thanksDamon
Date: Fri, 10 Jul 2015 01:16:20 +0300
From: [email protected]
To: [email protected]
Subject: Re: Using Derby in Production?
Hi Damon and everyone,
Is there a specific reason why you want Derby in production? Do you specifically need the
"embedded" part? And what is it that is problematic for you with stand alone
databases? Is it setup, administration, backup or what?
I think we can help you better if we understand your exact problem so answering
the above would give us a clearer picture.
Cheers!
Taher Alkhateeb
----- Original Message -----
From: "Ron Wheeler" <[email protected]>
To: [email protected]
Sent: Friday, 10 July, 2015 12:04:08 AM
Subject: Re: Using Derby in Production?
Derby is used in production.
http://osdir.com/ml/derby-user-db-apache/2014-01/msg00053.html
http://www.carehart.org/resourcelists/derby_for_cfers/#notdevonly
http://wiki.apache.org/apachecon/Us2005OnlineSessionSlides?action=AttachFile&do=view&target=ApacheCon05usDerbyPerformance.pdf
10 year old comparison of Derby and MySQL
http://wiki.apache.org/db-derby/UsesOfDerby from the Derby wiki
Testing under your forecasted production transaction load might give you
a better sense of which database system will give you adequate performance.
Ron
On 09/07/2015 12:09 PM, Pierre Smits wrote:
Damon,
We advice against the use of Apache Derby as the underlying RDBMS for
production environments. However, you can read up on how the developers of
that product think about how to use it at http://db.apache.org/derby/ .
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Thu, Jul 9, 2015 at 5:47 PM, damon henry <[email protected]> wrote:
Is there any rule of thumb or general wisdom about using the Derby
database engine in a production deployment? In previous enterprise systems
I have integrated, I have often used Derby during development, but then
migrated to a standalone database system before putting things in
production. I am working on my first OFBiz implementation and assumed I
would be going that route on this project as well, so tried a few different
standalone databases (mysql, postgres, MS SQL Server) with OFBiz, but to be
honest I am not seeing any clear advantage, and have in fact run into a few
issues with the stand alone databases. I also work for a much smaller
company now than I have in the past. This is not going to be a large
implementation, meaning it is not likely to host lots of simultaneous
connections, but once it gets put in place it may be in place for years and
accumulate lots of data over the lifetime. Is Derby up to the task? Has
anyone used Derby over a long period of time and found it to perform well.
thanksDamon Henry
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
