Currently, all components that read from object store assume that all the operations and functionality should be done based on all the available blocks that are present in the certain bucket’s root directory.
This is in most cases totally fine, however with time and allowance of storing blocks from multiple
Sources into the same bucket, the number of objects in a bucket can grow drastically.
This means that with time you might want to scale out certain components e.g:
Larger number of objects does not matter much, however compactor has to scale (CPU, network, disk, memory) with number of Sources pushing blocks to the object storage.
Queries against store gateway which are touching large number of blocks (no matter from what Sources) might be expensive, so it can scale with number of blocks.
Now, thanos only support following relabel actions:
external labels for all components
__block_id for store gateway, see this example
The relabel config defines filtering process done on every synchronization with object storage.
We will allow potentially manipulating with several of inputs:
By default, on empty relabel-config, all external labels are assumed.
Example usages would be:
- action: drop
- action: keep
We can shard by adjusting which labels should be included in the blocks.
For store gateway, we can specify
--max-time flags to filter for what blocks store gateway should be responsible for.
More details can refer to “Time based partitioning” chapter in Store gateway.