> One additionnal question, I don't really understand what is in the key
> cache. I have a column family with only one key, and the keycache size
> is 118 ... ?
The key cache is basically a hash table mapping row keys to sstable
offsets. It avoids the need to read from the index portion of the
sst
One additionnal question, I don't really understand what is in the key
cache. I have a column family with only one key, and the keycache size
is 118 ... ?
Any idea.
Thks.
Jean-Yves
On Mon, Mar 14, 2011 at 1:19 PM, Peter Schuller
wrote:
>> How is it possible calculate this value? I think that key size, if we use
>> RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
>> elements) bytes ??
>
> The easiest way right now is probably empirical testing. The is
Sometime back I looked at the code to find that out. Following is the
result. There will be some additional overhead for internal DS for
ConcurrentLinkedHashMap.
* (<8 bytes for position i.e. value> + +
<16 bytes for token (RP)> + <8 byte reference for DecoratedKey> + <8 bytes
for descriptor ref
> How is it possible calculate this value? I think that key size, if we use
> RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
> elements) bytes ??
The easiest way right now is probably empirical testing. The issue is
that the "memory use" must include overhead associated
Hello
How is it possible calculate this value? I think that key size, if we use
RandomPartitioner will 16 bytes so keycache will took 16*(num of keycache
elements) bytes ??
