Channel Index Storage

###Channel Index Storage

The following document types are used to store channel index information in the index bucket.

Most of these are stored as binary to optimize read/write and storage space, so unfortunately it's not possible to inspect their contents through the Couchbase Admin Console directly. However, it's still useful when debugging to know what is stored where:

Doc Type	Doc Name	Description
Stable Sequence	_idx_stableSeq	Stable sequence clock - the channel index is guaranteed to be complete up to this value
Partition Map	_idxPartitionMap	Partition map. Stored the mapping of vbuckets to index partitions. Initialized based on the CBGT partition map when not found in the bucket.
Channel Clock	_idx_SequenceClock:[channelName]	Channel clock - tracks the highest sequences seen for the channel
Channel Block	_idx:[channelName]:[partition]:block[blockNo]	Channel block. Binary encoding of a map of vbucket number to byte array. For each vbucket assigned to the partition, stores a byte array for sequence presence. Block 0 stores sequences 1-10000, block 1 10001-20000, etc. (block size is a parameter in the code, but not a configurable setting). Only provides sequence and removal flag information - docID and revID need to be retrieved from the Index Entry
Index Entry	_idx_entry:[vbNo]:[seqNo]	Stores the information needed to serve a changes request for document with vbucket vbNo, sequence seqNo.

##Notes on Channel Index Storage

The design of the channel storage is an attempt to balance write optimization with read optimization. It should be straightforward to tweak the current design if needed based on performance results. Areas for particular attention:

1. The channel and stable sequence clocks aren't currently being sharded - they are stored as a single value. This is optimized for the read side - readers only need to do a single GET to identify whether a channel has changed. However, this results in contention when multiple writers are trying to update the same clock. However, because of the batch nature of the index writers, writers will only be attempting to update these clocks at most once per batch. Based on this, I'm optimistic that the contention doesn't introduce significant write latency. However, it's an area for focused evaluation, and potentially a change to sharded clocks.

2. The channel block storage has optimizations for both readers and writers. Writers are only storing the full sequence information (doc id, rev id, etc.) once (instead of onces per channe). On the read side - based on the difference between their since value and the channel clock, readers know exactly which blocks they need to load in order to retrieve changes. However, for sparse channels, this model results in more storage used than a simple append-based list of sequences. Based on the benchmarks and analysis thus far, the byte array model provides the best balance of read and write performance, but needs to be testing in a wider range of channel density patterns, with higher volumes of data.