我将实现一个通知系统，并且试图找出一种在数据库中存储通知的好方法。我有一个使用PostgreSQL数据库的Web应用程序，但是关系数据库对于这种用例似乎并不理想；我想支持各种类型的通知，每种通知都包含不同的数据，尽管数据的子集对于所有类型的通知都是通用的。因此，我认为NoSQL数据库可能比尝试规范化关系数据库中的模式更好，因为这非常棘手。
我的应用程序托管在Amazon Web Services（AWS）中，我一直在寻找DynamoDB来存储通知。这是因为它是托管的，因此我不必处理它的操作。理想情况下，我想使用MongoDB，但我真的更喜欢不必自己处理数据库的操作。我一直在努力想出一种在DynamoDB中完成我想做的事情的方法，但是我一直在努力，因此我有几个问题。
假设我要为每个通知存储以下数据：
一个ID
通知接收者的用户ID
通知类型
时间戳记
是否已阅读/看到
有关通知/事件的元数据（对此无需查询）
现在，我希望能够查询给定用户的最新X通知。另外，在另一个查询中，我想获取特定用户的未读通知的数量。我试图找出一种方法，可以索引我的表以有效地做到这一点。
我可以排除仅具有哈希主键的情况，因为我不会仅通过哈希键进行查找。我不知道“哈希和范围主键”在这里是否对我有帮助，因为我不知道将哪个属性作为范围键。我可以将唯一的通知ID作为哈希键，将用户ID作为范围键吗？这样可以让我仅通过范围键进行查找，即不提供哈希键吗？如果可能的话，也许二级索引可以帮助我按时间戳排序。
我还查看了全局二级索引，但是这些问题是，在查询索引时，DynamoDB仅可以返回投影到索引中的属性-由于我希望返回所有属性，因此我将不得不重复我的所有数据，这似乎很荒谬。
如何索引通知表以支持用例？可能吗，或者您还有其他建议吗？
最佳答案
注意：使用像DynamoDB这样的云存储时，我们必须了解存储模型，因为这将直接影响
您的性能，可伸缩性和财务成本。它是不同的
而不是使用本地数据库，因为您不仅要为
您存储的数据以及执行的操作
数据。例如，删除记录是WRITE操作，因此如果
您没有有效的清理计划（您的情况
时间序列数据特别需要一个），您将付出代价。你的
处理小数据量时，数据模型不会显示问题
但是在需要扩展时肯定会破坏您的计划。那是
说，决策就像创建（或不创建）索引，定义适当的
键的属性，创建表细分等
使整个过程变得与众不同。选择DynamoDB（或更多）
一般而言，键值存储）
权衡需要做出决定，您需要清楚地了解
有关可以使用该工具的存储模型的某些概念
有效地，选择正确的按键确实很重要，但只有
冰山一角。例如，如果您忽略了事实，
处理时间序列数据，无论使用什么主键或索引
您定义的情况下，您的预配置吞吐量将不会得到优化，因为
它分布在整个表（及其分区）中，而不是
仅是经常访问的数据，这意味着未使用的数据是
仅仅因为它是吞吐量的一部分而直接影响您的吞吐量
表。这导致以下情况：
ProvisionedThroughputExceededException在以下情况下“意外”抛出
您肯定知道预配置吞吐量应该足以满足您的需求
需求，但是，被不均匀访问的表分区
已达到其限制（更多详细信息here）。
下面的帖子提供了更多详细信息，但我想带给您一些阅读的动力，并理解，尽管您现在当然可以找到一个更简单的解决方案，但这可能意味着您在碰壁时从头开始（这种“隔离墙”可能是由于高昂的财务成本，性能和可伸缩性方面的限制或两者的结合而来。
问：我可以将唯一的通知ID作为哈希键，将用户ID作为范围键吗？这样可以让我仅通过范围键进行查找，即不提供哈希键吗？
答：DynamoDB是键值存储，这意味着最高效的查询会使用整个键（哈希或哈希范围）。仅由于您没有密钥而使用Scan操作实际执行查询绝对是您的数据模型中就您的需求而言不足的标志。有几件事情需要考虑，许多选择可以避免此问题（下面有更多详细信息）。
现在，在继续之前，我建议您阅读此快速文章，以清楚地理解哈希键和哈希+范围键之间的区别：
DynamoDB: When to use what PK type?
您的案例是典型的时序数据场景，随着时间的流逝，记录变得过时了。您需要注意两个主要因素：
确保您的表具有均匀的访问模式
如果将所有通知放在一个表中，并且更频繁地访问最近的通知，则配置的吞吐量将无法有效使用。
您应该将访问量最大的项目分组在一个表中，以便可以针对所需访问权限适当调整预配置的吞吐量。此外，请确保正确定义Hash Key that will allow even distribution of your data across multiple partitions。
以最有效的方式（努力，性能和成本合理）删除过时的数据
该文档建议将数据划分到不同的表中，以便一旦记录过时就可以删除或备份整个表（请参阅下面的更多详细信息）。
这是文档中介绍与时间序列数据相关的最佳做法的部分：
了解时间序列数据的访问模式
对于您创建的每个表，您指定吞吐量
要求。 DynamoDB分配和保留资源来处理您的
持续低延迟的吞吐量要求。设计时
您的应用程序和表，您应该考虑应用程序的
访问模式以最有效地利用表格的
资源。
假设您设计了一个表格来跟踪您网站上的客户行为，
例如他们点击的网址。您可以使用哈希和
具有客户ID作为哈希属性的范围类型主键，以及
日期/时间作为范围属性。在此应用程序中，客户数据
随着时间的推移无限增长；但是，应用程序可能会显示
表格中所有项目的访问方式不均匀
最新的客户数据更相关，您的应用程序可能
随着时间的流逝，更频繁地访问最新项目
访问较少，最终很少访问较旧的项目。如果
这是一种已知的访问模式，您可以考虑一下
设计表架构时。而不是将所有项目存储在
一个表，则可以使用多个表来存储这些项目。对于
例如，您可以创建表来存储每月或每周数据。对于
该表存储最近一个月或一周中的数据，其中数据
访问速率高，要求更高的吞吐量并用于表存储
较旧的数据，您可以降低吞吐量并节省资源。
您可以通过将“热门”项目存储在一个表中来节省资源
更高的吞吐量设置，并在另一个表中使用“冷”项
较低的吞吐量设置。您可以删除旧项目，只需删除
桌子。您可以选择将这些表备份到其他存储
诸如Amazon Simple Storage Service（Amazon S3）之类的选项。删除
整个表格比删除项目效率更高
一对一，这实际上使写入吞吐量加倍
与删除操作一样多的删除操作。
资源：
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns
例如，您可以按月对表进行细分：
Notifications_April, Notifications_May, etc
问：我希望能够查询给定用户的最新X通知。
答：我建议使用
Query操作并仅使用具有Hash Key的UserId（Range Key）进行查询，以按Timestamp（日期和时间）对通知进行排序。Hash Key: UserId
Range Key: Timestamp
注意：更好的解决方案是
Hash Key，使其不仅具有UserId，而且具有在查询之前可以计算以确保您的Hash Key甚至允许您访问数据的连接信息。例如，如果来自特定用户的通知比其他用户更受访问，则可以开始具有热分区...在Hash Key中包含其他信息可以减轻这种风险。问：我想获取特定用户的未读通知的数量。
答：创建
Global Secondary Index作为稀疏索引，以UserId作为Hash Key，以Unread作为Range Key。例：
Index Name: Notifications_April_Unread
Hash Key: UserId
Range Key : Unuread
当您通过哈希键（UserId）查询该索引时，您将自动拥有所有未读的通知，并且不会通过与该情况无关的通知进行不必要的扫描。请记住，表中原始的主键会自动投影到索引中，因此，如果您需要获取有关通知的更多信息，可以始终使用这些属性对原始属性执行
GetItem或BatchGetItem表。注意：您可以探索使用除“未读”标志以外的其他属性的想法，重要的是要记住，稀疏索引可以帮助您解决此用例（下面有更多详细信息）。
详细说明：
我将使用稀疏索引来确保您可以查询简化的数据集来进行计数。在您的情况下，您可以使用属性“未读”来标记是否已读取通知，并使用该属性来创建稀疏索引。当用户阅读通知时，您只需从通知中删除该属性，以使其不再显示在索引中。以下是文档中明确适用于您的方案的一些准则：
利用稀疏索引
对于表中的任何项目，DynamoDB只会写一个对应的
索引条目（如果索引范围键）
该项目中存在属性值。如果范围键属性
并不是在每个表项中都出现，因此索引被认为是稀疏的。
[...]
要跟踪未结订单，您可以在CustomerId（哈希）和
IsOpen（范围）。表中仅定义了IsOpen的那些订单
将出现在索引中。然后，您的应用程序可以快速
通过查询索引有效地找到仍未结的订单。
例如，如果您有数千个订单，但数量很少
打开的应用程序可以查询索引并返回
每个未结订单的OrderId。您的应用程序将执行
读取次数明显少于扫描整个扫描所需要的时间
CustomerOrders表。 [...]
无需将任意值写入IsOpen属性，您可以
可以使用不同的属性，这将导致有用的排序顺序
在索引中。为此，您可以创建一个OrderOpenDate属性
并将其设置为下订单的日期（并仍然删除
订单完成后的属性），然后创建OpenOrders
具有架构客户ID（哈希）和OrderOpenDate（范围）的索引。
这样，当您查询索引时，项目将以
更有用的排序顺序。[...]
这样的查询可能非常有效，因为
索引将大大少于
表。此外，您投影到
索引，您将从索引消耗的读取容量单位越少。
资源：
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForGSI.html#GuidelinesForGSI.SparseIndexes
在下面找到一些以编程方式创建和删除表所需的操作参考：
建立表格
http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html
删除表格
http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteTable.html
关于amazon-web-services - DynamoDB中的索引通知表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29951270/