db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pouttu-Clarke <Matt.Pouttu-Cla...@icrossing.com>
Subject Re: Inaccuracies in H2's claims: Autocounter/Sequqnce-Numbers
Date Wed, 25 May 2011 15:41:03 GMT
In embedded mode I definitely found that H2 was faster than Derby for reads
on a single-threaded workload.  However, embedded H2 only supports a single
thread to run statements and does not support concurrent thread access.  So
when I added multiple threads on a multi-core box Derby scaled linearly
while H2 remained the same.  I am building a shared-nothing architecture
where scalability and performance of the system gears mostly on sharing
cache memory between threads on a multi-core box to reduce I/O hits and
network serialization.  So in my use case Derby wins hands down.

For other use cases we will most likely find various results.

However, I have to say that the blanket statements made on the H2 site have
lead to a misperception on the part of the user community that H2 is
generically faster than Derby (at least among people I have met).  It made
it quite difficult for me to justify running our own independent benchmark
to management when they were looking at the benchmark on the H2 site.

It's actually kind of strange (and disappointing) to see this kind of
one-upsmanship going on in the open source world.  Maybe I'm naive but I
thought blanket statements and whitewashing were the exclusive domain of
commercial software!

Cheers,
Matt

On 5/25/11 2:28 AM, "Bernt Marius Johnsen" <bernt.johnsen@oracle.com> wrote:

> Hi,
> 
> There was some rounds on this with the H2 guy on this some years ago
> too. Back then the claim on e.g. limit/offset where correct btw., so it
> was basically the performance claim that was the topic. But they did not
> seem to want to correct that claim.
> 
> I also find the PolePosition "benchmark" a bit dubious.
> 
> 
> On 05/25/2011 11:02 AM, Lukas Eder wrote:
>> I have been following this thread curiously and raised the question on
>> the H2 user group:
>> 
>> http://groups.google.com/group/h2-database/browse_thread/thread/bc712e8607ab0
>> 73b
>> 
>> 2011/5/25<Malte.Kempff@de.equens.com>:
>>> 
>>> May be the Article used an older version of derby. T's a pity that they
>>> don't say what version were used for comparison.
>>> 
>>> 
>>> -----Urspr√ľngliche Nachricht-----
>>> Von: Rick Hillegas [mailto:rick.hillegas@oracle.com]
>>> Gesendet: Dienstag, 24. Mai 2011 20:12
>>> An: Derby Discussion
>>> Betreff: Inaccuracies in H2's claims: Autocounter/Sequqnce-Numbers
>>> 
>>> There seem to a number of mis-statements on this page:
>>> 
>>> o The performance claim.
>>> 
>>> o The claim that Derby doesn't have an "Explain plan" feature.
>>> 
>>> o The claim that Derby doesn't support user-defined datatypes.
>>> 
>>> o The claim that Derby doesn't support sequences.
>>> 
>>> o The claim that Derby doesn't support limit/offset.
>>> 
>>> o The claim that Derby doesn't support case-insensitive columns.
>>> 
>>> On 5/24/11 10:02 AM, Tim Dudgeon wrote:
>>>> It was not me who said Derby is slow. I'm using it in embedded mode
>>>> all the time and performance is great.
>>>> I was just pointing out that others are saying things that seem to be
>>>> wrong, and some action might be wanted.
>>>> 
>>>> Tim
>>>> 
>>>> On 23/05/2011 17:00, Matt Pouttu-Clarke wrote:
>>>>> Tim,
>>>>> 
>>>>> Does H2 allow multiple concurrent threads to update the database?
>>>>> I'm not
>>>>> sure it's fair to compare a single threaded database to a multi-threaded
>>>>> database with a single threaded workload.
>>>>> 
>>>>> I have done benchmarks that show that Derby is much faster than H2
>>>>> with a
>>>>> multi-threaded workload in embedded mode.
>>>>> 
>>>>> Cheers,
>>>>> Matt
>>>>> 
>>>>> 
>>>>> On 5/21/11 3:56 AM, "Tim Dudgeon"<tdudgeon@informaticsmatters.com>
>>>>> wrote:
>>>>> 
>>>>>> There are some other things here that might deserve some comment:
>>>>>> http://www.h2database.com/html/features.html#comparison
>>>>>> 
>>>>>> e.g. performance of embeded derby is slow!
>>>>>> 
>>>>>> Tiim
>>>>>> 
>>>>>> 
>>>>>> On 18/05/2011 16:05,
>>>>>> Malte.Kempff@de.equens.com wrote:
>>>>>>> Hi to all,
>>>>>>> 
>>>>>>> in http://www.h2database.com/html/features.html#feature_list
I found
>>>>>>> this particular statement to above topic:
>>>>>>> 
>>>>>>> *Sequence*and autoincrement columns, computed columns (can be
used for
>>>>>>> function based indexes)
>>>>>>> 
>>>>>>> Later on is a matrix that shows some RDBMs in releation to some
>>>>>>> features
>>>>>>> where it is denied that Derby supports sequences.
>>>>>>> 
>>>>>>> So what is actually the case? And if Derby supports running numbers
>>>>>>> (in
>>>>>>> Oracle they are called /sequences/, in Microsoft DBs the are
often
>>>>>>> called /auto counters/) how are they to be used.
>>>>>>> 
>>>>>>> Thanks in advance for any hint
>>>>>>> 
>>>>>>> Malte
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> iCrossing Privileged and Confidential Information
>>>>> This email message is for the sole use of the intended recipient(s)
>>>>> and may contain confidential and privileged information of iCrossing.
>>>>> Any unauthorized review, use, disclosure or distribution is
>>>>> prohibited. If you are not the intended recipient, please contact the
>>>>> sender by reply email and destroy all copies of the original message.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
> 


Mime
View raw message