diff options
Diffstat (limited to 'doc/architecture/blueprints/database/scalability/patterns')
3 files changed, 5 insertions, 5 deletions
diff --git a/doc/architecture/blueprints/database/scalability/patterns/index.md b/doc/architecture/blueprints/database/scalability/patterns/index.md index 4a9bb003763..ec00d757377 100644 --- a/doc/architecture/blueprints/database/scalability/patterns/index.md +++ b/doc/architecture/blueprints/database/scalability/patterns/index.md @@ -1,7 +1,7 @@ --- stage: Data Stores group: Database -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments comments: false description: 'Learn how to scale the database through the use of best-of-class database scalability patterns' --- diff --git a/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md b/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md index 0780ae3c4d5..6cf8e17edeb 100644 --- a/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md +++ b/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md @@ -1,7 +1,7 @@ --- stage: Data Stores group: Database -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments comments: false description: 'Learn how to scale operating on read-mostly data at scale' --- diff --git a/doc/architecture/blueprints/database/scalability/patterns/time_decay.md b/doc/architecture/blueprints/database/scalability/patterns/time_decay.md index 7a64f0cb7c6..ff5f7c25ea1 100644 --- a/doc/architecture/blueprints/database/scalability/patterns/time_decay.md +++ b/doc/architecture/blueprints/database/scalability/patterns/time_decay.md @@ -1,7 +1,7 @@ --- stage: Data Stores group: Database -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments comments: false description: 'Learn how to operate on large time-decay data' --- @@ -27,7 +27,7 @@ application. Let's first consider entities with no inherent time-related bias for their data. A record for a user or a project may be equally important and frequently accessed, irrelevant to when -it was created. We can not predict by using a user's `id` or `created_at` how often the related +it was created. We cannot predict by using a user's `id` or `created_at` how often the related record is accessed or updated. On the other hand, a good example for datasets with extreme time-decay effects are logs and time @@ -91,7 +91,7 @@ a maximum of a month of events, restricted to 6 months in the past. ### Immutability The third characteristic of time-decay data is that their **time-decay status does not change**. -Once they are considered "old", they can not switch back to "new" or relevant again. +Once they are considered "old", they cannot switch back to "new" or relevant again. This definition may sound trivial, but we have to be able to make operations over "old" data **more** expensive (for example, by archiving or moving them to less expensive storage) without having to worry about |