Ah, clear then. SSD usage imposes a different bias in terms of costs;-)
On Tue, Nov 25, 2014 at 9:48 PM, Nikolai Grigoriev wrote:
> Andrei,
>
> Oh, yes, I have scanned the top of your previous email but overlooked the
> last part.
>
> I am using SSDs so I prefer to put extra work to keep my syste
Andrei,
Oh, yes, I have scanned the top of your previous email but overlooked the
last part.
I am using SSDs so I prefer to put extra work to keep my system performing
and save expensive disk space. So far I've been able to size the system
more or less correctly so these LCS limitations do not ca
Nikolai,
Just in case you've missed my comment in the thread (guess you have) -
increasing sstable size does nothing (in our case at least). That is,
it's not worse but the load pattern is still the same - doing nothing
most of the time. So, I switched to STCS and we will have to live with
extra s
Hi Jean-Armel,
I am using latest and greatest DSE 4.5.2 (4.5.3 in another cluster but
there are no relevant changes between 4.5.2 and 4.5.3) - thus, Cassandra
2.0.10.
I have about 1,8Tb of data per node now in total, which falls into that
range.
As I said, it is really a problem with large amoun
Yep, Marcus, I know. It's mainly a question of cost of those extra x2
disks, you know. Our "final" setup will be more like 30TB, so doubling
it is still some cost. But i guess, we will have to live with it
On Tue, Nov 25, 2014 at 1:26 PM, Marcus Eriksson wrote:
> If you are that write-heavy you s
If you are that write-heavy you should definitely go with STCS, LCS
optimizes for reads by doing more compactions
/Marcus
On Tue, Nov 25, 2014 at 11:22 AM, Andrei Ivanov wrote:
> Hi Jean-Armel, Nikolai,
>
> 1. Increasing sstable size doesn't work (well, I think, unless we
> "overscale" - add mo
Hi Jean-Armel, Nikolai,
1. Increasing sstable size doesn't work (well, I think, unless we
"overscale" - add more nodes than really necessary, which is
prohibitive for us in a way). Essentially there is no change. I gave
up and will go for STCS;-(
2. We use 2.0.11 as of now
3. We are running on EC
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-cassandra-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
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
23 matches
Mail list logo
