-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
region_sharding: working resharding example #6565
Conversation
491ef62
to
3862d1c
Compare
"customer_region_lookup": { | ||
"type": "consistent_lookup_unique", | ||
"params": { | ||
"table": "main.customer_lookup", |
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.
In the original example on https://vitess.io/docs/user-guides/region-sharding/ , we also had to define the primary vindex on the lookup table:
"customer_lookup": {
"column_vindexes": [
{
"column": "keyspace_id",
"name": "identity"
}
]
},
My suggestion on Slack was that we needed to change that to a primary vindex on id
instead.
Is that missing from this example? Or are you making the lookup table unsharded? At the moment I don't see any column_vindexes
defined for customer_lookup
.
Is there another PR with the changes to the tutorial document https://vitess.io/docs/user-guides/region-sharding/ ?
I'm curious to see a discussion in the tutorial on the sharding strategy for the lookup table.
- If we shard by
id
(which makes the most sense from a functionality point-of-view; otherwise the lookup table is useless), or if we make the table unsharded, then we might still have to go cross-region for the lookups, which will add latency. - Unless we cross-replicate every shard into every region, but then there are questions about replication lag consistency when using the lookup table.
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.
I'm using the new workflows that weren't available when we first built the example. CreateLookupVindex
also creates a primary vindex on the lookup table.
This is what the vschema looks like after the lookup vindex is created.
$ vtctlclient GetVSchema main
{
"sharded": true,
"vindexes": {
"customer_region_lookup": {
"type": "consistent_lookup_unique",
"params": {
"from": "id",
"table": "main.customer_lookup",
"to": "keyspace_id"
},
"owner": "customer"
},
"hash": {
"type": "hash"
},
"region_vdx": {
"type": "region_json",
"params": {
"region_bytes": "1",
"region_map": "/path/to/file/countries.json"
}
}
},
"tables": {
"customer": {
"columnVindexes": [
{
"name": "region_vdx",
"columns": [
"id",
"country"
]
},
{
"column": "id",
"name": "customer_region_lookup"
}
]
},
"customer_lookup": {
"columnVindexes": [
{
"column": "id",
"name": "hash"
}
]
}
}
}
I'm still working on rewriting the user guide, PR should be ready shortly.
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.
Do you think it is helpful for CreateLookupVindex
to return the created vschema? Otherwise it is silent and not obvious.
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.
I haven't run vitess yet or gotten familiar with the vtctlclient
commands, so I'm not in a good position to say. But I'll agree that it is not obvious, and finding ways to make it more obvious would probably be very helpful.
3862d1c
to
e2fd0f9
Compare
Signed-off-by: deepthi <deepthi@planetscale.com>
e2fd0f9
to
1653579
Compare
Signed-off-by: deepthi <deepthi@planetscale.com>
This modifies the region_sharding example to demonstrate region_json based resharding.
Note: DO NOT MERGE, I'm updating the user guide on the website vitessio/website#488, and would like to merge both at the same time.
Signed-off-by: deepthi deepthi@planetscale.com