-
Notifications
You must be signed in to change notification settings - Fork 107
Conversation
Looks interesting. Is the goal of this component to reduce lock contention? Can you share any benchmarks run? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
if we already partition by partition id, should we also partition by org id? in the case of multi tenant setups this would keep the |
result := make([][]idx.Archive, len(p.Partition)) | ||
var i int | ||
for _, m := range p.Partition { | ||
pos, m := i, m |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as above
thanks for the review @replay relevant benchmark
For most benchmarks the the PartitionedMemoryIdx performs worse than the unpartitioned version. This is all due to the results from searching all partitions needing to be merged, which results in lots of allocations. The next step is to continue exposing "partitions" throughout the code base. The end goal is to have all partitions handled independently and allow peers to query specific partitions. This will allow nodes to respond with data for some partitions while others are blocked. The speculative execution can then try alternate peers for partitions that are slow. |
- add config flag to enable partitionedIndex - update cassandra and bigtable indexes to use MemoryIndex interface - update all unit tests to run against both MemoryIdx and PartitionedMemoryIdx
this is just to make response responses consistent between MemoryIdx and PartitionedMemoryIdx
@woodsaj sounds good. I'd just like to ask first what you think about my above suggestion, because i feel like this could help a lot for multi tenant setups with many tenants:
Instead of keeping it a single map of index partitions we could also add a second level like |
it could, but the majority of MT clusters are single tenant. It might still make sense to do, but it is not something that should be included in this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@woodsaj at this point, would you recommend enabling the partitioning ? in which circumstances? |
var defs []schema.MetricDefinition | ||
var num int | ||
for _, partition := range cluster.Manager.GetPartitions() { | ||
defs = c.LoadPartitions([]int32{partition}, defs[:0], pre) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@woodsaj isn't this a bug? subsequent calls of this seem to overwrite previously loaded defs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no.
Add a PartitionedIndex wrapper around the memoryIdx.
Partitioning the index can be toggled via a config flag. By default it is off.