Forum: Other

Post: Tables, wide vs. tall, and 100 params to a procedure ?

Tables, wide vs. tall, and 100 params to a procedure ?
mgan42
Dec 10, 2012
I have several million 15-minute electric usage records for which I need to determine an appropriate schema and partition columns for VoltDB. I'm trying to determine some throughput benchmarks.

With some other databases, I've used a tall table, where I would represent the readings for a single day with 96 rows. This ended-up causing some pain with a few hundred million rows. So, I went to a wide table, where each day of 15-min readings was represented by 1 row, with 96+ columns. This eased some pain for a while, but I've had some bottlenecks again.

Hence, trying VoltDB.

* For a high performance database such as VoltDB, does either design wide vs. tall, lend itself better to VoltDB?
* Does providing 96+ input parameters to a volt procedure pose a problem?

I'm sure I'll have additional thoughts on planning for capacity, memory, number of servers, etc. But, I have to start somewhere...
Thanks
awilson
Dec 11, 2012
I have several million 15-minute electric usage records for which I need to determine an appropriate schema and partition columns for VoltDB. I'm trying to determine some throughput benchmarks.

With some other databases, I've used a tall table, where I would represent the readings for a single day with 96 rows. This ended-up causing some pain with a few hundred million rows. So, I went to a wide table, where each day of 15-min readings was represented by 1 row, with 96+ columns. This eased some pain for a while, but I've had some bottlenecks again.

Hence, trying VoltDB.

* For a high performance database such as VoltDB, does either design wide vs. tall, lend itself better to VoltDB?
* Does providing 96+ input parameters to a volt procedure pose a problem?

I'm sure I'll have additional thoughts on planning for capacity, memory, number of servers, etc. But, I have to start somewhere...
Thanks


Hi,

Yes, you can have more than 96 columns provided that the row does not exceed 2MB and your result set is limited to 50MB.

What are some of the queries you'd like to perform?

The planning guide will help you with general sizing.

Thanks