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, "ishib...@gmail.com" <ishib...@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, "ishib...@gmail.com" <ishib...@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 <sean_r_dur...@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 <doanduy...@gmail.com> >>> Sent: Wednesday, February 13, 2019 8:08 AM >>> To: user <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 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 <vsfilare...@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Ð
