in the family. There are millions of rows. Each operation consists of
doing a batch_insert through pycassa, which increments ~17k keys. A
majority of these keys are new in each batch.
Each operation is taking up to 15 seconds. For our system this is a
significant bottleneck.
Try to
I have a patch for trunk which I just have to get time to test a bit before I
submit.
It is for super columns and will use the super columns timestamp as the base
and only store variant encoded offsets in the underlying columns.
Could you please measure how much real benefit it brings (in
Is C* suitable for storing customer account (financial) data, as well as
billing, payroll, etc? This is a new company so migration is not an
issue... starting from scratch.
If you need only store them - then yes, but if you require transactions spanning
multiple rows or column families,
Jonathan Ellis jbellis at gmail.com writes:
IMO if you only get CL.ALL it's not superior enough to pessimistic
locking to justify the complexity of adding it.
Yes, may be youre right, but CL.ALL is neccessary only to solve this problem in
a generic way.
In some (most?) cases, conflicts
