如果您的表将达到数十亿条记录，rdbms肯定不会扩展。
关于hbase，它是否是一个好的解决方案取决于您的需求。如果您正在寻找实时读取，hbase只有在您只寻找特定密钥时才有帮助。如果您想对不同的列进行随机读取，hbase在这里不是一个理想的解决方案。hbase可以很好地扩展以防更新。
我建议您高效地设计hbase模式，并以适合您查询的方式存储数据。
但是，如果您对运行聚合查询感兴趣，还可以将hbase表Map到配置单元中的外部表，并对数据运行sql类型的查询。

如果写入速度为1/秒，则大多数可用数据库都应该能够支持这一点。因为您正在寻找长期/持久存储，所以应该考虑提供水平扩展的数据库，以便在需要增加容量时添加更多节点。具有自动切分功能的数据库非常适合您（cassandra、aerospike…）。确保您选择的自动分片数据库不需要客户机/应用程序来管理哪些数据存储在何处。在这种情况下，内存中的数据库不适合。
当您的存储容量只有几TB时，您可能需要担心数据库的规模、吞吐量，这样您的基础设施成本就不会让您陷入困境。
您的查询模式对于选择正确的解决方案非常关键。您可能不想索引所有内容，但可以微调索引内容，以便可以查询记录中的键和/或仅查询这些数据元素，这样索引存储开销就不会变得太大，从而可以控制成本。您还应该为数据库解决方案寻找时间范围查询能力，这似乎是典型查询模式的一部分。
最后但并非最不重要的一点是，您希望在尽可能快的时间内完成查询过程。您应该尝试cassandra（适合水平缩放，吞吐量较小）和aerospike（适合水平缩放，吞吐量相当不错）。

在这种情况下，可以将hbase用作nosql数据库。要使搜索更加定制和快速，请使用elasticsearch和hbase。

我的问题是关于您希望使用哪种类型的数据库存储库：ram？闪光？磁盘？
ram的响应时间为纳秒。以微秒为单位闪烁。磁盘以毫秒为单位。
当然，你可能想把这三个键混合在一起，特别是如果一些键比其他键更“热”的话——更容易被反复阅读。
如果您想进行大量的快速处理，并将其扩展到“更广的范围”（集群中的许多cpu用于更快的读取性能），那么您很可能是nosql数据库的候选对象。我需要更多地了解您的数据模型，以了解它是否可以作为键值存储，以及它如何需要更多的内部结构，如json/bson。
警告：我对我的雇主aerospike有偏见。然而，你应该做一些踢轮胎与我们或任何其他关键价值商店，你正在考虑看看它是否会与你的数据之前，投注农场。显然，每个nosql供应商都会声称自己是“最好的”，但这在很大程度上取决于您的用例。供应商的“解决方案”只适用于某些数据模型。我们倾向于最好的快速内存ram/闪存或混合实现。