diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-03-18 23:02:30 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-03-18 23:02:30 +0300 |
commit | 41fe97390ceddf945f3d967b8fdb3de4c66b7dea (patch) | |
tree | 9c8d89a8624828992f06d892cd2f43818ff5dcc8 /doc/development/database_review.md | |
parent | 0804d2dc31052fb45a1efecedc8e06ce9bc32862 (diff) |
Add latest changes from gitlab-org/gitlab@14-9-stable-eev14.9.0-rc42
Diffstat (limited to 'doc/development/database_review.md')
-rw-r--r-- | doc/development/database_review.md | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/doc/development/database_review.md b/doc/development/database_review.md index 8e217725a17..4b5845992b9 100644 --- a/doc/development/database_review.md +++ b/doc/development/database_review.md @@ -203,6 +203,12 @@ Include in the MR description: - Order columns based on the [Ordering Table Columns](ordering_table_columns.md) guidelines. - Add foreign keys to any columns pointing to data in other tables, including [an index](migration_style_guide.md#adding-foreign-key-constraints). - Add indexes for fields that are used in statements such as `WHERE`, `ORDER BY`, `GROUP BY`, and `JOIN`s. +- New tables and columns are not necessarily risky, but over time some access patterns are inherently + difficult to scale. To identify these risky patterns in advance, we need to document expectations for + access and size. Include in the MR description answers to these questions: + - What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on? + - How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year? Under what circumstances are rows updated? What assumptions are these based on? + - Based on the anticipated data volume and access patterns, does the new table pose an availability risk to GitLab.com or self-managed instances? Will the proposed design scale to support the needs of GitLab.com and self-managed customers? #### Preparation when removing columns, tables, indexes, or other structures @@ -245,6 +251,10 @@ Include in the MR description: that post migrations are executed post-deployment in production. - Check [timing guidelines for migrations](migration_style_guide.md#how-long-a-migration-should-take) - Check migrations are reversible and implement a `#down` method +- Check new table migrations: + - Are the stated access patterns and volume reasonable? Do the assumptions they're based on seem sound? Do these patterns pose risks to stability? + - Are the columns [ordered to conserve space](ordering_table_columns.md)? + - Are there foreign keys for references to other tables? - Check data migrations: - Establish a time estimate for execution on GitLab.com. - Depending on timing, data migrations can be placed on regular, post-deploy, or background migrations. |