hscale-user Mailing List for HSCALE
Status: Alpha
Brought to you by:
antarapero
Menu
▾
▴
hscale-user — Questions and discussions on how to use HSCALE.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Peter R. <pet...@op...> - 2008-09-26 20:40:19
|
... resending this message since listserver at sf.net seemed to be down for quite a while :( Paul, > I have read up a bit on HSCALE and I have a couple questions about it. > First of all, does it support JDBC batching? Also, how about simple JDBC-Batching is supported as long as you don't use "rewriteBatchedStatements=true" with Connector-J (see http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-configuration-properties.html) Currently HSCALE does not support multi-value INSERT statements. > stored procedures? If would be fantastic if HSCALE can support these Stored procedures are supported (HSCALE + MySQL Proxy is just a proxy). But I think you meant "Is using partitioned tables within stored procedures supported?": No. I doubt that this will be the case in the near future since you have no control over stored procedures from within the proxy and thus would have to come up with some completely different approach. Personally, I don't use stored procedures since they put application logic into the DBMS. But that is really, really just my point of view ;) Greetings Peter ..: Next time, please subscribe to the mailing list before posting. |
|
From: Paul C. <way...@gm...> - 2008-09-18 19:02:50
|
Hi, I have read up a bit on HSCALE and I have a couple questions about it. First of all, does it support JDBC batching? Also, how about simple stored procedures? If would be fantastic if HSCALE can support these features as they are used by alot of developers. Thanks |
|
From: Peter R. <pr-...@op...> - 2008-08-12 20:56:02
|
On Tue, 12 Aug 2008 04:49:54 -0500 "David Cramer" <dc...@gm...> wrote: > I'm testing out HSCALE, and I was wondering if it was possible to > configure the column name to be a composite key? Our example dataset > using a composite primary key, so I'm assuming it's not going to work > out too well if the key passed in the configuration has duplicates. Hi David, this is currently not on the roadmap for the (near) future. Sorry for that! Primary key checking isn't implemented as well (and will not be implemented in the near future). Currently we are trying to get HSCALE to work with our (very simple) schema with IDs generated outside the database) schema. Once we have that in production we will focus on other use cases as well. Regards Peter |
|
From: David C. <dc...@gm...> - 2008-08-12 09:50:07
|
I'm testing out HSCALE, and I was wondering if it was possible to configure the column name to be a composite key? Our example dataset using a composite primary key, so I'm assuming it's not going to work out too well if the key passed in the configuration has duplicates. -- David Cramer Director of Technology iBegin http://www.ibegin.com/ |
|
From: Peter R. <pr-...@op...> - 2008-07-31 03:31:04
|
Hi Karel, first of all: We are making progress towards supporting multiple backends. There is already working code in the subversion trunk. Some important thinks like transaction handling are missing but it is a beginning. > Hi, I am looking at sharding as a means to spread the load of write > operations. I understand that XA sharding is a 'far future' idea for > Hscale, but I am wondering if it would make sense to use the FEDERATED > storage engine on the sharded tables: > The application would see 'my_huge_table', which HScales translates to > my_huge_table[1-3] on server 0. > --server 0-- > my_huge_table_1 ===> federated, connects to server 1 > my_huge_table_2 ===> federated, connects to server 2 > my_huge_table_3 ===> federated, connects to server 3 > Would this kind of setup make sense? It still has a one-server > bottleneck, but at least we do not to buy 'better/faster/bigger' > storage > for that one server, we can spread the actual storage to multiple > servers. > Would this help with write performance or would the FEDERATED engine > give too much overhead on server 0? This is a neat idea! But there are some drawbacks with the FEDERATED engine that might make it a bad choice (see http://dev.mysql.com/doc/refman/5.0/en/federated-limitations.html). First of all FEDERATED is not transactional. The other big thing is that FEDERATED supports indexes very poorly. We used it for a while for not so important data (both performance and integrety wise) and it worked. We had no data loss but performance was very low. If storage is your main concern and you are willing to sacrifice some performance you could put partitions on another local(!) db (so database files are in another folder beneath /var/lib/mysql) and mount that via your favorite network storage system (like nfs). The ultimate advice I can give you here is: Benchmark, benchmark, benchmark ;) Or wait for hscale-0.3... Hope this answers your question! Greetings Peter |
|
From: Karel V. <ka...@ou...> - 2008-07-18 15:52:23
|
Hi, I am looking at sharding as a means to spread the load of write operations. I understand that XA sharding is a 'far future' idea for Hscale, but I am wondering if it would make sense to use the FEDERATED storage engine on the sharded tables: The application would see 'my_huge_table', which HScales translates to my_huge_table[1-3] on server 0. --server 0-- my_huge_table_1 ===> federated, connects to server 1 my_huge_table_2 ===> federated, connects to server 2 my_huge_table_3 ===> federated, connects to server 3 Would this kind of setup make sense? It still has a one-server bottleneck, but at least we do not to buy 'better/faster/bigger' storage for that one server, we can spread the actual storage to multiple servers. Would this help with write performance or would the FEDERATED engine give too much overhead on server 0? Regards, Karel |