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 |
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 <[hidden email]> 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 |
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 <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
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" <[hidden email]> To: [hidden email] 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 <[hidden email]> 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: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
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: [hidden email] > To: [hidden email] > 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" <[hidden email]> > To: [hidden email] > 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 <[hidden email]> 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: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
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. - 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. HTH & Cheers Taher Alkhateeb ----- Original Message ----- From: "damon henry" <[hidden email]> To: [hidden email] 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: [hidden email] > To: [hidden email] > 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" <[hidden email]> > To: [hidden email] > 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 <[hidden email]> 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: [hidden email] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > |
Administrator
|
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" <[hidden email]> > To: [hidden email] > 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: [hidden email] >> To: [hidden email] >> 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" <[hidden email]> >> To: [hidden email] >> 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 <[hidden email]> 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: [hidden email] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> > |
Free forum by Nabble | Edit this page |