对于该问题，应使用哪种“大数据”解决方案？ Hbase？ MongoDB？其他人？

Question

这是关于哪种类型的NOSQL解决方案更适合解决此问题的问题。

问题

一个Java后端系统以大约1000 / sec的频率产生“参数”的“更新”。参数基本上是一个实体，具有值，类型，名称，描述以及与其相关的很多其他信息，这些信息涉及其定义，有效性，检查，更新时间戳等。更新由java pojo表示（总共约450个字节），并包含约40个字段。

接下来的十年中需要保存所有这些更新（1000 /秒）。如您所见，您最终将要存储约350亿个更新。

要了解的重要一点是，每次更新只有一小部分可更改的字段：

• 通常有些字段每次都会更改（请参阅值和时间），
• 其他很少更改的内容（例如类型，有效性检查）
• 其他基本不变的名称（例如名称，说明，UUID等）

将所有这些更新存储在hbase中作为独立的行是不可行的，因为随着时间的推移，我最终将存储PB级数据，而我负担不起。我还相信，将不可能有响应地检索这些数据。

另一个重要的一点是，我需要支持非常复杂的检索查询，通常需要使用复杂的过滤器。这些查询的一些示例报告如下：

• 检索所选的一组1000的更新的最后一天 参数
• 检索给定一组选定参数的最后一个值。有时仅在几年前就可以找到最后一个值（称为稀有参数）
• 根据名称通配符检索单个参数集，结束过滤更为复杂

问题

使用像HBase这样的Wide列解决方案更合适，还是像MongoDB这样的基于文档的解决方案更好？

我的首要任务是将存储保持在1 TB字节的数量级（在整个时间内保持在100-200 TB以下），并使查询响应速度在几秒钟的数量级（通常为2-3）。

我知道这是一个非常广泛的问题，但这将帮助我看到某个人的观点，肯定比我更专业！

非常感谢

Answer 1

HBase非常适合具有大量随机读写访问模式的键值型工作负载，特别是对于那些已经将HDFS作为公共存储层投入大量资金的组织。领先的Hadoop发行商将HBase定位为“超大规模但相当简单的用例”。

与MongoDB相比，该定位继续说明以下内容：“如果您要在特定键上查找用户，HBase提供了非常快速的随机读取和随机写入，但是MongoDB提供了更丰富的模型，您可以通过该模型进行跟踪整个在线应用程序中的用户行为。”

MongoDB的设计理念将关系技术中的关键概念与新兴NoSQL数据库的优势融合在一起。虽然HBase具有高度可扩展性，并且可以在部分用例中实现高性能，但是MongoDB可以在更广泛的应用程序中使用。与HBase相比，后者的直观数据模型，多文档ACID事务，丰富的查询框架，本机驱动程序以及较低的操作开销通常使用户能够更快，更轻松地交付新应用程序。