You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by G M Abdul Salam <g....@gmail.com> on 2007/11/10 12:49:48 UTC
DerbyDB quality
sir,
I am in a big dilemma at the moment to decide whether to go for Derby DB or
PostgreSQL. Can you please kindly help me in answering my below query:
1. how good is DerbyDB when it comes for storing 1 - 2 million records in a
table
2. how good is it to handle multilingual content (Arabic and French)
3. how good it is with performance side for Java Web Application
we are in the process of building global web application and would like to
know if DerbyDB suits our needs. Your help and support is highly appreciated
Kind Regards,
Mohammed Abdul Salam, G
Re: DerbyDB quality
Posted by John Embretsen <Jo...@Sun.COM>.
Kurt Huwig wrote:
> It is caused by inserting millions of tuples into a table due to the
> necessary index split. And I guess the user somehow wants to get the
> records into the table and he has to make sure that noone queries the
> database while he insert the records.
Not that it helps, but my point was that you may run into this issue having no
more than a few thousand rows in the table (depending on the size of the indexed
data). As long as you are near the point when an index split needs to happen
(i.e. when a page is full?), I believe the main contributing factor is
concurrent reads and writes.
--
John
Re: DerbyDB quality
Posted by Kurt Huwig <k....@iku-ag.de>.
Am Montag, 12. November 2007 schrieb John Embretsen:
> Kurt Huwig wrote:
> > Several users - including me - are having problems with tables
> > containing a lot of records and concurrent INSERT and SELECT
> > statements which result in deadlocks. There is a issue filed
> > including a reproducing example which deadlocks Derby within a few
> > seconds:
> >
> > https://issues.apache.org/jira/browse/DERBY-2991
>
> This is a concurrency issue that you may run into in some use cases,
> but it is not an issue related to (caused by) having millions of
> tuples in a table.
It is caused by inserting millions of tuples into a table due to the
necessary index split. And I guess the user somehow wants to get the
records into the table and he has to make sure that noone queries the
database while he insert the records.
--
Mit freundlichen Grüßen
Kurt Huwig
GnuPG 1024D/99DD9468 64B1 0C5B 82BC E16E 8940 EB6D 4C32 F908 99DD 9468
Re: DerbyDB quality
Posted by John Embretsen <Jo...@Sun.COM>.
Kurt Huwig wrote:
> Am Montag, 12. November 2007 schrieb John Embretsen:
>> G M Abdul Salam wrote:
>>> 1. how good is DerbyDB when it comes for storing 1 - 2 million
>>> records in a table
>> Should not be problematic. In a large data volume test that was run
>> against the 10.3.1.4 release, there were three tables with ~300
>> million, ~232 million and ~8 million tuples, respectively (no issues
>> seen). For details, see
>> http://dbtg.thresher.com/derby/test/10.3.1.4_RC/AdditionalTests.html
>
> Several users - including me - are having problems with tables
> containing a lot of records and concurrent INSERT and SELECT statements
> which result in deadlocks. There is a issue filed including a
> reproducing example which deadlocks Derby within a few seconds:
>
> https://issues.apache.org/jira/browse/DERBY-2991
This is a concurrency issue that you may run into in some use cases, but it is
not an issue related to (caused by) having millions of tuples in a table.
> Unfortunaltely, there is no progress since August.
Yes, that is unfortunate. So far no one with the required expertise (or the
effort needed to become an expert in this area) has volunteered to work on this
issue.
--
John
Re: DerbyDB quality
Posted by Kurt Huwig <k....@iku-ag.de>.
Am Montag, 12. November 2007 schrieb John Embretsen:
> G M Abdul Salam wrote:
> > sir,
> >
> > I am in a big dilemma at the moment to decide whether to go for
> > Derby DB or PostgreSQL. Can you please kindly help me in answering
> > my below query:
> >
> > 1. how good is DerbyDB when it comes for storing 1 - 2 million
> > records in a table
>
> Should not be problematic. In a large data volume test that was run
> against the 10.3.1.4 release, there were three tables with ~300
> million, ~232 million and ~8 million tuples, respectively (no issues
> seen). For details, see
> http://dbtg.thresher.com/derby/test/10.3.1.4_RC/AdditionalTests.html
Several users - including me - are having problems with tables
containing a lot of records and concurrent INSERT and SELECT statements
which result in deadlocks. There is a issue filed including a
reproducing example which deadlocks Derby within a few seconds:
https://issues.apache.org/jira/browse/DERBY-2991
Unfortunaltely, there is no progress since August.
--
Mit freundlichen Grüßen
Kurt Huwig (Vorstand)
Telefon 0681/96751-50, Telefax 0681/96751-66
http://www.iku-ag.de/
iKu Systemhaus AG, Am Römerkastell 4, 66121 Saarbrücken
Amtsgericht: Saarbrücken, HRB 13240
Vorstand: Kurt Huwig, Andreas Niederländer
Aufsichtsratsvorsitzender: Jan Bankstahl
GnuPG 1024D/99DD9468 64B1 0C5B 82BC E16E 8940 EB6D 4C32 F908 99DD 9468
Re: DerbyDB quality
Posted by John Embretsen <Jo...@Sun.COM>.
G M Abdul Salam wrote:
> sir,
>
> I am in a big dilemma at the moment to decide whether to go for Derby DB
> or PostgreSQL. Can you please kindly help me in answering my below query:
>
> 1. how good is DerbyDB when it comes for storing 1 - 2 million records
> in a table
Should not be problematic. In a large data volume test that was run against the
10.3.1.4 release, there were three tables with ~300 million, ~232 million and ~8
million tuples, respectively (no issues seen). For details, see
http://dbtg.thresher.com/derby/test/10.3.1.4_RC/AdditionalTests.html
> 2. how good is it to handle multilingual content (Arabic and French)
Derby is Java and can store any Unicode character. Depending on your intended
meaning of the word "handle", I'm sure the experts will be happy to answer any
further questions...
> 3. how good it is with performance side for Java Web Application
I have not heard of any performance problems in this area. Of course, it depends
on your needs and usage patterns. (For example, using Prepared Statements is
usually recommended for performance reasons.)
Some results from a performance regression test against Derby is available here:
http://home.online.no/~olmsan/derby/perf/ - but that might not be what you are
looking for. I'll let others chime in on this if they have anything to share...
Feel free to ask further questions on the list - and we will be happy to know if
Derby works out for you or not!
--
John