> We stop at the memtable if we know that’s all we need. This depends on a lot
> of factors (schema, point read vs slice, etc)
The codes seems to search sstables without checking whether the query
is already satisfied in memtable only.
Could you point out the related code snippets for what you
You’re comparing single machine key/value stores to a distributed db with a
much richer data model (partitions/slices, statics, range reads, range
deletions, etc). They’re going to read very differently. Instead of explaining
why they’re not like rocks/ldb, how about you tell us what you’re
Thanks. Let me clarify my questions more.
1) For memtable, if the selected columns (assuming they are in simple
types) could be found in memtable only, why bother to search sstables
then? In leveldb and rocksdb, they would stop consulting sstables if
the memtable already fulfill the query.
2)
First:
Compaction controls how sstables are combined but not how they’re read. The
read path (with one tiny exception) doesn’t know or care which compaction
strategy you’re using.
A few more notes inline.
> On Jan 8, 2019, at 3:04 AM, Jinhua Luo wrote:
>
> Hi All,
>
> The compaction
Hi All,
The compaction would organize the sstables, e.g. with LCS, the
sstables would be categorized into levels, and the read path should
read sstables level by level until the read is fulfilled, correct?
For STCS, it would search sstables in buckets from smallest to largest?
What about other
