RE: Best compaction strategy for rarely used data

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

RE: Best compaction strategy for rarely used data

: [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 exactly

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 exactly what's happening. I'll see maybe just one more compaction, since the

RE: Best compaction strategy for rarely used data

, 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

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 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

Best compaction strategy for rarely used data

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

Re: Deleting Compaction Strategy for Cassandra 3.0?

do I get 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

Re: Deleting Compaction Strategy for Cassandra 3.0?

. 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

Re: Deleting Compaction Strategy for Cassandra 3.0?

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

Re: Deleting Compaction Strategy for Cassandra 3.0?

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

Re: Deleting Compaction Strategy for Cassandra 3.0?

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

Deleting Compaction Strategy for Cassandra 3.0?

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 Strategy) can be a perfect fit: https

Re: Best compaction strategy

> 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 have

Re: Best compaction strategy

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

Re: Best compaction strategy

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

Best compaction strategy

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

Re: Newsletter / Marketing: Re: Compaction Strategy

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

Re: Compaction Strategy

oss 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 expect. Regards

Re: Compaction Strategy

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 Petrolink

Re: Compaction Strategy

control compaction > 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, >>

Re: Compaction Strategy

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

Compaction Strategy

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

Re: Compaction strategy for update heavy workload

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 (unless it's so small that it's irrelevant, which it may well > be). > > > > On 13 June 2018 at

Re: Compaction strategy for update heavy workload

> > 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 >> also defined on the table level. >> Our typic

Re: Compaction strategy for update heavy workload

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. > In our use case we will have up

Compaction strategy for update heavy workload

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

Re: Best compaction strategy for counters tables

es. > > 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 &

Re: Best compaction strategy for counters tables

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

Best compaction strategy for counters tables

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

Re: changing compaction strategy

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

Re: changing compaction strategy

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 <mto...@salesforce.com>

changing compaction strategy

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","compa

Re: Which compaction strategy when modeling a dumb set

e that using > Cassandra as a queuing table is anti pattern. > > From: Vincent Rischmann <m...@vrischmann.me> > Sent: Friday, February 24, 2017 06:24 > To: user@cassandra.apache.org > Subject: Which compaction strategy when modeling a dumb

Re: Which compaction strategy when modeling a dumb set

user@cassandra.apache.org Subject: Re: Which compaction strategy when modeling a dumb set Do you update this table when an event is processed? If yes, it is considered a good practice for Cassandra. I read somewhere that using Cassandra as a queuing table is anti pattern. ___

Re: Which compaction strategy when modeling a dumb set

ary 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 an event, when I process the e

Re: Which compaction strategy when modeling a dumb set

on, 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 use. I expect maybe

Re: Which compaction strategy when modeling a dumb set

ready 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 strategy here o

Re: Which compaction strategy when modeling a dumb set

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. ​

Which compaction strategy when modeling a dumb set

. 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 ?

Re: Choosing a compaction strategy (TWCS)

re’s no other work to do, if there’s an sstable >>> over 24 hours old that’s at least 80% tombstones, it’ll compact it in a >>> single sstable compaction). >>> >>> >>> >>> - Jeff >>> >>> >>>

Re: Choosing a compaction strategy (TWCS)

Voytek Jarnot <voytek.jar...@gmail.com> >> *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org> >> *Date: *Friday, December 16, 2016 at 7:34 PM >> >> *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> >> *Subj

Re: Choosing a compaction strategy (TWCS)

Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Date: Friday, December 16, 2016 at 7:34 PM >> >> >> To: "user@cassandra.apache.org" <user@cassandra.apache.org> >> Subject: Re: Choosing a compaction strategy (TWCS) &g

Re: Choosing a compaction strategy (TWCS)

To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Friday, December 16, 2016 at 7:34 PM > > *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Subject: *Re: Choosing a compaction strategy (TWCS) > > > > Thanks a

Re: Choosing a compaction strategy (TWCS)

