我们正在设计的应用程序具有一项功能，用户可以在其中向实体动态添加新元素，然后需要对其进行有效搜索。这些元素的数量实际上是无限的。我们的团队一直在将DynamoDB作为数据存储选项，我们一直在努力研究键/值模型以及如何在索引下获取此动态数据以进行有效查询。
我认为我有一个单表解决方案，可以优雅地处理该问题，并且还允许查询数据存储中的any给定属性，但是我在其他任何地方都找不到该示例，这让我感到不安。希望它在某种程度上没有根本缺陷-我将不胜感激！
该模型本质上是用于向RDBM添加动态或稀疏数据的Entity-Attribute-Value方法。因此，不要像这样在DynamoDB表中存储不同的实体/对象：
PK SK SK-1 SK-2 SK-3 SK-N... PK SK SK-1 SK-N...
Key Key Key Key --> Name Money
Entity Id Value Value Value Value Person 22 Fred 30000
...这使我可以查询“ name = Fred的所有人”之类的信息，但最终您将用尽所有排序键索引，并且在查询之前您需要知道哪个索引与哪个键一起使用，数据可能是以EAV格式存储，如下所示：
PK SK & GSI-PK GSI-SK PK SK & GSI-PK GSI-SK
Id Entity.Key Value 22 Person#Name Fred
Id Entity.Key Value --> 22 Person#Money 30000
Id Entity.Key Value 22 Person#Sex M
Id Entity.Key Value 22 Person#DOB 09/00
现在，有了一个全局二级索引（Entity.Key上方的GSI-1 PK和Value上方的GSI-1 SK），我可以对任何键的任何值进行范围搜索，并获取匹配的ID列表。用户可以添加其属性，甚至可以添加全新的实体，并使它们以可以立即建立索引的方式持久化，而无需我们修改DynamoDB模式。
我可以想到的这种方法的主要缺点是，从Entity＃Key-Value的查询返回的数据仅包含该键和实体ID的值，而不包含整个实体。这对于图表和图形很好，但是如果您想通过一个查询获得网格类型的结果，那就是一个问题。我也担心索引上的热分区键，但是希望我们可以通过智能写入分片解决该问题。
差不多。通过一些调整，该模型可以扩展为支持记录每个键上的所有更改，并允许对这些更改进行一些不错的时间序列查询，但是我的问题是，是否有人发现将EAV类型的方法用于KV商店很有用例如DynamoDB，或者是否还有另一种方式来处理动态模式查询？
您可以将pk作为实体的id。然后是{attributeName}的排序键。您可能仍希望具有包含诸如createdAt等字段的基础实体。
所以您可能会有：
PK SORT Attributes:
#Entity#22 #Entity#Details createdAt=2020
#Entity#22 #Attribute#name key=name value=Fred
#Entity#22 #Attribute#money key=money value=30000
要获取实体的所有属性，您只需执行一个没有pk={id}过滤器的查询。您不能根据每个给定的属性动态地进行排序，这正是DynamoDB所不擅长的，我重复一遍！这种情况正是NOSQL表现不佳的原因。
您可以使用流式传输进行聚合。因此，例如，您可以存储前10名最富有的人：
PK SORT Attributes:
#Money#Highest #1 id=#Entity#22 value=30000
#Money#Highest #2 id=#Entity#52 value=30000
您将在DynamoDB流中进行计算。但是您无法动态索引值，DynamoDB的工作原理是将数据从一种形式有效地复制到另一种形式，以便可以有效地检索它。因此，您将为每个要搜索的新属性复制整个数据库，否则将不得不使用“扫描”，这将毫无意义，因为如果您做过所有事情，那么使用DynamoDB将无济于事一直在进行扫描。
您的过程需要很好地理解才能充分利用DynamoDb，如果您想随意索引数据，并执行各种不同的查询，则可能需要SQL数据库或elasticsearch。