此问题可能与任何基于NoSQL数据库的文档相关。
我正在制作一些特定兴趣的社交网络,并决定使用DynamoDB,因为它具有可扩展性和无痛苦管理因素。数据库中只有两个主要实体:用户和帖子。
常见查询的要求非常简单:
这是我到目前为止提出的数据库方案(图例:__thisIsHashKey
和_thisIsRangeKey
):
timeline = { // post
__usarname:"totocaster",
_date:"1245678901345",
record_type:"collection",
items: ["2d931510-d99f-494a-8c67-87feb05e1594","2d931510-d99f-494a-8c67-87feb05e1594","2d931510-d99f-494a-8c67-87feb05e1594","2d931510-d99f-494a-8c67-87feb05e1594","2d931510-d99f-494a-8c67-87feb05e1594"],
number_of_likes:123,
description:"Hello, this is cool"
}
timeline = { // new follower
__usarname:"totocaster",
_date:"1245678901345",
type:"follow",
follower:"tamuna123"
}
timeline = { // new like
__usarname:"totocaster",
_date:"1245678901345",
record_type:"like",
liker:"tamuna123",
like_date:"123255634567456"
}
users = {
__username:"totocaster",
avatar_url:"2d931510-d99f-494a-8c67-87feb05e1594",
followers:["don_gio","tamuna123","barbie","mikecsharp","bassman"],
following:["tamuna123","barbie","mikecsharp"],
likes:[
{
username:'barbie',
date:"123255634567456"
},
{
username:"mikecsharp",
date:"123255634567456"
}],
full_name:"Toto Tvalavadze",
password:"Hashed Key",
email:"totocaster@myemailprovider.com"
}
正如您所看到的那样,我将所有帖子直接存储在时间线集合中。这样我就可以使用日期和用户名(哈希和范围键)查询帖子。一切似乎都很好,但这是问题:
我无法一次性查询用户时间线。这将是系统最需要的查询之一,我无法提供有效的方法来执行此操作。请帮忙。感谢。
答案 0 :(得分:1)
我会查看Titan图数据库(http://thinkaurelius.github.com/titan/)和Neo4j(http://www.neo4j.org/)。
我知道Titan声称可以很好地扩展数据集。
最终,我认为您的模型很好地映射到图表。用户和帖子将是节点,然后您可以通过边缘任意连接它们。用户(节点)是另一个用户(节点)的朋友(边缘)。
用户(节点)在其时间轴中有许多帖子(节点)。然后你可以通过图表运行有趣的遍历。
答案 1 :(得分:0)
我碰巧每天都在处理新闻。 (Stream-Framework的作者并创立了getstream.io)
我看到的最常见的解决方案是:
大多数人在阅读时使用扇出或写入扇出。这使得构建工作解决方案变得更加容易,但它可能会很快变得昂贵。最好的办法是结合使用这两种方法。因此,在大多数情况下,写一个扇出,但对于非常受欢迎的源,它们会留在内存中。
Stream-Framework是开源的,支持Cassandra / Redis&蟒
getstream.io是一个托管解决方案,构建于Go& amp;之上。 Rocksdb。
如果您最终使用DynamoDB,请确保设置正确的分区键: https://shinesolutions.com/2016/06/27/a-deep-dive-into-dynamodb-partitions/
另请注意,基于Redis或DynamoDB的解决方案会很快变得昂贵。通过利用Cassandra或RocksDB,您将获得每位用户的最低成本。
答案 2 :(得分:0)
您还可以使用非常适合社交网络的Amazon Neptune(https://aws.amazon.com/neptune/)(Graph DB)。对于您的用例,我认为DynomoDB并不是一个不错的选择。