在我们的系统中存在用户可以查看和“关闭”报告的情况。在他们关闭它后，报告被移动到数据库内的一个临时表中，并保存 24 小时，然后移动到存档表（报告存储未来 7 年）。在这 7 年的任何时候，用户都可以“重新打开”报表并对其进行处理。问题是档案存储越来越大，查找/重新打开报告往往很耗时。而且我需要不时获取有关档案的统计信息（即报告日期、客户、“打开”的平均长度等）。我想使用大数据方法，但不确定是否使用 Hadoop、Cassandra 或其他方法？有人可以为我提供一些指导如何开始并决定使用什么吗？
【问题讨论】：
标签： hadoop cassandra bigdata database
如果您的存档很大并且您想从中获取报告，您将无法仅使用 Cassandra，因为它没有简单的方法来聚合数据。您最终会将 Hadoop 和 Cassandra 配置在同一个节点上。
根据我的经验，存档（一次写入 - 多次读取）不是 Cassandra 的最佳用例，如果您有大量写入（我们已经尝试将它用于备份系统的后端）。根据您的压缩策略，您将为此支付空间或 iops 费用。添加的更改通过 SSTable 层次结构传播，导致写入比原始更改多得多。
如果不知道其他变量，就不可能完整地回答您的问题：您要分配多少硬件（服务器、它们的 ram/cpu/hdd/ssd）？每个“报告”条目的大小是多少？您通常每天进行多少次读取/写入？您的存档存储现在有多大？
【讨论】：
Cassandra 可能工作正常。保留两个表，reports 和reports_archive。使用 24 小时和 7 年的 TTL 定义架构：
CREATE TABLE reports (
...
) WITH default_time_to_live = 86400;
CREATE TABLE reports_archive (
...
) WITH default_time_to_live = 86400 * 365 * 7;
使用新的时间窗口压缩策略 (TWCS) 来最大程度地减少写入放大。将报告元数据和报告二进制数据存储在单独的表中可能是有利的。
对于汇总分析，请将 Spark 与 Cassandra 结合使用。您没有提及数据的大小，但粗略地说，每个 Cassandra 节点 1-3 TB 应该可以正常工作。使用 RF=3，您至少需要三个节点。
【讨论】：