超级快速文件存储引擎

Question

基本上，我在一个数据库中有一个巨大的表(约1.000.000.000.000条记录)，其中包含以下字段：

id，block_id，记录

id是唯一的，block_id不是唯一的，它包含大约10k (max)记录，具有相同的block_id，但是有不同的记录。

为了简化处理DB的工作，我有一个类似于以下内容的API：

Engine e = new Engine(...);
// this method must be thread safe but with fine grained locked (block_id) to improve concurrency
e.add(block_id, "asdf"); // asdf up to 1 Kilobyte  max

// this must concatenate all the already added records added block_id, and won't need to be bigger than 10Mb (worst case) average will be <5Mb
String s = e.getConcatenatedRecords(block_id);

如果我将每个块映射到一个文件(尚未完成)，那么每个记录都将是文件中的一行，我仍然能够使用该API。

但我想知道，与良好调优的postgresql数据库相比，使用平面文件是否会有任何性能上的提高？(至少在这种特定情况下)

不过，我最大的要求是，getConcatenatedRecords方法返回速度非常快(添加操作不是这样)。我也在考虑缓存和内存映射，我只是不想在询问是否已经为这种场景制定了解决方案之前让自己复杂化？

Answer 1

经过一番研究。我发现，这些数据存储在我所拥有的大部分用例中占了很大一部分：

• MVStore of H2数据库
• MapDB
• Oracle Bekeley DB Java版
• 京都内阁似乎没有积极的发展

有趣的是，它们大多支持java集合的API (列表、集合、映射.)

编辑:所有这些预言允许我打开一个文件作为一个巨大集合的数据存储，我可以按名称引用它们，每个文件可以有许多集合。它们中的每一个都有索引。其思想是，这些项目将被用作实际数据库的基础，您可以将它们视为数据库的数据存储引擎(无论是SQL还是NoSQL)。由于这些项目是mongodb、h2database和orientdb等项目的基础，所以我确信，如果简化的数据方法符合我的需要，那么它也不会出现任何问题。因为我的分区需求非常简单，所以我也可以与其他节点共享负载。

Answer 2

听起来您已经在postgres中运行了这一功能--您可以发布正在使用的架构吗？当然，在非常具体的情况下，可以做得比经过良好优化的数据库更好，但通常情况下，所做的工作比您想象的要多得多(特别是在同步写入的情况下)。

您是否在索引中使用聚类？表的存储设置是什么？

在查询变得太慢之前，表可以有多大？

Answer 3

既然您似乎在PostgreSQL上构建对象存储，那么为什么不使用对象存储呢？

我从OpenStack斯威夫特开始：

• OpenStack块存储(Swift)
• Swift医生

或者，选择一个分布式网络文件系统，如果这更接近您的需要。(Ab)如果您关心性能，使用PostgreSQL作为网络文件系统不会有多大帮助。只有当我需要ACID语义时，我才会这样做--比如一些数据库更改的原子提交以及与它们相关的文件。

您不会在多个PostgreSQL实例上获得原子提交(尽管您已经接近了，使用了准备好的事务处理)，所以我猜这不是您的用例。如果不是，我建议你也去找合适的工作。