Skip to content
This repository has been archived by the owner on Aug 23, 2023. It is now read-only.

Add partitioned index #1232

Merged
merged 10 commits into from
Mar 8, 2019
Merged

Add partitioned index #1232

merged 10 commits into from
Mar 8, 2019

Conversation

woodsaj
Copy link
Member

@woodsaj woodsaj commented Mar 7, 2019

Add a PartitionedIndex wrapper around the memoryIdx.
Partitioning the index can be toggled via a config flag. By default it is off.

@shanson7
Copy link
Collaborator

shanson7 commented Mar 7, 2019

Looks interesting. Is the goal of this component to reduce lock contention? Can you share any benchmarks run?

Copy link
Contributor

@robert-milan robert-milan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@replay
Copy link
Contributor

replay commented Mar 7, 2019

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 defById map smaller and it seems like it should be easy to now just make the key something like (orgId * 128) + partition assuming the max number of partitions is 128.

result := make([][]idx.Archive, len(p.Partition))
var i int
for _, m := range p.Partition {
pos, m := i, m
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above^^

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above

@woodsaj
Copy link
Member Author

woodsaj commented Mar 7, 2019

thanks for the review @replay
I think this should be good to merge. The change is pretty safe given that by default the unpartitionedIdx will be used.

relevant benchmark

goos: linux
goarch: amd64
pkg: github.com/grafana/metrictank/idx/memory
BenchmarkConcurrentInsertFind/partitioned-8                  10000            363256 ns/op          524709 B/op      11788 allocs/op
BenchmarkConcurrentInsertFind/unPartitioned-8               3000            333891 ns/op          484942 B/op      10115 allocs/op
PASS
ok      github.com/grafana/metrictank/idx/memory        12.061s

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
@replay
Copy link
Contributor

replay commented Mar 8, 2019

@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:

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 defById map smaller and it seems like it should be easy to now just make the key something like (orgId * 128) + partition assuming the max number of partitions is 128.

Instead of keeping it a single map of index partitions we could also add a second level like Partition[orgId][partitionId]*UnpartitionedMemoryIdx instead of Partition[partitionId]*UnpartitionedMemoryIdx

@woodsaj
Copy link
Member Author

woodsaj commented Mar 8, 2019

because i feel like this could help a lot for multi tenant setups with many tenants:

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

Copy link
Contributor

@replay replay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@woodsaj woodsaj merged commit 20f6fde into master Mar 8, 2019
@woodsaj woodsaj deleted the partitionedIdx branch March 8, 2019 14:19
@Dieterbe
Copy link
Contributor

@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)
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants