You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Durity, Sean R" <SE...@homedepot.com> on 2019/02/13 13:48:37 UTC
RE: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
Agreed. It’s pretty close to impossible to administrate your way out of a data model that doesn’t play to Cassandra’s strengths. Which is true for other data storage technologies – you need to model the data the way that the engine is designed to work.
Sean Durity
From: DuyHai Doan <do...@gmail.com>
Sent: Wednesday, February 13, 2019 8:08 AM
To: user <us...@cassandra.apache.org>
Subject: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
Plain answer is NO
There is a slight hope that the JIRA https://issues.apache.org/jira/browse/CASSANDRA-9754<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D9754&d=DwMFaQ&c=MtgQEAMQGqekjTjiAhkudQ&r=aC_gxC6z_4f9GLlbWiKzHm1vucZTtVYWDDvyLkh8IaQ&m=YH5vXIEwCC-CMZNOyNJCAHTeso6N1JZHkgoolKHKQjE&s=KjhchSZTtYYl60nfet6WB1fQd-Ph2P-YOD-GQzUJj2o&e=> gets into 4.0 release
But right now, there seems to be few interest in this ticket, the last comment 23/Feb/2017 old ...
On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov <vs...@gmail.com>> wrote:
Hi all,
The question.
We have Cassandra 3.11.1 with really heavy primary partitions:
cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%% partition size is 220+ mb sometimes partitions are 1+ gb. We have regular problems with node lockdowns leading to read request timeouts under read requests load.
Changing primary partition key structure is out of question.
Are there any sharding techniques available to dilute partitions at level lower than 'select' requests to make read performance better? Without changing read requests syntax?
Thank you all in advance,
Vsevolod Filaretov.
________________________________
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
Posted by Vsevolod Filaretov <vs...@gmail.com>.
@all, thank you for your answers,
Jeff, Thank you very much, will look into it.
ср, 13 февр. 2019 г., 18:38 Jeff Jirsa jjirsa@gmail.com:
> Cassandra-11206 (https://issues.apache.org/jira/browse/CASSANDRA-11206)
> is in 3.11 and does have a few knobs to make this less painful
>
> You can also increase the column index size from 64kb to something
> significantly higher to decrease the cost of those reads on the JVM
> (shifting cost to the disk) - consider 256k or 512k for 100-1000mb
> partitions.
>
> --
> Jeff Jirsa
>
>
> On Feb 13, 2019, at 5:48 AM, Durity, Sean R <SE...@homedepot.com>
> wrote:
>
> Agreed. It’s pretty close to impossible to administrate your way out of a
> data model that doesn’t play to Cassandra’s strengths. Which is true for
> other data storage technologies – you need to model the data the way that
> the engine is designed to work.
>
>
>
>
>
> Sean Durity
>
>
>
> *From:* DuyHai Doan <do...@gmail.com>
> *Sent:* Wednesday, February 13, 2019 8:08 AM
> *To:* user <us...@cassandra.apache.org>
> *Subject:* [EXTERNAL] Re: Make large partitons lighter on select without
> changing primary partition formation.
>
>
>
> Plain answer is NO
>
>
>
> There is a slight hope that the JIRA
> https://issues.apache.org/jira/browse/CASSANDRA-9754
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D9754&d=DwMFaQ&c=MtgQEAMQGqekjTjiAhkudQ&r=aC_gxC6z_4f9GLlbWiKzHm1vucZTtVYWDDvyLkh8IaQ&m=YH5vXIEwCC-CMZNOyNJCAHTeso6N1JZHkgoolKHKQjE&s=KjhchSZTtYYl60nfet6WB1fQd-Ph2P-YOD-GQzUJj2o&e=>
> gets into 4.0 release
>
>
>
> But right now, there seems to be few interest in this ticket, the last
> comment 23/Feb/2017 old ...
>
>
>
>
>
> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov <vs...@gmail.com>
> wrote:
>
> Hi all,
>
>
>
> The question.
>
>
>
> We have Cassandra 3.11.1 with really heavy primary partitions:
>
> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%%
> partition size is 220+ mb sometimes partitions are 1+ gb. We have regular
> problems with node lockdowns leading to read request timeouts under read
> requests load.
>
>
>
> Changing primary partition key structure is out of question.
>
>
>
> Are there any sharding techniques available to dilute partitions at level
> lower than 'select' requests to make read performance better? Without
> changing read requests syntax?
>
>
>
> Thank you all in advance,
>
> Vsevolod Filaretov.
>
>
> ------------------------------
>
> The information in this Internet Email is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this Email
> by anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it, is prohibited and may be unlawful. When addressed
> to our clients any opinions or advice contained in this Email are subject
> to the terms and conditions expressed in any applicable governing The Home
> Depot terms of business or client engagement letter. The Home Depot
> disclaims all responsibility and liability for the accuracy and content of
> this attachment and for any damages or losses arising from any
> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other
> items of a destructive nature, which may be contained in this attachment
> and shall not be liable for direct, indirect, consequential or special
> damages in connection with this e-mail message or its attachment.
>
>
Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
Posted by Jeff Jirsa <jj...@gmail.com>.
It takes effect on each sstable as it’s written, so you have to rewrite your dataset before it’s fully in effect
You can do that with “nodetool upgradesstables -a”
--
Jeff Jirsa
> On Feb 13, 2019, at 11:43 PM, "ishibaev@gmail.com" <is...@gmail.com> wrote:
>
> Hi Jeff,
> If increase the value, it will affect only newly created indexes. Will repair rebuilds old indexes with new , larger, size, or leave them with the same size?
>
> Best regards, Ilya
>
>
>
> -------- ИÑходное Ñообщение --------
> Тема: Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
> От: Jeff Jirsa
> Кому: user@cassandra.apache.org
> КопиÑ:
>
>
> We build an index on each partition as we write it - in 3.0 it’s a list that relates the clustering columns for a given partition key to a point in the file. When you read, we use that index to skip to the point at the beginning of your read.
>
> That 64k value is just a default that few people ever have reason to change - it’s somewhat similar to the 64k compression chunk size, though they’re not aligned.
>
> If you increase the value from 64k to 128k, you’ll have half as many index markers per partition. This means when you use the index, you’ll do a bit more IO to find the actual start of your result. However, it also means you have half as many index objects created in the heap on reads - for many uses cases with wife partitions, the indexinfo objects on reads create far too much garbage and cause bad latency/gc. This just gives you a way to trade off between the two options - disk IO or gc pauses.
>
>
> --
> Jeff Jirsa
>
>
>> On Feb 13, 2019, at 10:45 PM, "ishibaev@gmail.com" <is...@gmail.com> wrote:
>>
>> Hello!
>> increase column_index_size_in_kb for rarely index creations, am I correct?
>> But will it be used in every read request, or column index for queries within a row only?
>>
>> Best regards, Ilya
>>
>>
>>
>> -------- ØÑÂхþôýþõ ÑÂþþñщõýøõ --------
>> âõüð: Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
>> Þт: Jeff Jirsa
>> Úþüу: user@cassandra.apache.org
>> ÚþÿøÑÂ:
>>
>>
>> Cassandra-11206 (https://issues.apache.org/jira/browse/CASSANDRA-11206) is in 3.11 and does have a few knobs to make this less painful
>>
>> You can also increase the column index size from 64kb to something significantly higher to decrease the cost of those reads on the JVM (shifting cost to the disk) - consider 256k or 512k for 100-1000mb partitions.
>>
>> --
>> Jeff Jirsa
>>
>>
>>> On Feb 13, 2019, at 5:48 AM, Durity, Sean R <SE...@homedepot.com> wrote:
>>>
>>> Agreed. It’s pretty close to impossible to administrate your way out of a data model that doesn’t play to Cassandra’s strengths. Which is true for other data storage technologies – you need to model the data the way that the engine is designed to work.
>>>
>>>
>>> Sean Durity
>>>
>>> From: DuyHai Doan <do...@gmail.com>
>>> Sent: Wednesday, February 13, 2019 8:08 AM
>>> To: user <us...@cassandra.apache.org>
>>> Subject: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
>>>
>>> Plain answer is NO
>>>
>>> There is a slight hope that the JIRA https://issues.apache.org/jira/browse/CASSANDRA-9754 gets into 4.0 release
>>>
>>> But right now, there seems to be few interest in this ticket, the last comment 23/Feb/2017 old ...
>>>
>>>
>>> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov <vs...@gmail.com> wrote:
>>> Hi all,
>>>
>>> The question.
>>>
>>> We have Cassandra 3.11.1 with really heavy primary partitions:
>>> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%% partition size is 220+ mb sometimes partitions are 1+ gb. We have regular problems with node lockdowns leading to read request timeouts under read requests load.
>>>
>>> Changing primary partition key structure is out of question.
>>>
>>> Are there any sharding techniques available to dilute partitions at level lower than 'select' requests to make read performance better? Without changing read requests syntax?
>>>
>>> Thank you all in advance,
>>> Vsevolod Filaretov.
>>>
>>>
>>> The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
>> âÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÃÃÂ¥FòVç7V'67&–&RÂRÖ֖âW6W"×Vç7V'67&–&T676æG&æ6†Ræ÷&päf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W"Ö†VÇ676æG&æ6†Ræ÷&pÃ
> ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖ֖âW6W"×Vç7V'67&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W"Ö†VÇ676æG&æ6†Ræ÷&pÐ
Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
Posted by "ishibaev@gmail.com" <is...@gmail.com>.
Hi Jeff,
If increase the value, it will affect only newly created indexes. Will repair
rebuilds old indexes with new , larger, size, or leave them with the same
size?
Best regards, Ilya
\-------- Исходное сообщение --------
Тема: Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
От: Jeff Jirsa
Кому: user@cassandra.apache.org
Копия:
> We build an index on each partition as we write it - in 3.0 it’s a list that
relates the clustering columns for a given partition key to a point in the
file. When you read, we use that index to skip to the point at the beginning
of your read.
>
>
>
>
> That 64k value is just a default that few people ever have reason to change
- it’s somewhat similar to the 64k compression chunk size, though they’re not
aligned.
>
>
>
>
> If you increase the value from 64k to 128k, you’ll have half as many index
markers per partition. This means when you use the index, you’ll do a bit more
IO to find the actual start of your result. However, it also means you have
half as many index objects created in the heap on reads - for many uses cases
with wife partitions, the indexinfo objects on reads create far too much
garbage and cause bad latency/gc. This just gives you a way to trade off
between the two options - disk IO or gc pauses.
>
>
>
>
>
>
>
> \--
>
> Jeff Jirsa
>
>
>
>
>
> On Feb 13, 2019, at 10:45 PM,
"[ishibaev@gmail.com](mailto:ishibaev@gmail.com)"
<[ishibaev@gmail.com](mailto:ishibaev@gmail.com)> wrote:
>
>
>
>> Hello!
> increase column_index_size_in_kb for rarely index creations, am I correct?
> But will it be used in every read request, or column index for queries
within a row only?
>
> Best regards, Ilya
>
>
>>
>>
>
> \-------- ИÑходное Ñообщение --------
> Тема: Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
> От: Jeff Jirsa
> Кому: [user@cassandra.apache.org](mailto:user@cassandra.apache.org)
> КопиÑ:
>
>
>
>>
>>> Cassandra-11206 (<https://issues.apache.org/jira/browse/CASSANDRA-11206>)
is in 3.11 and does have a few knobs to make this less painful
>>>
>>>
>
>>>
>>> You can also increase the column index size from 64kb to something
significantly higher to decrease the cost of those reads on the JVM (shifting
cost to the disk) - consider 256k or 512k for 100-1000mb partitions.
>
>
>>>
>>> \--
>>>
>>> Jeff Jirsa
>>>
>>>
>
>>>
>>>
> On Feb 13, 2019, at 5:48 AM, Durity, Sean R
<[SEAN_R_DURITY@homedepot.com](mailto:SEAN_R_DURITY@homedepot.com)> wrote:
>
>
>>>
>>>> Agreed. It’s pretty close to impossible to administrate your way out of
a data model that doesn’t play to Cassandra’s strengths. Which is true for
other data storage technologies – you need to model the data the way that
the engine is designed to work.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Sean Durity
>>>>
>>>>
>>>>
>>>> **From:** DuyHai Doan
<[doanduyhai@gmail.com](mailto:doanduyhai@gmail.com)>
> **Sent:** Wednesday, February 13, 2019 8:08 AM
> **To:** user
<[user@cassandra.apache.org](mailto:user@cassandra.apache.org)>
> **Subject:** [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
>>>>
>>>>
>>>>
>>>> Plain answer is NO
>>>>
>>>>
>>>>
>>>> There is a slight hope that the JIRA
[https://issues.apache.org/jira/browse/CASSANDRA-9754](https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D9754&d=DwMFaQ&c=MtgQEAMQGqekjTjiAhkudQ&r=aC_gxC6z_4f9GLlbWiKzHm1vucZTtVYWDDvyLkh8IaQ&m=YH5vXIEwCC-
CMZNOyNJCAHTeso6N1JZHkgoolKHKQjE&s=KjhchSZTtYYl60nfet6WB1fQd-Ph2P-YOD-
GQzUJj2o&e=) gets into 4.0 release
>>>>
>>>>
>>>>
>>>> But right now, there seems to be few interest in this ticket, the last
comment 23/Feb/2017 old ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov
<[vsfilaretov@gmail.com](mailto:vsfilaretov@gmail.com)> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> The question.
>>>>>
>>>>>
>>>>>
>>>>> We have Cassandra 3.11.1 with really heavy primary partitions:
>>>>>
>>>>> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%%
partition size is 220+ mb sometimes partitions are 1+ gb. We have regular
problems with node lockdowns leading to read request timeouts under read
requests load.
>>>>>
>>>>>
>>>>>
>>>>> Changing primary partition key structure is out of question.
>>>>>
>>>>>
>>>>>
>>>>> Are there any sharding techniques available to dilute partitions at
level lower than 'select' requests to make read performance better? Without
changing read requests syntax?
>>>>>
>>>>>
>>>>>
>>>>> Thank you all in advance,
>>>>>
>>>>> Vsevolod Filaretov.
>>>>
>>>>
>
>>>>
>>>> * * *
>>>>
>>>>
> The information in this Internet Email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this Email by
anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful. When addressed to our
clients any opinions or advice contained in this Email are subject to the
terms and conditions expressed in any applicable governing The Home Depot
terms of business or client engagement letter. The Home Depot disclaims all
responsibility and liability for the accuracy and content of this attachment
and for any damages or losses arising from any inaccuracies, errors, viruses,
e.g., worms, trojan horses, etc., or other items of a destructive nature,
which may be contained in this attachment and shall not be liable for direct,
indirect, consequential or special damages in connection with this e-mail
message or its attachment.
>
>>
>>
ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖ֖âW6W"×Vç7V'67&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W"Ö†VÇ676æG&æ6†Ræ÷&pÐ
Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
Posted by Jeff Jirsa <jj...@gmail.com>.
We build an index on each partition as we write it - in 3.0 it’s a list that relates the clustering columns for a given partition key to a point in the file. When you read, we use that index to skip to the point at the beginning of your read.
That 64k value is just a default that few people ever have reason to change - it’s somewhat similar to the 64k compression chunk size, though they’re not aligned.
If you increase the value from 64k to 128k, you’ll have half as many index markers per partition. This means when you use the index, you’ll do a bit more IO to find the actual start of your result. However, it also means you have half as many index objects created in the heap on reads - for many uses cases with wife partitions, the indexinfo objects on reads create far too much garbage and cause bad latency/gc. This just gives you a way to trade off between the two options - disk IO or gc pauses.
--
Jeff Jirsa
> On Feb 13, 2019, at 10:45 PM, "ishibaev@gmail.com" <is...@gmail.com> wrote:
>
> Hello!
> increase column_index_size_in_kb for rarely index creations, am I correct?
> But will it be used in every read request, or column index for queries within a row only?
>
> Best regards, Ilya
>
>
>
> -------- ИÑходное Ñообщение --------
> Тема: Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
> От: Jeff Jirsa
> Кому: user@cassandra.apache.org
> КопиÑ:
>
>
> Cassandra-11206 (https://issues.apache.org/jira/browse/CASSANDRA-11206) is in 3.11 and does have a few knobs to make this less painful
>
> You can also increase the column index size from 64kb to something significantly higher to decrease the cost of those reads on the JVM (shifting cost to the disk) - consider 256k or 512k for 100-1000mb partitions.
>
> --
> Jeff Jirsa
>
>
>> On Feb 13, 2019, at 5:48 AM, Durity, Sean R <SE...@homedepot.com> wrote:
>>
>> Agreed. It’s pretty close to impossible to administrate your way out of a data model that doesn’t play to Cassandra’s strengths. Which is true for other data storage technologies – you need to model the data the way that the engine is designed to work.
>>
>>
>> Sean Durity
>>
>> From: DuyHai Doan <do...@gmail.com>
>> Sent: Wednesday, February 13, 2019 8:08 AM
>> To: user <us...@cassandra.apache.org>
>> Subject: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
>>
>> Plain answer is NO
>>
>> There is a slight hope that the JIRA https://issues.apache.org/jira/browse/CASSANDRA-9754 gets into 4.0 release
>>
>> But right now, there seems to be few interest in this ticket, the last comment 23/Feb/2017 old ...
>>
>>
>> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov <vs...@gmail.com> wrote:
>> Hi all,
>>
>> The question.
>>
>> We have Cassandra 3.11.1 with really heavy primary partitions:
>> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%% partition size is 220+ mb sometimes partitions are 1+ gb. We have regular problems with node lockdowns leading to read request timeouts under read requests load.
>>
>> Changing primary partition key structure is out of question.
>>
>> Are there any sharding techniques available to dilute partitions at level lower than 'select' requests to make read performance better? Without changing read requests syntax?
>>
>> Thank you all in advance,
>> Vsevolod Filaretov.
>>
>>
>> The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
> ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖ֖âW6W"×Vç7V'67&–&T676æG&æ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖ֖âW6W"Ö†VÇ676æG&æ6†Ræ÷&pÐ
Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
Posted by "ishibaev@gmail.com" <is...@gmail.com>.
Hello!
increase column_index_size_in_kb for rarely index creations, am I correct?
But will it be used in every read request, or column index for queries within
a row only?
Best regards, Ilya
\-------- Исходное сообщение --------
Тема: Re: [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
От: Jeff Jirsa
Кому: user@cassandra.apache.org
Копия:
> Cassandra-11206 (<https://issues.apache.org/jira/browse/CASSANDRA-11206>) is
in 3.11 and does have a few knobs to make this less painful
>
>
>
>
> You can also increase the column index size from 64kb to something
significantly higher to decrease the cost of those reads on the JVM (shifting
cost to the disk) - consider 256k or 512k for 100-1000mb partitions.
>
>
>
> \--
>
> Jeff Jirsa
>
>
>
>
>
> On Feb 13, 2019, at 5:48 AM, Durity, Sean R
<[SEAN_R_DURITY@homedepot.com](mailto:SEAN_R_DURITY@homedepot.com)> wrote:
>
>
>
>> Agreed. It’s pretty close to impossible to administrate your way out of a
data model that doesn’t play to Cassandra’s strengths. Which is true for other
data storage technologies – you need to model the data the way that the engine
is designed to work.
>>
>>
>>
>>
>>
>> Sean Durity
>>
>>
>>
>> **From:** DuyHai Doan
<[doanduyhai@gmail.com](mailto:doanduyhai@gmail.com)>
> **Sent:** Wednesday, February 13, 2019 8:08 AM
> **To:** user
<[user@cassandra.apache.org](mailto:user@cassandra.apache.org)>
> **Subject:** [EXTERNAL] Re: Make large partitons lighter on select without
changing primary partition formation.
>>
>>
>>
>> Plain answer is NO
>>
>>
>>
>> There is a slight hope that the JIRA
[https://issues.apache.org/jira/browse/CASSANDRA-9754](https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D9754&d=DwMFaQ&c=MtgQEAMQGqekjTjiAhkudQ&r=aC_gxC6z_4f9GLlbWiKzHm1vucZTtVYWDDvyLkh8IaQ&m=YH5vXIEwCC-
CMZNOyNJCAHTeso6N1JZHkgoolKHKQjE&s=KjhchSZTtYYl60nfet6WB1fQd-Ph2P-YOD-
GQzUJj2o&e=) gets into 4.0 release
>>
>>
>>
>> But right now, there seems to be few interest in this ticket, the last
comment 23/Feb/2017 old ...
>>
>>
>>
>>
>>
>> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov
<[vsfilaretov@gmail.com](mailto:vsfilaretov@gmail.com)> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> The question.
>>>
>>>
>>>
>>> We have Cassandra 3.11.1 with really heavy primary partitions:
>>>
>>> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%%
partition size is 220+ mb sometimes partitions are 1+ gb. We have regular
problems with node lockdowns leading to read request timeouts under read
requests load.
>>>
>>>
>>>
>>> Changing primary partition key structure is out of question.
>>>
>>>
>>>
>>> Are there any sharding techniques available to dilute partitions at level
lower than 'select' requests to make read performance better? Without changing
read requests syntax?
>>>
>>>
>>>
>>> Thank you all in advance,
>>>
>>> Vsevolod Filaretov.
>>
>>
>
>>
>> * * *
>>
>>
> The information in this Internet Email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this Email by
anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it, is prohibited and may be unlawful. When addressed to our
clients any opinions or advice contained in this Email are subject to the
terms and conditions expressed in any applicable governing The Home Depot
terms of business or client engagement letter. The Home Depot disclaims all
responsibility and liability for the accuracy and content of this attachment
and for any damages or losses arising from any inaccuracies, errors, viruses,
e.g., worms, trojan horses, etc., or other items of a destructive nature,
which may be contained in this attachment and shall not be liable for direct,
indirect, consequential or special damages in connection with this e-mail
message or its attachment.
>
Re: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
Posted by Jeff Jirsa <jj...@gmail.com>.
Cassandra-11206 (https://issues.apache.org/jira/browse/CASSANDRA-11206) is in 3.11 and does have a few knobs to make this less painful
You can also increase the column index size from 64kb to something significantly higher to decrease the cost of those reads on the JVM (shifting cost to the disk) - consider 256k or 512k for 100-1000mb partitions.
--
Jeff Jirsa
> On Feb 13, 2019, at 5:48 AM, Durity, Sean R <SE...@homedepot.com> wrote:
>
> Agreed. It’s pretty close to impossible to administrate your way out of a data model that doesn’t play to Cassandra’s strengths. Which is true for other data storage technologies – you need to model the data the way that the engine is designed to work.
>
>
> Sean Durity
>
> From: DuyHai Doan <do...@gmail.com>
> Sent: Wednesday, February 13, 2019 8:08 AM
> To: user <us...@cassandra.apache.org>
> Subject: [EXTERNAL] Re: Make large partitons lighter on select without changing primary partition formation.
>
> Plain answer is NO
>
> There is a slight hope that the JIRA https://issues.apache.org/jira/browse/CASSANDRA-9754 gets into 4.0 release
>
> But right now, there seems to be few interest in this ticket, the last comment 23/Feb/2017 old ...
>
>
> On Wed, Feb 13, 2019 at 1:18 PM Vsevolod Filaretov <vs...@gmail.com> wrote:
> Hi all,
>
> The question.
>
> We have Cassandra 3.11.1 with really heavy primary partitions:
> cfhistograms 95%% is 130+ mb, 95%% cell count is 3.3mln and higher, 98%% partition size is 220+ mb sometimes partitions are 1+ gb. We have regular problems with node lockdowns leading to read request timeouts under read requests load.
>
> Changing primary partition key structure is out of question.
>
> Are there any sharding techniques available to dilute partitions at level lower than 'select' requests to make read performance better? Without changing read requests syntax?
>
> Thank you all in advance,
> Vsevolod Filaretov.
>
>
> The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.