Re: [h2] H2 database on multiple threads/cores

2013-11-11 Thread Adam McMahon
Noel,
 
As always, thanks for your insights.  It is good to know that H2 at its 
cores is single threaded while at the same time multithreaded at outer 
layers. , this will help me as I think about my design.  
 
SSD is a good option, looking to use Digital Ocean 
https://www.digitalocean.com/.  Good SSD, but it only scales CPU via more 
cores not time slices (as opposed to http://www.linode.com)   I have a 
hunch this mutli core scaling is not the best option for H2.  But overall 
seems like nice service, and my hunches are often times wrong  :)
 
-Adam
 

On Sunday, November 10, 2013 4:16:28 AM UTC-5, Noel Grandin wrote:

 The short answer is that it's complicated. 

 You're probably better off creating some performance tests for your 
 application and testing them out on the various options. 
 Since the answers will vary depending on how your application uses the DB. 
 For database applications I would recommend you pick the provider that 
 supplies SSD storage. 

 The longer answer is that H2 is composed of multiple layers. The 
 lowest layer is single-threaded, but the layers and caches above that 
 are multi-threaded, and since a lot of queries spend a lot of time 
 processing data, rather than reading/writing to the disk, we actually 
 get a fair amount of parallelism out of our architecture. 


-- 
You received this message because you are subscribed to the Google Groups H2 
Database group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [h2] H2 database on multiple threads/cores

2013-11-10 Thread Noel Grandin
The short answer is that it's complicated.

You're probably better off creating some performance tests for your
application and testing them out on the various options.
Since the answers will vary depending on how your application uses the DB.
For database applications I would recommend you pick the provider that
supplies SSD storage.

The longer answer is that H2 is composed of multiple layers. The
lowest layer is single-threaded, but the layers and caches above that
are multi-threaded, and since a lot of queries spend a lot of time
processing data, rather than reading/writing to the disk, we actually
get a fair amount of parallelism out of our architecture.

-- 
You received this message because you are subscribed to the Google Groups H2 
Database group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.


[h2] H2 database on multiple threads/cores

2013-11-09 Thread Adam McMahon
Hi H2 Group,

I am trying to get my head around H2's use of multiple threads and cores. 
 I know this topic has been dealt with before, but I am still a little 
confused on the topic.  My questions are with regard to the default mode of 
H2 (not MVCC or multithreaded=true).

A) the documentation states that most requests to the same database are 
synchronized.  

B) However, document goes on to discuss read and write locks.  This feature 
sounds similar to Java's standard ReadWriteLock functionality, which is 
used to have concurrent reads on data, while preventing reading during a 
synchronized write.

I am having difficulty understanding the two above statements.  My current 
interpretation is that read requests (SELECT, etc) can be done in parallel, 
while INSERT, UPDATE, etc cannot be done in parallel.  However, I am a bit 
doubtful that this interpretation is correct.

C) In my current application, I have noticed that I can perform 
some concurrent operations.   For example, a long running SELECT/ORDER_BY 
on Table A does not prevent quick selects on Table B.  So, clearly some 
operations can be done in parallel on multiple threads/cores (perhaps it is 
the ORDER_BY that is done concurrently here?).  Any clarification as to 
what operations can be done concurrently would be great.

D)  Finally, I am looking at a couple VPS providers to host an H2 server. 
 Some VPS companies provide scalable CPU power by [1] providing increasing 
CPU time slices with a smaller number of cores, while other companies 
provide scalable CPU power by [2] providing a larger number of cores with 
out an increase in CPU time slices.  Since H2 is not highly multi threaded, 
it seems like H2 would do better in a situation similar to [1].  Would you 
agree?

Thanks. -Adam


-- 
You received this message because you are subscribed to the Google Groups H2 
Database group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.