我有大约20亿的事件。一个事件包括：一个密钥（ssn）、一个日期和有关事件的信息。我有5种类型的活动。
阅读模式：我需要从一个键中获取少于特定日期的所有事件。
写模式：每天只需一次批量加载。
想象一下数据库：
SSN;date(yyyymmdd);info
1;20140101;A
1;20140105;B
2;20140106;A
1;20140103;C因此，如果我的查询是：（ssn=“1”and date=“20140104”），我需要得到：
1;20140101;A
1;20140103;C我的第一种方法是：
行键=ssn+日期。
一个具有许多列来存储信息的族(info:cep, info:name, ...)
有人看到这种方法的性能问题吗？虽然，我的密钥是用日期组成的，但我不认为它会导致“单调递增的值”，因为我首先有一个ssn。
2条答案
按热度按时间bttbmeg01#
考虑到所需的读/写模式，设计是很好的。opentsdb实际上使用了一个类似的模式来存储timeseries数据（用于重实时度量、传感器数据等…）
您确实有单调递增的键（给定ssn），但这并不重要，原因有两个：
密钥的主要部分是ssn，其基数（~450mm）远大于节点/区域服务器的数量。
最重要的是，你每天只写一次！根据您的数据分布和写入模式，单调递增的键可能会导致热插拔。进行大容量加载意味着创建一个预拆分的表，生成“脱机”的hfiles，并在不经过hbase写入管道（wal、memstore、次要/主要压缩）的情况下一次加载它们。写入时间热点无法发生。
一个小建议：
使用单字符列族名称：info->d（如“data”中）
7nbnzgx92#
这是一个完美的设计。对于读取扫描，您将使用startkey=sss+0和endkey=ssn+date。您需要为用户标识符字段（ssn-9）分配固定数量的符号。行键按字典顺序排序。20 bln/420总ssn流通=47事件每个ssn，假设均匀分布。这并不多，但我会考虑索引大小和所需的任何优化。
事件是时间序列。您可能会对以下摘要感兴趣。它有3个用例：https://cloud.google.com/bigtable/pdf/cloudbigtabletimeseries.pdf