这是一个关于什么类型的NOSQL解决方案更适合解决这个问题的问题。
问题
java后端系统以大约1000/秒的频率生成“参数”的“更新”。一个参数基本上是一个实体,它有一个值、一个类型、一个名称、一个描述,以及许多其他关于它的定义、有效性、检查、更新时间戳等信息。。。更新由一个java pojo表示(总共约450字节),包含大约40个字段。
有必要在未来10年内保存所有这些更新(1000/秒)。正如你所看到的,你最终将有大约350亿更新要存储。
要知道的一件重要事情是,每个更新都只有一小部分字段会更改:
-
通常会有每次都更改的字段(请参见值和时间),
-
其他很少改变的(比如类型,有效性检查),
-
其他基本上不会改变的(如名称、描述、UUID等)
将所有这些更新作为独立行存储在hbase中是不可行的,因为随着时间的推移,我最终将存储数PB的数据,而且我负担不起。我还认为,不可能对这些数据进行响应性检索。
另一个重要点是,我需要支持非常复杂的检索查询,通常使用复杂的过滤器。这些查询的一些示例报告如下:
-
检索选定1000个更新集的最后一天
参数
-
检索给定选定参数集的最后一个值。最后一个值有时只能在几年前的历史上找到(称为稀有参数)
-
基于名称通配符结束更复杂的筛选检索一组参数
问题
是使用像HBase这样的宽列解决方案更合适,还是使用像MongoDB这样的基于文档的解决方案更好?
我的首要任务是将存储量保持在兆字节(假设整个时间低于100-200兆字节)的顺序,并在几秒钟(通常是2-3秒)内实现查询响应。
我知道这是一个非常广泛的问题,但它会帮助我看到的观点,肯定有人比我更专家!
多谢提前
