@all, thank you for your answers, Jeff, Thank you very much, will look into it.
ср, 13 февр. 2019 г., 18:38 Jeff Jirsa jji...@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 <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 > <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 <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. > >
