-
Notifications
You must be signed in to change notification settings - Fork 83
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
RFC 510: DynamoDB Global Table L2 #511
Conversation
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
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 like it! There are three big things left in my mind:
- I think a GSI probably shouldn't have a default capacity, we should make the user specify it? At least the default for a replica's GSI capacity should be the base GSI, not the replica table.
- I'd like one final thought to be spent on using enums vs enum-like classes for billing mode (and articulated why you prefer one over the other). I can also see why you might not want to.
- I'd like an example for encryption, it's not clear to me now whether it's a central property or a per-replica property
text/0510-dynamodb-global-table.md
Outdated
replicas: [{ | ||
region: 'us-east-1', | ||
read: Capacity.autoscaled({ max: 70 }), | ||
globalSecondaryIndexOptions: [ |
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.
Is this necessary to "turn on" the GSI for the replica? Or are all GSIs automatically turned on, and this is only necessary to tweak settings?
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.
Was there a conscious decision between a list and a map?
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.
This is not required to turn on the GSIs. They would be enabled for each replica.
This is just to specify some settings for GSIs that are configurable per replica.
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.
Was there a conscious decision between a list and a map?
Yes, I was just trying to keep it similar to how GSIs were defined. We can also have it like,
{
'UniqueGsiName': {
read: Capacity.fixed(55),
contributorInsightsEnabled: false,
}
}
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.
read
and contributorInsightsEnabled
are the only two props that can be configured for the GSI per replica.
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.
{
'UniqueGsiName': {
read: Capacity.fixed(55),
contributorInsightsEnabled: false,
}
}
I kind of enjoy the above. Feels like less ceremony to me. No?
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.
Hey, I have just updated the Replica GSI options
from list to map. I can see this can also be done for GSI, Replica and LSI
. Let me know if that is what you would prefer. :)
For me, it makes sense to have them as list since it conveys intent like, list of global secondary indexes
, or list of replicas
, but I am fine either way.
* You need a sort key to define a local secondary index. | ||
* You can create up to five local secondary indexes. | ||
|
||
#### Encryption |
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.
This needs an example.
Also above in the RFC you said that kmsKeyArn
was a per-replica property, but if the encryption setting is global that might be confusing.
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.
Will add an example.
The keyArns
only need to be provided if the encryption mode is KEY_ARNS
. The encryption mode will remain the same for all replicas but the keys would be specific to the replica.
I can instead add a table level property to add [ { region: keyArn} ]
but I believe it make more sense to have this in replica props.
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.
Again this could be an enum-like class: `
encryption: TableEncryption.regionKeyArns({
'us-east-1': 'arn:kms:...',
'us-east-2': 'arn:kms:...',
});
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.
Taking into account that the table itself also needs a key, and that should probably be an IKey
for single-region consistency:
encryption: TableEncryption.customerManagedKey(tableKey, {
replicaKeyArns: {
'us-east-1': 'arn:kms:...',
'us-east-2': 'arn:kms:...',
}
});
Perhaps?
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
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.
Almost there! A couple of final details to think about, but they're very minor. I like this, after you consider the last couple of points I think this is good to merge.
text/0510-dynamodb-global-table.md
Outdated
name: 'FooHashKey', | ||
type: AttributeType.STRING, | ||
}, | ||
encryption: GlobalTableEncryption.KEY_ARNS, |
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.
Don't forget the keyARN for the table itself. Which probably shouldn't be an ARN but an IKey
.
* You need a sort key to define a local secondary index. | ||
* You can create up to five local secondary indexes. | ||
|
||
#### Encryption |
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.
Taking into account that the table itself also needs a key, and that should probably be an IKey
for single-region consistency:
encryption: TableEncryption.customerManagedKey(tableKey, {
replicaKeyArns: {
'us-east-1': 'arn:kms:...',
'us-east-2': 'arn:kms:...',
}
});
Perhaps?
text/0510-dynamodb-global-table.md
Outdated
replicas: [ | ||
{ | ||
region: 'us-west-2', | ||
encryptionKey: 'FooKmsKeyArn', |
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.
Encryption is not really relevant for this example, so if you remove it the example will be shorter and easier to read.
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.
Will update this.
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
Signed-off-by: Vinayak Kukreja <vinakuk@amazon.com>
This is a request for comments about DynamoDB GlobalTable L2 construct. See #510 for additional details.
APIs are signed off by @rix0rrr and @madeline-k .
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license