Some background on the read and write paths, some of the extra details are a
little out of date but mostly correct in 1.2
http://www.slideshare.net/aaronmorton/cassandra-community-webinar-introduction-to-apache-cassandra-12-20353118/40
http://thelastpickle.com/2011/04/28/Forces-of-Write-and-Read/
I'm not sure how accurate it is (it's from 2011, one of its sources is
from 2010), but I'm pretty sure it's more or less OK:
http://blog.csdn.net/firecoder/article/details/7019435
M.
W dniu 07.08.2013 10:34, Nikolay Mihaylov pisze:
thanks
It will use the Index Sample (RAM) first, then it wil
thanks
It will use the Index Sample (RAM) first, then it will use "full" Index
(disk) and finally it will read data from SSTable (disk). There's no such
thing like "collision" in this case.
so it still have 2 seeks :)
where I can see the internal structure of the sstable i tried to find it
docum
2. when cassandra lookups a key in sstable (assuming bloom-filter and other
"stuff" failed, also assuming the key is located in this single sstable),
cassandra DO NOT USE sequential I/O. "She" probably will read the
hash-table slot or similar structure, then cassandra will do another disk
seek i
Hi
I am researching various hash-tables and b-trees on disk.
while I researched, I has a thoughts about cassandra sstables that I want
to verify it here.
1. cassandra sstable uses sequential disk I/O when created. e.g. disk head
write it from the beginning to the end. Assuming the disk is not
fr
