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