On Wed, May 2, 2012 at 8:22 AM, Tim Wintle wrote:
> On Tue, 2012-05-01 at 11:00 -0700, Aaron Turner wrote:
>> Tens or a few hundred MB per row seems reasonable. You could do
>> thousands/MB if you wanted to, but that can make things harder to
>> manage.
>
> thanks (Both Aarons)
>
>> Depending on
On Tue, 2012-05-01 at 11:00 -0700, Aaron Turner wrote:
> Tens or a few hundred MB per row seems reasonable. You could do
> thousands/MB if you wanted to, but that can make things harder to
> manage.
thanks (Both Aarons)
> Depending on the size of your data, you may find that the overhead of
> ea
I would try to avoid 100's on MB's per row. It will take longer to compact and
repair.
10's is fine. Take a look at in_memory_compaction_limit and thrift_frame_size
in the yaml file for some guidance.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpi
On Tue, May 1, 2012 at 10:20 AM, Tim Wintle wrote:
> I believe that the general design for time-series schemas looks
> something like this (correct me if I'm wrong):
>
> (storing time series for X dimensions for Y different users)
>
> Row Keys: "{USET_ID}_{TIMESTAMP/BUCKETSIZE}"
> Columns: "{DIME
I believe that the general design for time-series schemas looks
something like this (correct me if I'm wrong):
(storing time series for X dimensions for Y different users)
Row Keys: "{USET_ID}_{TIMESTAMP/BUCKETSIZE}"
Columns: "{DIMENSION_ID}_{TIMESTAMP%BUCKETSIZE}" -> {Counter}
But I've not fou
