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