Data modeling 活动提要/新闻提要/时间表的hbase数据建模

我决定在一个项目中使用HBase将用户活动存储在社交网络中。尽管HBase有一种表示数据的简单方法（面向列），但在决定如何表示数据时，我仍面临一些困难

因此，假设您有数百万用户，每个用户都在生成一个活动，例如，在一个线程中发表评论，发布一些东西，如投票等。我认为基本上有两种方法可以使用活动hbase表：

键可以是用户引用+活动创建的时间戳，所有活动元数据的值（大部分时间固定大小）

键是用户引用，然后每个活动将作为列族中的一个新列存储

我看到了使用第二种方法的其他类型系统（如博客）的示例。第一种方法（使用固定列，仅在更改模式时才改变）更常见

---

对于这两种方法，我访问数据的方式会有什么影响？

通常，您会问您的表应该宽还是长。在某种程度上，HBase可以同时使用这两种方法。宽表中的行不应超过区域大小（默认为256MB）——因此，如果您为用户的操作存储了大量数据，那么真正多产的用户可能会导致系统崩溃。但是，如果每个操作只存储几个字节，那么将所有用户活动放在一行将允许您通过一个get获取它们的完整历史记录。但是，您将检索整行，这可能会导致很多历史记录的速度减慢（大于100MB的行为10秒）

使用一个高表和一个反向时间戳将允许您非常快速地获取用户最近的活动（使用key=user id开始扫描）

如果希望按时间查询，则使用时间戳作为键的结尾是一个好主意，但如果希望优化对数据库的写入（写入将始终位于系统中最新的区域，从而导致热点），则使用时间戳是一个坏主意

您可能还想考虑在密钥中添加更多信息（如活动），以便更容易地获取特定类型的所有活动。

---

另一个要看的例子是OpenTSDB

经过一些搜索，我找到了meetup的案例，其中包括一些关于如何为活动建模的材料，我还找到了HBase书籍中的一章，该章节将由Oreilly发布，该章节对数据建模策略进行了评论，有趣的是，宽表永远不应超过区域大小。我认为我会更好地考虑行键，以避免写入问题。谢谢