在互联网上的多个来源中，解释说 HDFS 旨在处理比 NoSQL 技术（例如 Cassandra）更多的数据。一般来说，当我们超过 1TB 时，我们必须开始考虑 Hadoop (HDFS) 而不是 NoSQL。
除了架构和 HDFS 支持批处理以及大多数 NoSQL 技术（例如 Cassandra）执行随机 I/O 以及架构设计差异之外，为什么 NoSQL 解决方案（再次例如 Cassandra）不能处理和 HDFS 一样多的数据？
为什么我们不能将 NoSQL 技术用作数据湖？为什么我们应该只将它们用作大数据架构中的热存储解决方案？
【问题讨论】：
标签： hadoop cassandra hdfs nosql
为什么 NoSQL 解决方案（...例如 Cassandra）不能处理与 HDFS 一样多的数据？
HDFS 设计用于存储大量数据并支持批处理模式 (OLAP)，而 Cassandra 设计用于在线事务用例 (OLTP)。
目前建议的服务器密度是旋转磁盘为 1TB/节点，使用 SSD 时为 3TB/节点。
在 Cassandra 3.x 系列中，存储引擎已被重写以提高节点密度。此外，还有一些 JIRA 票可以在未来提高服务器密度。
目前 Cassandra 中的服务器密度存在限制，原因是：
修复。对于最终一致的数据库，在发生故障时必须进行修复以重新同步数据。您在一台服务器上拥有的数据越多，修复所需的时间就越长（更精确地计算 Merkle 树，一种摘要的二叉树）。但是修复的问题主要是通过Cassandra 2.1
压缩。使用 LSM 树数据结构，任何突变都会导致磁盘上的新写入，因此必须进行压缩以摆脱不推荐使用的数据或已删除的数据。您在 1 个节点上拥有的数据越多，压缩的时间就越长。也有一些解决这个问题的解决方案，主要是新的 DateTieredCompactionStrategy，它有一些调整旋钮可以在时间阈值后停止压缩数据。很少有人在生产中使用密度高达 10TB/节点的 DateTiered 压缩
节点重建。想象一个节点崩溃并完全丢失，您需要通过流式传输来自其他副本的数据来重建它。节点密度越高，重建节点所需的时间越长
负载分配。节点上的数据越多，平均负载就越大（高磁盘 I/O 和高 CPU 使用率）。这将极大地影响实时请求的节点延迟。虽然 100 毫秒的差异对于需要 10 小时才能完成的批处理场景而言可以忽略不计，但对于受严格 SLA 约束的实时数据库/应用程序而言，这一差异至关重要
【讨论】：