6 at 7:34 PM To: "user@cassandra.apache.org" <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 potential issue: If my compaction_window_size is 7 (DAYS

Re: Choosing a compaction strategy (TWCS)

ot;user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Friday, December 16, 2016 at 11:12 AM > > *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Subject: *Re: Choosing a compaction strategy (TWCS) > > > > Thank you J

Re: Choosing a compaction strategy (TWCS)

. - Jeff From: Voytek Jarnot <voytek.jar...@gmail.com> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> Date: Friday, December 16, 2016 at 11:12 AM To: "user@cassandra.apache.org" <user@cassandra.apache.org> Subject: Re: Choosing

Re: Choosing a compaction strategy (TWCS)

ushed into the same sstable – it > won’t kill you, but if you can avoid it, avoid it. > > > > - Jeff > > > > > > *From: *Jeff Jirsa <jeff.ji...@crowdstrike.com> > *Date: *Friday, December 16, 2016 at 10:47 AM > *To: *"user@ca

Re: Choosing a compaction strategy (TWCS)

it. - Jeff From: Jeff Jirsa <jeff.ji...@crowdstrike.com> Date: Friday, December 16, 2016 at 10:47 AM To: "user@cassandra.apache.org" <user@cassandra.apache.org> Subject: Re: Choosing a compaction strategy (TWCS) With a 10 year retention, just ignore the target s

Re: Choosing a compaction strategy (TWCS)

cassandra.apache.org" <user@cassandra.apache.org> Subject: Choosing a compaction strategy (TWCS) 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 occu

Choosing a compaction strategy (TWCS)

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,

Re: Question about compaction strategy changes

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

Re: Question about compaction strategy changes

rds <s...@pubnub.com> > *Reply-To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Sunday, October 23, 2016 at 7:03 PM > *To: *user <user@cassandra.apache.org> > *Subject: *Re: Question about compaction strategy changes > > > >

Re: Question about compaction strategy changes

consumed by compaction in a TWCS setting. From: Seth Edwards <s...@pubnub.com> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> Date: Sunday, October 23, 2016 at 7:03 PM To: user <user@cassandra.apache.org> Subject: Re: Question about compacti

Re: Question about compaction strategy changes

​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

Re: Question about compaction strategy changes

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

Re: Question about compaction strategy changes

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

Re:Question about compaction strategy changes

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

Question about compaction strategy changes

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!

Re: upgradesstables/cleanup/compaction strategy change

Forsberg <forsb...@opera.com> wrote: > >> 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 changin

Re: upgradesstables/cleanup/compaction strategy change

uster 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 by avoid

upgradesstables/cleanup/compaction strategy change

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 by avoiding

Impact of Changing Compaction Strategy

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

Re: Impact of Changing Compaction Strategy

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

Re: Leveled Compaction Strategy with a really intensive delete workload

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 really intensive

Re: Leveled Compaction Strategy with a really intensive delete workload

. regards regards On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani ostef...@gmail.com 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 size (10

Re: Leveled Compaction Strategy with a really intensive delete workload

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 at 10:50 AM, Stefano Ortolani ostef...@gmail.com wrote: Hi all, I have a question re leveled compaction strategy that has

Re: Leveled Compaction Strategy with a really intensive delete workload

regards On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani ostef...@gmail.com 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 size (10 times

Re: Leveled Compaction Strategy with a really intensive delete workload

of with data tiered or size tiered strategy. regards regards On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani ostef...@gmail.com 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

Leveled Compaction Strategy with a really intensive delete workload

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

Re: Leveled Compaction Strategy with a really intensive delete workload

strategy. regards regards On Sun, May 24, 2015 at 10:50 AM, Stefano Ortolani ostef...@gmail.com 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

Date Tiered Compaction Strategy and collections

Hello all, If one has a table like this:id text,ts timestampvalues listtext  PK (id,ts)  How will the DTCS work? I am asking this because the writeTime() function does not work on collections.

Re: Date Tiered Compaction Strategy and collections

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 batra...@yahoo.com wrote: Hello all, If one has a table like this: id text, ts

Re: Compaction Strategy guidance

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 I/O system (@Andrei

Re: Compaction Strategy guidance

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 limitations. Increasing the size of sstables might help if you have enough CPU and you can

Re: Compaction Strategy guidance

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 I/O system (@Andrei, I am interested

Re: Compaction Strategy guidance

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 I/O system (@Andrei, I am interested

Re: Compaction Strategy guidance

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 limitations. Increasing the size of sstables might

Re: Compaction Strategy guidance

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 I/O system (@Andrei, I am interested by the results of your experimentation

Re: Compaction Strategy guidance

- 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 I/O system (@Andrei, I am interested by the results of your experimentation about large sstable files

Re: Compaction Strategy guidance

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 limitations. Increasing the size of sstables might

Re: Compaction Strategy guidance

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

Re: Compaction Strategy guidance

: 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 certain price. LCS will put most load on you

Re: Compaction Strategy guidance

...@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 certain price. LCS will put most load on you I/O system (if you use

Re: Compaction Strategy guidance

: user@cassandra.apache.org Asunto: Re: Compaction Strategy guidance Importancia: Alta 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

Re: Compaction Strategy guidance

. Para: user@cassandra.apache.org Asunto: Re: Compaction Strategy guidance Importancia: Alta 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

Re: Compaction Strategy guidance

Muñoz G. smg...@gmail.com wrote: 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

Re: Compaction Strategy guidance

On Mon, Nov 24, 2014 at 6:48 AM, Nikolai Grigoriev ngrigor...@gmail.com 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

Re: Compaction Strategy guidance

wrote: 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

Re: Compaction Strategy guidance

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 certain price. LCS will put most load on you I/O system (if you use spindles - you may need to be careful about

Re: Compaction Strategy guidance

, Servando Muñoz G. smg...@gmail.com wrote: 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

Re: Compaction Strategy guidance

. smg...@gmail.com wrote: 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

Re: Compaction Strategy guidance

@cassandra.apache.org Asunto: Re: Compaction Strategy guidance Importancia: Alta 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

Compaction Strategy guidance

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

Re: Compaction Strategy guidance

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)

RE: Compaction Strategy guidance

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

Re: Could table partitioning be implemented using a customer compaction strategy?

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 bur...@spinn3r.com wrote: We use log structured tables

Could table partitioning be implemented using a customer compaction strategy?

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 would take each

Customized Compaction Strategy: Dev Questions

Good morning! I've asked (and seen other people ask) about the ability to drop old sstables, basically creating a FIFO-like clean-up process. Since we're using Cassandra as an auditing system, this is particularly appealing to us because it means we can maximize the amount of auditing data we

Re: Customized Compaction Strategy: Dev Questions

You mean this: https://issues.apache.org/jira/browse/CASSANDRA-5228 ? On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote: Good morning! I've asked (and seen other people ask) about the ability to drop old sstables, basically creating a FIFO-like clean-up process.  Since

Re: Customized Compaction Strategy: Dev Questions

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest sstable rather than simply run out of space. The problem with using TTLs is that I have to try and guess how much data is being put in--since this is auditing data, the usage can vary wildly depending on time of year, verbosity

  1   2   >