Thanks Aaron.. I was looking to spliting the rows so that I could use a standard CF instead of super.. but your argument also makes sense.
On Thu, Feb 24, 2011 at 1:19 AM, Aaron Morton <aa...@thelastpickle.com> wrote: > AFAIK performance in the single row case will better. Multi get may require > multiple seeks and reads in an sstable,, verses obviously a single seek and > read for a single row. Multiplied by the number of sstables that contain row > data. > > Using the key cache would reduce the the seeks. > > If it makes sense in your app do it. In general though try to model data so a > single row read gets what you need. > > Aaron > > On 24/02/2011, at 5:59 AM, Aditya Narayan <ady...@gmail.com> wrote: > >> Does it make any difference if I split a row, that needs to be >> accessed together, into two or three rows and then read those multiple >> rows ?? >> (Assume the keys of all the three rows are known to me programatically >> since I split columns by certain categories). >> Would the performance be any better if all the three were just a single row >> ?? >> >> I guess the performance should be same in both cases, the columns >> remain the same in quantity & there spread into several SST files.. >
