woops was obviously tired, what I said clearly doesn't make sense.
On 10 June 2016 at 14:52, kurt Greaves wrote:
> Sorry, I did mean larger number of rows per partition.
>
> On 9 June 2016 at 10:12, John Thomas wrote:
>
>> The example I gave was for when N=1, if we need to save more values I
>>
Sorry, I did mean larger number of rows per partition.
On 9 June 2016 at 10:12, John Thomas wrote:
> The example I gave was for when N=1, if we need to save more values I
> planned to just add more columns.
>
> On Thu, Jun 9, 2016 at 12:51 AM, kurt Greaves
> wrote:
>
>> I would say it's probabl
The example I gave was for when N=1, if we need to save more values I
planned to just add more columns.
On Thu, Jun 9, 2016 at 12:51 AM, kurt Greaves wrote:
> I would say it's probably due to a significantly larger number of
> partitions when using the overwrite method - but really you should be
@cassandra.apache.org
Subject: Re: Interesting use case
I would say it's probably due to a significantly larger number of partitions
when using the overwrite method - but really you should be seeing similar
performance unless one of the schemas ends up generating a lot more disk IO.
If you're planning t
I would say it's probably due to a significantly larger number of
partitions when using the overwrite method - but really you should be
seeing similar performance unless one of the schemas ends up generating a
lot more disk IO.
If you're planning to read the last N values for an event at the same t
We have a use case where we are storing event data for a given system and
only want to retain the last N values. Storing extra values for some time,
as long as it isn’t too long, is fine but never less than N. We can't use
TTLs to delete the data because we can't be sure how frequently events wil
