That sounds interesting, but not sure exactly what you mean? My key is
like this: "((f1, f2, day) timeuuid)", and f1/f2 are roughly
well-distributed. So my inserts are pretty evenly distributed across
about 22k combinations of f1+f2 each day.
Are you saying that you get better performance by keeping the wide rows
less wide, or by spreading out over time inserts into a single row?
Just don't know what you mean by "shuffling"?
On 08/26/2013 03:06 PM, Jake Luciani wrote:
How are you inserting the data? Is it all partition at once?
We've had the experience that shuffling the inserts across rows for
wide rows gave us "normal" insert rates. When you mutate a entire
wide row at once it hits a bottleneck.
On Mon, Aug 26, 2013 at 4:49 PM, Keith Freeman <8fo...@gmail.com
<mailto:8fo...@gmail.com>> wrote:
I can believe that I'm IO bound with the current disk
configuration, but that doesn't explain the CPU load does it? If
I'm hitting a limit of disk performance, I should see a slowdown
but not the jump in CPU, right?
On 08/22/2013 11:52 AM, Nate McCall wrote:
Given the backups in the flushing stages, I think you are IO
bound. SSDs will work best for the data volume. Use rotational
media for the commitlog as it is largely sequential.
Quick experiment: disable commit log on the keyspace and see if
your test goes faster ("WITH DURABLE_WRITES = false" on keyspace
creation).
On Wed, Aug 21, 2013 at 5:41 PM, Keith Freeman <8fo...@gmail.com
<mailto:8fo...@gmail.com>> wrote:
We have 2 partitions on the same physical disk for commit-log
and data. Definitely non-optimal, we're planning to install
SSDs for the commit-log partition but don't have them yet.
Can this explain the high server loads?
On 08/21/2013 04:24 PM, Nate McCall wrote:
