o:l...@lapo.it>
Sent: Friday, December 30, 2022 4:12 AM
To: mailto:user@cassandra.apache.org
Subject: [EXTERNAL] Re: Best compaction strategy for rarely used data
On 2022-12-29 21: 54, Durity, Sean R via user wrote: > At some point you will
end up with large sstables (like 1 TB) t
: [EXTERNAL] Re: Best compaction strategy for rarely used data
On 2022-12-29 21: 54, Durity, Sean R via user wrote: > At some point you will
end up with large sstables (like 1 TB) that won’t > compact because there are
not 4 similar-sized ones able to be compacted Yes, that's exa
On 2022-12-29 21:54, Durity, Sean R via user wrote:
At some point you will end up with large sstables (like 1 TB) that won’t
compact because there are not 4 similar-sized ones able to be compacted
Yes, that's exactly what's happening.
I'll see maybe just one more compaction, since the biggest
, December 29, 2022 4:51 AM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: Best compaction strategy for rarely used data
Hi Lapo Take a look at TWCS, I think that could help your use case: https:
//thelastpickle. com/blog/2016/12/08/TWCS-part1. html [thelastpickle. com]
Regards Paul Chandler
Hi Lapo
Take a look at TWCS, I think that could help your use case:
https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html
Regards
Paul Chandler
Sent from my iPhone
> On 29 Dec 2022, at 08:55, Lapo Luchini wrote:
>
> Hi, I have a table which gets (a lot of) data that is written once an
Hi, I have a table which gets (a lot of) data that is written once and
very rarely read (it is used for data that is mandatory for regulatory
reasons), and almost never deleted.
I'm using the default SCTS as at the time I didn't know any better, but
SSTables size are getting huge, which is a p
et it right that
> running `nodetool upgradesstables -a` is going to rewrite all the SSTable
> files subject to the defined compaction strategy?
You don’t need to do user defined compaction here
As soon as the data files are on the server, the next time TWCS looks for
compaction candidates
. We are OK with
rewriting all files once, though.
Assuming, we get it running on our server version: do I get it right that
running `nodetool upgradesstables -a` is going to rewrite all the SSTable
files subject to the defined compaction strategy?
--
Alex
If you’re really really advanced you MIGHT be able to use spark +
cqlsstablewriter to create a ton of sstables with just tombstones one them
representing deletes, then either nodetool refresh or sstableloader them into
the cluster
If you create sstables on the right timestamp boundaries to ma
On Fri, 28 Feb 2020, 23:02 Erick Ramirez,
wrote:
> I'm not personally aware of anyone who is using it successfully other
> than ProtectWise where it was a good fit for their narrow use case. My
> limited knowledge of it is that it has some sharp edges which is the reason
> they haven't pushed for
I'm not personally aware of anyone who is using it successfully other than
ProtectWise where it was a good fit for their narrow use case. My limited
knowledge of it is that it has some sharp edges which is the reason they
haven't pushed for it to be added to Cassandra (that's second hand info so
pl
component can be anything and we don't have a way to enumerate all of
them. Even if we could, there are millions of records to remove and we
would like to avoid creating any tombstones. Our total storage for this
cluster is close to 100 TiB.
We found that DCS (Deleting Compaction Strateg
> within the TTL it's the wrong strategy.
> This diagram is a good rule of the thumb
>
>
>
>> On Thu, Oct 25, 2018 at 6:28 AM Alexander Dejanovski
>> wrote:
>> Hi Raman,
>>
>> TWCS is the best compaction strategy for TTL data, even if you
To add to what Alex suggested, if you know what keys use what TTL you could
store them in different tables, with different window settings.
Jon
On Fri, Oct 26, 2018 at 1:28 AM Alexander Dejanovski
wrote:
> Hi Raman,
>
> TWCS is the best compaction strategy for TTL data, even if
Hi Raman,
TWCS is the best compaction strategy for TTL data, even if you have
different TTLs (set the time window based on your largest TTL, so it would
be 1 day in your case).
Enable unchecked tombstone compaction to clear the data with 2 days TTL
along the way. This is done by setting :
ALTER
Hi All,
I have one table in which i have some data which has TTL of 2days and some
data which has TTL of 60 days. What compaction strategy will suits the most.
1. LeveledCompactionStrategy (LCS)
2. SizeTieredCompactionStrategy (STCS)
3. TimeWindowCompactionStrategy (TWCS)
--
Raman
I suspect that you are CPU bound rather than IO bound. There are a lot of
areas to look into, but I would start with a few.
I could not tell much from the results you shared since at the time, there
were no writes happening. Switching to a different compaction strategy
will most likely make it
y scattered across different sstables. size compaction
strategy (STCS) is much less expensive than level compaction strategy (LCS).
Stopping the background compaction should
be approached with caution, I think your problem is more to do with why
STCS compaction is taking more resources than you e
size compaction strategy (STCS) is much less expensive
than level compaction strategy (LCS).
Stopping the background compaction should be approached with caution, I
think your problem is more to do with why STCS compaction is taking more
resources than you expect.
Regards,
Ali Hubail
Petr
ction
> and it is causing timeouts.
>
> Also will reducing or increasing compaction_throughput_mb_per_sec eliminate
> timeouts ?
>
> Thanks,
>
>
>> On Sep 17, 2018, at 9:38 PM, rajasekhar kommineni
>> wrote:
>>
>> Hello Folks,
>>
>
17, 2018, at 9:38 PM, rajasekhar kommineni wrote:
>
> Hello Folks,
>
> I need advice in deciding the compaction strategy for my C cluster. There are
> multiple jobs that will load the data with less inserts and more updates but
> no deletes. Currently I am using Size Tired c
Hello Folks,
I need advice in deciding the compaction strategy for my C cluster. There are
multiple jobs that will load the data with less inserts and more updates but no
deletes. Currently I am using Size Tired compaction, but seeing auto
compactions after the data load kicks, and also read
ll also solve the problem w.r.t old buckets.
> >
> > In regards to LCS, the only way to really know if it'll be too much
> compaction overhead is to test it, but for the most part you should
> consider your read/write ratio, rather than the total number of
> reads/writes (unle
;s so small that it's irrelevant, which it may well be).
>
> On 13 June 2018 at 19:25, manuj singh wrote:
>>
>> Hi all,
>> I am trying to determine compaction strategy for our use case.
>> In our use case we will have updates on a row a few times. And we have a ttl
part you should
consider your read/write ratio, rather than the total number of
reads/writes (unless it's so small that it's irrelevant, which it may well
be).
On 13 June 2018 at 19:25, manuj singh wrote:
> Hi all,
> I am trying to determine compaction strategy for our use case.
>
Hi all,
I am trying to determine compaction strategy for our use case.
In our use case we will have updates on a row a few times. And we have a
ttl also defined on the table level.
Our typical workload is less then 1000 writes + reads per second. At the
max it could go up to 2500 per second.
We
the past I did not care much about the compaction strategy for counters
> as I considered it to be negligible in my case (counters were MB big tables
> out of a few TB for the entire dataset).
>
> You can always pick a strategy you think would work better, and test the
> change on a canary n
SSTables.
In the past I did not care much about the compaction strategy for counters
as I considered it to be negligible in my case (counters were MB big tables
out of a few TB for the entire dataset).
You can always pick a strategy you think would work better, and test the
change on a canary node
Hello!
I am using Cassandra 3.10.
I have a counter table, with the following schema and RF=1
CREATE TABLE edges (
src_id text,
src_type text,
source text
weight counter,
PRIMARY KEY ((src_id, src_type), source)
);
SELECT vs UPDATE requests ratio for this table is 0.1
READ vs W
The rogue pending task is likely a non-issue. If your jmx command went
through without errors and you got the log message you can assume it
worked. It won't show in the schema unless you run the ALTER statement
which affects the whole cluster.
If you were switching from STCS then you wouldn't expe
a way to tell when/if the local node has successfully updated the
compaction strategy? Looking at the sstable files, it seems like they are
still based on STCS but I don't know how to be sure.
Appreciate any tips or suggestions!
On Mon, Mar 13, 2017 at 5:30 PM, Mike Torra wrote:
>
I'm trying to change compaction strategy one node at a time. I'm using
jmxterm like this:
`echo 'set -b
org.apache.cassandra.db:type=ColumnFamilies,keyspace=my_ks,columnfamily=my_cf
CompactionParametersJson
\{"class":"TimeWindowCompactionStrategy&qu
queuing table is anti pattern.
>
> From: Vincent Rischmann
> Sent: Friday, February 24, 2017 06:24
> To: user@cassandra.apache.org
> Subject: Which compaction strategy when modeling a dumb set
>
> Hello,
>
> I'm using a table
cent Rischmann
Sent: Friday, February 24, 2017 06:24
To: user@cassandra.apache.org
Subject: Which compaction strategy when modeling a dumb set
Hello,
I'm using a table like this:
CREATE TABLE myset (id uuid PRIMARY KEY)
which is basically a set I use for deduplication, id is a unique id for
: user@cassandra.apache.org
Subject: Which compaction strategy when modeling a dumb set
Hello,
I'm using a table like this:
CREATE TABLE myset (id uuid PRIMARY KEY)
which is basically a set I use for deduplication, id is a unique id for an
event, when I process the event I insert the id
lication, id is a unique id
>> for an event, when I process the event I insert the id, and before
>> processing I check if it has already been processed for
>> deduplication.
>>
>> It works well enough, but I'm wondering which compaction strategy I
>> should u
f it has already been processed for deduplication.
It works well enough, but I'm wondering which compaction strategy I should use.
I expect maybe 1% or less of events will end up duplicated (thus not generating
an insert), so the workload will probably be 50% writes 50% read.
Is LCS a good
Probably LCS although what you're implying (read before write) is an
anti-pattern in Cassandra. Something like this is a good indicator that you
should review your model.
ation.
It works well enough, but I'm wondering which compaction strategy I
should use. I expect maybe 1% or less of events will end up duplicated
(thus not generating an insert), so the workload will probably be 50%
writes 50% read.
Is LCS a good strategy here or should I stick with STCS ?
it’ll compact it in a
>>> single sstable compaction).
>>>
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>> *From: *Voytek Jarnot
>>> *Reply-To: *"user@cassandra.apache.org"
>>> *Date: *Friday, Decem
able
>> over 24 hours old that’s at least 80% tombstones, it’ll compact it in a
>> single sstable compaction).
>>
>>
>>
>> - Jeff
>>
>>
>>
>> *From: *Voytek Jarnot
>> *Reply-To: *"user@cassandra.apache.org"
>> *Date: *Friday,
that’s at least 80% tombstones, it’ll compact it in a
>> single sstable compaction).
>>
>>
>>
>> - Jeff
>>
>>
>>
>> From: Voytek Jarnot
>> Reply-To: "user@cassandra.apache.org"
>> Date: Friday, December 16, 2016 at 7:3
ber 16, 2016 at 7:34 PM
>
> *To: *"user@cassandra.apache.org"
> *Subject: *Re: Choosing a compaction strategy (TWCS)
>
>
>
> Thanks again, Jeff.
>
>
>
> Thinking about this some more, I'm wondering if I'm overthinking or if
> there's a p
Friday, December 16, 2016 at 11:12 AM
To: "user@cassandra.apache.org"
Subject: Re: Choosing a compaction strategy (TWCS)
Thank you Jeff - always nice to hear straight from the source.
Any issues you can see with 3 (my calendar-week bucket not aligning with the
arbitrary 7-day window
uot;
> *Date: *Friday, December 16, 2016 at 11:12 AM
>
> *To: *"user@cassandra.apache.org"
> *Subject: *Re: Choosing a compaction strategy (TWCS)
>
>
>
> Thank you Jeff - always nice to hear straight from the source.
>
>
>
> Any issues you can see with 3 (my calendar
.
- Jeff
From: Voytek Jarnot
Reply-To: "user@cassandra.apache.org"
Date: Friday, December 16, 2016 at 11:12 AM
To: "user@cassandra.apache.org"
Subject: Re: Choosing a compaction strategy (TWCS)
Thank you Jeff - always nice to hear straight from the source.
table – it
> won’t kill you, but if you can avoid it, avoid it.
>
>
>
> - Jeff
>
>
>
>
>
> *From: *Jeff Jirsa
> *Date: *Friday, December 16, 2016 at 10:47 AM
> *To: *"user@cassandra.apache.org"
> *Subject: *Re: Choosing a
.
- Jeff
From: Jeff Jirsa
Date: Friday, December 16, 2016 at 10:47 AM
To: "user@cassandra.apache.org"
Subject: Re: Choosing a compaction strategy (TWCS)
With a 10 year retention, just ignore the target sstable count (I should remove
that guidance, to be honest), and
bloom filter is
going to make things nice and easy for you.
- Jeff
From: Voytek Jarnot
Reply-To: "user@cassandra.apache.org"
Date: Friday, December 16, 2016 at 10:37 AM
To: "user@cassandra.apache.org"
Subject: Choosing a compaction strategy (TWCS)
Scena
Scenario:
Converting an Oracle table to Cassandra, one Oracle table to 4 Cassandra
tables, basically time-series - think log or auditing. Retention is 10
years, but greater than 95% of reads will occur on data written within the
last year. 7 day TTL used on a small percentage of the records, major
On 24 October 2016 at 18:11, Seth Edwards wrote:
> The other thought is that we currently have data mixed in that does not
> have a TTL and we are strongly considering putting this data in it's own
> table.
You should definitely do that. Having non-TTL'd data mixed in will result
in SSTables th
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Sunday, October 23, 2016 at 7:03 PM
> *To: *user
> *Subject: *Re: Question about compaction strategy changes
>
>
>
> More compactions meaning "rows to be compacted" or actual number of
> pending comp
consumed by compaction in a TWCS setting.
From: Seth Edwards
Reply-To: "user@cassandra.apache.org"
Date: Sunday, October 23, 2016 at 7:03 PM
To: user
Subject: Re: Question about compaction strategy changes
More compactions meaning "rows to be compacted" or actu
More compactions meaning "actual number of compaction tasks". A compaction
task generally operates on many SSTables (how many depends on the chosen
compaction strategy). The number of pending tasks does not line up with the
number of SSTables that will be compacted. 1 task may co
More compactions meaning "rows to be compacted" or actual number of pending
compactions? I assumed when I run nodetool compactionstats the number of
pending tasks would line up with number of sstables that will be compacted.
Most of the time this is idle, then we hit spots when it could jump into
t
On 22 October 2016 at 03:37, Seth Edwards wrote:
> We're using TWCS and we notice that if we make changes to the options to
> the window unit or size, it seems to implicitly start recompacting all
> sstables.
If you increase the window unit or size you potentially increase the number
of SSTable
hi Edwards,
when changibg gc_grace_second, no compaction willbbe triggered.
regards,
jasonstack
Sent from my Mi phoneOn Seth Edwards , Oct 22, 2016 11:37 AM wrote:Hello! We're using TWCS and we notice that if we make changes to the options to the window unit or size, it seems to implicitly s
Hello! We're using TWCS and we notice that if we make changes to the
options to the window unit or size, it seems to implicitly start
recompacting all sstables. Is this indeed the case and more importantly,
does the same happen if we were to adjust the gr_grace_seconds for this
table?
Thanks!
e:
>
>> Hi!
>>
>> I have a 2.0.13 cluster which I have just extended, and I'm now looking
>> into upgrading it to 2.1.
>>
>> * The cleanup after the extension is partially done.
>> * I'm also looking into changing a few tables into Leveled Compaction
>
xtended, and I'm now looking
> into upgrading it to 2.1.
>
> * The cleanup after the extension is partially done.
> * I'm also looking into changing a few tables into Leveled Compaction
> Strategy.
>
> In the interest of speeding up things by avoiding unnecessary rewrit
Hi!
I have a 2.0.13 cluster which I have just extended, and I'm now looking
into upgrading it to 2.1.
* The cleanup after the extension is partially done.
* I'm also looking into changing a few tables into Leveled Compaction
Strategy.
In the interest of speeding up things b
When you change compaction strategy, nothing happens until the next flush. On
the next flush, the new compaction strategy will decide what to do – if you
change from STCS to DTCS, it will look at various timestamps of files, and
attempt to group them by time windows based on the sstable’s
Hi,
I need to understand whether all existing sstables are recreated/updated when
we change compaction strategy from STCS to DTCS?
Sstables are immutable by design but do we take an exception for such cases and
update same files when an Alter statement is fired to change the compaction
>>> to my question above would help second guess my a decision a bit less :)
>>>
>>> Cheers,
>>> Stefano
>>>
>>> On Mon, May 25, 2015 at 9:52 AM, Jason Wee wrote:
>>>
>>>> , due to a really intensive delete workloads, th
>>> promoted to t..
>>>
>>> Is cassandra design for *delete* workloads? doubt so. Perhaps looking at
>>> some other alternative like ttl?
>>>
>>> jason
>>>
>>> On Mon, May 25, 2015 at 10:12 AM, Manoj Khangaonkar <
>>>
mmendation seems to be
>>> that leveled compaction is suited for read intensive workloads.
>>>
>>> Depending on your use case, you might better of with data tiered or size
>>> tiered strategy.
>>>
>>> regards
>>>
>>> regards
>&g
tion seems to be that
>> leveled compaction is suited for read intensive workloads.
>>
>> Depending on your use case, you might better of with data tiered or size
>> tiered strategy.
>>
>> regards
>>
>> regards
>>
>>> On Sun, May 24, 2015
ed strategy.
>
> regards
>
> regards
>
> On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani
> wrote:
>
>> Hi all,
>>
>> I have a question re leveled compaction strategy that has been bugging me
>> quite a lot lately. Based on what I understood, a compacti
strategy.
regards
regards
On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani
wrote:
> Hi all,
>
> I have a question re leveled compaction strategy that has been bugging me
> quite a lot lately. Based on what I understood, a compaction takes place
> when the SSTable gets to a specific
Hi all,
I have a question re leveled compaction strategy that has been bugging me
quite a lot lately. Based on what I understood, a compaction takes place
when the SSTable gets to a specific size (10 times the size of its previous
generation). My question is about an edge case where, due to a
The underlying write time is still tracked for each value in the collection
- it's part of how conflict resolution is managed - but it's not exposed
through CQL.
On Fri Nov 28 2014 at 4:18:47 AM Batranut Bogdan wrote:
> Hello all,
>
> If one has a table like this:
> id text,
> ts timestamp
> val
Hello all,
If one has a table like this:id text,ts timestampvalues list
PK (id,ts)
How will the DTCS work? I am asking this because the writeTime() function does
not work on collections.
>> >> Hi Andrei, Hi Nicolai,
>> >>
>> >> Which version of C* are you using ?
>> >>
>> >> There are some recommendations about the max storage per node :
>> >>
>> >> http://www.datastax.com/dev/blog/performance-improvements-in-ca
t the max storage per node :
> >>
> http://www.datastax.com/dev/blog/performance-improvements-in-cassandra-1-2
> >>
> >> "For 1.0 we recommend 300-500GB. For 1.2 we are looking to be able to
> >> handle 10x
> >> (3-5TB)".
> >>
> &
r 1.0 we recommend 300-500GB. For 1.2 we are looking to be able to
>> handle 10x
>> (3-5TB)".
>>
>> I have the feeling that those recommendations are sensitive according many
>> criteria such as :
>> - your hardware
>> - the compaction strategy
>> - ...
uot;For 1.0 we recommend 300-500GB. For 1.2 we are looking to be able to
> handle 10x
> (3-5TB)".
>
> I have the feeling that those recommendations are sensitive according many
> criteria such as :
> - your hardware
> - the compaction strategy
> - ...
>
> It looks
> There are some recommendations about the max storage per node :
>> >
>> > http://www.datastax.com/dev/blog/performance-improvements-in-cassandra-1-2
>> >
>> > "For 1.0 we recommend 300-500GB. For 1.2 we are looking to be able to
>> > handle
>> > 10x
-1-2
> >
> > "For 1.0 we recommend 300-500GB. For 1.2 we are looking to be able to
> handle
> > 10x
> > (3-5TB)".
> >
> > I have the feeling that those recommendations are sensitive according
> many
> > criteria such as :
> > - your ha
d 300-500GB. For 1.2 we are looking to be able to handle
> 10x
> (3-5TB)".
>
> I have the feeling that those recommendations are sensitive according many
> criteria such as :
> - your hardware
> - the compaction strategy
> - ...
>
> It looks that LCS lower those limita
".
I have the feeling that those recommendations are sensitive according many
criteria such as :
- your hardware
- the compaction strategy
- ...
It looks that LCS lower those limitations.
Increasing the size of sstables might help if you have enough CPU and you
can put more load on your
On Mon, Nov 24, 2014 at 6:48 AM, Nikolai Grigoriev
wrote:
> One of the obvious recommendations I have received was to run more than
> one instance of C* per host. Makes sense - it will reduce the amount of
> data per node and will make better use of the resources.
>
This is usually a Bad Idea to
sure if this node will ever get back to normal life. And
>> >> >>>> believe me
>> >> >>>> - this is not because of I/O, I have SSDs everywhere and 16
>> >> >>>> physical
>> >> >>>> cores.
>> >> >>&
lose to 2x disk
> space
> >> >>>> on
> >> >>>> EVERY disk in my JBOD configuration...this will kill the node
> sooner
> >> >>>> or
> >> >>>> later. This is all because all sstables after bootstrap end at L0
> and
> &g
otstrap end at L0 and
>> >>>> then
>> >>>> the process slowly slowly moves them to other levels. If you have
>> >>>> write
>> >>>> traffic to that CF then the number of sstables and L0 will grow
>> >>
e
> https://issues.apache.org/jira/browse/CASSANDRA-8301
> >>>> is implemented it may be better.
> >>>>
> >>>>
> >>>> On Sun, Nov 23, 2014 at 4:53 AM, Andrei Ivanov
> >>>> wrote:
> >>>>>
&g
ewhat similar C* load profile. Hence some comments
>>>>> in addition Nikolai's answer.
>>>>> 1. Fallback to STCS - you can disable it actually
>>>>> 2. Based on our experience, if you have a lot of data per node, LCS
>>>>> may work j
ill not be able
>>>> to compact what it gets from old nodes. In your case, if you switch
>>>> strategy the same thing may happen. This is all due to limitations
>>>> mentioned by Nikolai.
>>>>
>>>> Andrei,
>>>>
>>>>
may work just fine. That is, till the moment you decide to join
>>>> another node - chances are that the newly added node will not be able
>>>> to compact what it gets from old nodes. In your case, if you switch
>>>> strategy the same thing may happen. This is all due to li
ai.
>>>
>>> Andrei,
>>>
>>>
>>> On Sun, Nov 23, 2014 at 8:51 AM, Servando Muñoz G.
>>> wrote:
>>> > ABUSE
>>> >
>>> >
>>> >
>>> > YA NO QUIERO MAS MAILS SOY DE MEXICO
>>> >
t;
>> >
>> > YA NO QUIERO MAS MAILS SOY DE MEXICO
>> >
>> >
>> >
>> > De: Nikolai Grigoriev [mailto:ngrigor...@gmail.com]
>> > Enviado el: sábado, 22 de noviembre de 2014 07:13 p. m.
>> > Para: user@cassandra.apache.org
>>
gt;
> >
> >
> > De: Nikolai Grigoriev [mailto:ngrigor...@gmail.com]
> > Enviado el: sábado, 22 de noviembre de 2014 07:13 p. m.
> > Para: user@cassandra.apache.org
> > Asunto: Re: Compaction Strategy guidance
> > Importancia: Alta
> >
> >
> >
t; ABUSE
>
>
>
> YA NO QUIERO MAS MAILS SOY DE MEXICO
>
>
>
> De: Nikolai Grigoriev [mailto:ngrigor...@gmail.com]
> Enviado el: sábado, 22 de noviembre de 2014 07:13 p. m.
> Para: user@cassandra.apache.org
> Asunto: Re: Compaction Strategy guidance
> Importancia: A
ABUSE
YA NO QUIERO MAS MAILS SOY DE MEXICO
De: Nikolai Grigoriev [mailto:ngrigor...@gmail.com]
Enviado el: sábado, 22 de noviembre de 2014 07:13 p. m.
Para: user@cassandra.apache.org
Asunto: Re: Compaction Strategy guidance
Importancia: Alta
Stephane,
As everything good, LCS comes at
Stephane,
As everything good, LCS comes at certain price.
LCS will put most load on you I/O system (if you use spindles - you may
need to be careful about that) and on CPU. Also LCS (by default) may fall
back to STCS if it is falling behind (which is very possible with heavy
writing activity) and
Hi there,
use case:
- Heavy write app, few reads.
- Lots of updates of rows / columns.
- Current performance is fine, for both writes and reads..
- Currently using SizedCompactionStrategy
We're trying to limit the amount of storage used during compaction. Should
we switch to LeveledCompactionStr
Check that: https://issues.apache.org/jira/browse/CASSANDRA-6602
There is a patch for a compaction strategy dedicated to time series data.
The discussion is also interesting in the comments.
On Fri, Aug 15, 2014 at 6:28 AM, Kevin Burton wrote:
> We use log structured tables to hold logs
space, you can just drop the oldest day's
worth of data without having to use tombstones.
MySQL has a somewhat decent partition engine:
http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
It seems like this come be easily implemented using a custom compaction
strategy.
Essentially, you
able as well? Are
you talking about making a new compaction strategy that creates SSTables by day?
On June 4, 2014 at 1:36:10 PM, Redmumba (redmu...@gmail.com) wrote:
Let's say I run a major compaction every day, so that the "oldest" sstable
contains only the data for January 1st.
>>
>>
>> On Wed, Jun 4, 2014 at 10:40 AM, Russell Bradberry
>> wrote:
>>
>>> Maybe I’m misunderstanding something, but what makes you think that
>>> running a major compaction every day will cause they data from January 1st
>>> to exist in only on
r days in the
>> SSTable as well? Are you talking about making a new compaction strategy
>> that creates SSTables by day?
>>
>>
>>
>> On June 4, 2014 at 1:36:10 PM, Redmumba (redmu...@gmail.com) wrote:
>>
>> Let's say I run a major compaction
1 - 100 of 140 matches
Mail list logo
