You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Phil Luckhurst <ph...@powerassure.com> on 2014/05/19 15:31:17 UTC
Can SSTables overlap with SizeTieredCompactionStrategy?
We have a table defined using SizeTieredCompactionStrategy that is used to
store time series data. Over a period of a few days we wrote approximately
200,000 unique time based entries for each of 700 identifiers, i.e. 700 wide
rows with 200,000 entries in each. The table was empty when we started and
and there were no updates to any entries, no deletions, and no tombstones
were created.
Our estimates suggested that this should have required about 7GB of disk
space but when we looked on disk there were 8 sstables taking up 11GB of
space.
Running nodetool compact on the column family reduced it to a single sstable
that does match our 7GB estimate.
I'd like to understand what accounts for the other 4GB when it was stored as
multiple sstables? Is it because the individual sstables overlap?
Thanks
Phil
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
Re: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Prem Yadav <ip...@gmail.com>.
I would think its because of the index and filter files. Also the
additional data which gets added because of serialization. Also, since
SStables are only deleted after the compaction us finished, it might be
possible that when you checked, the intermediate SSTables were not yet
deleted.
However, 50% additional disk usage does sound bad.
On Wed, May 21, 2014 at 4:42 PM, Phil Luckhurst <
phil.luckhurst@powerassure.com> wrote:
> I'm wondering if the lack of response to this means it was a dumb question
> however I've searched the documentation again but I still can't find an
> answer :-(
>
> Phil
>
>
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594627.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at
> Nabble.com.
>
Re: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Aaron Morton <aa...@thelastpickle.com>.
cold_reads_to_omit defaults to 0.0 which disabled the feature, so it may not have been responsible in this case.
There are a couple of things that could explain the difference:
* after nodetool compaction there was one SSTable, so one -Filter.db file rather than 8 that each had 700 entires. However 700 entries is not very many so this would have been a small size on disk.
* Same story with the -Index.db files, they would have all had the same values but that would not have been very with big with 700 entries. However with the wide rows column indexes would have also been present in the -Index.db file.
* Compression may have been better. In the when you have one SSTable all the columns for the row will be stored sequentially and it may have just had better compression.
If most of the difference was in the -Data.db files I would guess compression, nodetool cfstats will tell you the compression ratio.
Hope that helps.
Aaron
-----------------
Aaron Morton
New Zealand
@aaronmorton
Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com
On 23/05/2014, at 9:46 am, Phil Luckhurst <ph...@powerassure.com> wrote:
> Hi Andreas,
>
> So does that mean it can compact the 'hottest' partitions into a new sstable
> but the old sstables may not immediately be removed so the same data could
> be in more that one sstable? That would certainly explain the difference we
> see when we manually run nodetool compact.
>
> Thanks
> Phil
>
>
> Andreas Finke wrote
>> Hi Phil,
>>
>> I found an interesting blog entry that may address your problem.
>>
>> http://www.datastax.com/dev/blog/optimizations-around-cold-sstables
>>
>> It seems that compaction is skipped for stables which so mit satisfy a
>> certain read rate. Please check.
>>
>>
>> Kind regards
>>
>> Andreas Finke
>> Java Developer
>> Solvians IT-Solutions GmbH
>>
>>
>> ---- Phil Luckhurst wrote ----
>>
>> Definitely no TTL and records are only written once with no deletions.
>>
>> Phil
>>
>>
>> DuyHai Doan wrote
>>> Are you sure there is no TTL set on your data? It might explain the
>>> shrink
>>> in sstable size after compaction.
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594644.html
>> Sent from the
>
>> cassandra-user@.apache
>
>> mailing list archive at Nabble.com.
>
>
>
>
>
> --
> View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594658.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Phil Luckhurst <ph...@powerassure.com>.
Hi Andreas,
So does that mean it can compact the 'hottest' partitions into a new sstable
but the old sstables may not immediately be removed so the same data could
be in more that one sstable? That would certainly explain the difference we
see when we manually run nodetool compact.
Thanks
Phil
Andreas Finke wrote
> Hi Phil,
>
> I found an interesting blog entry that may address your problem.
>
> http://www.datastax.com/dev/blog/optimizations-around-cold-sstables
>
> It seems that compaction is skipped for stables which so mit satisfy a
> certain read rate. Please check.
>
>
> Kind regards
>
> Andreas Finke
> Java Developer
> Solvians IT-Solutions GmbH
>
>
> ---- Phil Luckhurst wrote ----
>
> Definitely no TTL and records are only written once with no deletions.
>
> Phil
>
>
> DuyHai Doan wrote
>> Are you sure there is no TTL set on your data? It might explain the
>> shrink
>> in sstable size after compaction.
>
>
>
>
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594644.html
> Sent from the
> cassandra-user@.apache
> mailing list archive at Nabble.com.
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594658.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Andreas Finke <An...@solvians.com>.
Hi Phil,
I found an interesting blog entry that may address your problem.
http://www.datastax.com/dev/blog/optimizations-around-cold-sstables
It seems that compaction is skipped for stables which so mit satisfy a certain read rate. Please check.
Kind regards
Andreas Finke
Java Developer
Solvians IT-Solutions GmbH
---- Phil Luckhurst wrote ----
Definitely no TTL and records are only written once with no deletions.
Phil
DuyHai Doan wrote
> Are you sure there is no TTL set on your data? It might explain the shrink
> in sstable size after compaction.
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594644.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Phil Luckhurst <ph...@powerassure.com>.
Definitely no TTL and records are only written once with no deletions.
Phil
DuyHai Doan wrote
> Are you sure there is no TTL set on your data? It might explain the shrink
> in sstable size after compaction.
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594644.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by DuyHai Doan <do...@gmail.com>.
Are you sure there is no TTL set on your data? It might explain the shrink
in sstable size after compaction.
Le 21 mai 2014 23:17, "Phil Luckhurst" <ph...@powerassure.com> a
écrit :
> We based the estimate on a previous controlled observation. We generated a
> year's worth of one minute data for a single identifier and recorded the
> size of the resulting sstable. By adding the data one month at a time we
> observed that there was a linear predictable increase in the sstable size.
> Using this we simply multiplied by the number of identifiers, in this case
> 700, to get the 7GB estimate.
> And as noted above this estimate is correct once the data is compacted to
> one sstable but is wrong when there are multiple sstables.
>
> Phil
>
>
> Andreas Finke wrote
> > Hi Phil,
> >
> > there is no dump question ;) What is your size estimation based on e.g.
> > what size is a column in your calculation?
>
>
>
>
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594641.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at
> Nabble.com.
>
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Phil Luckhurst <ph...@powerassure.com>.
We based the estimate on a previous controlled observation. We generated a
year's worth of one minute data for a single identifier and recorded the
size of the resulting sstable. By adding the data one month at a time we
observed that there was a linear predictable increase in the sstable size.
Using this we simply multiplied by the number of identifiers, in this case
700, to get the 7GB estimate.
And as noted above this estimate is correct once the data is compacted to
one sstable but is wrong when there are multiple sstables.
Phil
Andreas Finke wrote
> Hi Phil,
>
> there is no dump question ;) What is your size estimation based on e.g.
> what size is a column in your calculation?
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594641.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
RE: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Andreas Finke <An...@solvians.com>.
Hi Phil,
there is no dump question ;) What is your size estimation based on e.g. what size is a column in your calculation?
________________________________________
From: Phil Luckhurst [phil.luckhurst@powerassure.com]
Sent: Wednesday, May 21, 2014 5:42 PM
To: cassandra-user@incubator.apache.org
Subject: Re: Can SSTables overlap with SizeTieredCompactionStrategy?
I'm wondering if the lack of response to this means it was a dumb question
however I've searched the documentation again but I still can't find an
answer :-(
Phil
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594627.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.
Re: Can SSTables overlap with SizeTieredCompactionStrategy?
Posted by Phil Luckhurst <ph...@powerassure.com>.
I'm wondering if the lack of response to this means it was a dumb question
however I've searched the documentation again but I still can't find an
answer :-(
Phil
--
View this message in context: http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574p7594627.html
Sent from the cassandra-user@incubator.apache.org mailing list archive at Nabble.com.