我在这些字段的数据库中基本上有一个巨大的巨大表（大约1.000.000.000.000条记录）：
id，block_id，record
id是唯一的，block_id不是唯一的，它包含大约10k（max）个记录，具有相同的block_id但具有不同的记录
为了简化处理数据库的工作，我有一个类似于此的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方法返回愚蠢（使用add操作不是这样）。我也在考虑缓存和内存映射，在询问是否有针对这种情况的解决方案之前，我只是不想让自己复杂化？
答案 0 :(得分：1)
听起来你已经在postgres中运行了这个 - 你可以发布你正在使用的架构吗？在非常特定的情况下，确实可能比一个调整良好的数据库做得更好，但通常会比你想象的要多得多（特别是如果你正在同步写入）。
您是否在索引中使用CLUSTER？该表的存储设置是什么？
在您的查询变得太慢之前，表格有多大？
答案 1 :(得分：1)
由于您似乎在PostgreSQL之上构建对象存储，为什么不使用对象存储？
我从OpenStack Swift开始：
或者，分布式网络文件系统，如果它更接近您的需求。 （ab）如果你关心性能，使用PostgreSQL作为网络文件系统并不会让你走得太远。我唯一需要做的就是当我需要ACID语义时 - 例如某些数据库更改的原子提交以及它们所涉及的文件。
你没有得到多个PostgreSQL实例的原子提交（虽然你接近，准备好的派系）所以我猜这不是你的用例。如果不是，我建议寻找合适的工作。
答案 2 :(得分：1)
经过一番研究。我发现这些数据存储占据了我的大部分用例：
有趣的是，他们主要支持java集合的API（列表，集合，映射......）
编辑：所有这些Proyects允许我打开一个文件作为大型集合的数据存储，我可以按名称引用它们，每个文件可以有很多集合。他们每个都被索引。我们的想法是将这些项目用作真实数据库的基础，您可以将它们视为数据库的数据存储引擎（无论是SQL还是NoSQL）。因为这些项目是mongodb，h2database和orientdb等项目的基础，所以我相信，如果简单的数据流方法符合我的需求，它也可以毫无问题地扩展。因为我的分区需求非常简单，所以我也可以与其他节点共享负载。