amazon-web-services - NoSQL 鼓励基于访问模式设计数据库。当模式发生变化时该怎么办？

Question

NoSQL 鼓励基于访问模式设计数据库，它可以非常快速地执行那些设计用于的查询。对于其他查询，性能不是那么好。但对于软件来说，变化是常态。那么当新的需求来了，我们又要添加新的特性时，nosql数据库该如何适应呢？或者更好的是，我如何设计 nosql 数据库（最好是 dynamodb），让我能够适应新功能的添加。

我想到的第一个方法是设计一个新表并将所有以前的数据迁移到新表中。但是考虑到该表有数百万条记录，它可能不是很划算

参考：

Rick Houlihan 谈基于访问模式设计 dynamodb 表

aws 文档中的 Dynamodb 设计最佳实践

标签： amazon-web-servicesdatabase-designnosqlamazon-dynamodb

Answer 1

为了适应新的变化而最小化全表迁移的一种方法是使用索引的通用名称。对于 dynamodb，我们将 pk 作为 partition_key，将 sk 作为 sort_key 以及项目的所有属性。pk 和 sk 的值实际上是从其他属性派生的值。更重要的是，我们会在建表过程中添加 5 个 LSI，并在必要时使用它们。例如，要存储有关一本书的数据，表中的一行将具有以下字段： pk, sk, ISBN, data_type, author, created_at, ...other data, lsi1, lsi2, lsi3, lsi4, lsi5

字段的值： pk->ISBN, sk->data_type, ISBN->ISBN, ...., lsi1->data_type#created_at , lsi(2-5)->empty

这样，除非需求发生剧烈变化，否则我们表的表结构不太可能发生变化。这里需要注意的一点是，除非添加、删除或更新的项目包含属于索引的属性，否则 dynamodb 不会产生计算或存储成本。