Yulian; 
Quote :Raw size is aroung 190MB.There are bigger raws with similar structure ( 
its index raws , which actually stores keys ) and everything is working fine on 
them, everything is working also fine on this cf but on other raw.
Tables data from CFStats ( First table has bigger raws but works fine , where 
second has timeout ) :
---------------------------
You asked: There are bigger raws with similar structure Question:  Do you mean 
bigger rows  ?      What is the structure of the statuspindexes Keyspace & 
which table are you querying within it ?
you asked:  its index raws , which actually stores keysQuestion:  do you mean 
Index rows ?     how are you creating Indexes  , what type of Indexes ?  
you asked: Tables data from CFStats,  where second has timeout Question:  What 
is the time out value set at  & whats different about both these tables ?     
What are you querying from the second table ? 

Unfortunately,  I have more questions that answers;  however  despite the 
sacrilege of using super-columns (lol), there has got to be a logical answer to 
the Performance problem you are having.       Hopefully we could dig in and 
find an answer . 

Jan/  



 



     On Tuesday, February 24, 2015 12:00 PM, Robert Coli <rc...@eventbrite.com> 
wrote:
   

 On Tue, Feb 24, 2015 at 8:50 AM, Yulian Oifa <oifa.yul...@gmail.com> wrote:

The structure is the same , the CFs are super column CFs , where key is long  ( 
timestamp to partition the index , so each 11 days new row is created ) , super 
Column is int32 and columns / values are timeuuids.I am running same queries , 
getting reversed slice by raw key and super column.

Obligatory notice that Super Columns are not really recommended for use. I have 
no idea if the performance problem you are seeing is related to the use of 
Super Columns.
=Rob 

  

Reply via email to