Oh I see. I understand it now. Thank you for the clarification!
Preetika
On Tue, Mar 21, 2017 at 11:07 AM, Jonathan Haddad wrote:
> Each sstable has it's own partition index, therefore it's never updated.
>
> On Tue, Mar 21, 2017 at 11:04 AM preetika tyagi
Each sstable has it's own partition index, therefore it's never updated.
On Tue, Mar 21, 2017 at 11:04 AM preetika tyagi
wrote:
> Yes, I understand that. However, what I'm trying to understand is the
> internal structure of partition index. When a record associate with
Yes, I understand that. However, what I'm trying to understand is the
internal structure of partition index. When a record associate with the
same partition key is updated, we have two different records with different
timestamps. There are chances of these two records being split across two
The partition index is never updated, as sstables are immutable.
On Tue, Mar 21, 2017 at 9:40 AM preetika tyagi
wrote:
> Thank you Jan & Jeff for the responses. That was really useful.
>
> Jan - I have one follow-up question. When the data is spread over more
> than one
Thank you Jan & Jeff for the responses. That was really useful.
Jan - I have one follow-up question. When the data is spread over more than
one SSTable in case of updates as you mentioned, we will need two seeks per
SSTable (one for partition index and another for SSTable itself). I'm
curious to
On 2017-03-20 13:17 (-0700), preetika tyagi wrote:
> I'm trying to understand the maximum number of disk seeks required in a
> read operation in Cassandra. I looked at several online articles including
> this one:
>