表分区的抽象层 - JPA

Question

事实

• 数据库：PostgreSQL（最新）
• 编程语言：Java

问题陈述（简体）

我们有 2 个表格 - 概述和详细信息。 “概述”中可能有数百万行，并且“概述”的每一行都可以在“详细信息”中与数百万行相关联。外键 details.overview_id 指的是overview.id。大多数查询都是一般形式的

SELECT * FROM details WHERE overview_id = xxx AND details.id > yyy AND details.id < zzz;

如果我们有一个单表查询详细信息，查询将太慢（尽管查询详细信息几乎总是在主键上） .

更多关于 DB 活动性质的信息：INSERT 和 UPDATE 概述很少发生。 INSERT 细节的发生速度很快，而同一张表上的 UPDATE 几乎从不发生，有时会发生批量 DELETE。

我们已经拥有的

过去，我们使用原始 SQL 将表“详细信息”与“概览”中的每一行进行分区。 （实际上，我们实际上并没有进行分区，而是基于模板创建了新表。这些表没有任何名为 overview_id 的列（节省存储空间），而是我们有一个单独的表来完成 overview.id 和特定分区表的表名。）因此，正如您所理解的，分区必须动态生成，因为在概览中插入了新行，并且在从概览中删除行时删除了分区。所有这些都在应用程序内部进行管理。应用程序与数据库的交互速度非常快，但应用程序代码相当复杂，难以维护。此外，原始 SQL 随处可见，很难横向扩展数据库 - 我们必须重新发明大多数 JPA 提供商已经完成的工作。

当前目标

目前，我们正在探索一种机制选项，通过这种机制可以在幕后发生这种分区 - 可能由 JPA 提供者（我知道这不是 JPA 规范的一部分），以便我们可以专注于应用程序，而底层框架/层负责可扩展性问题。

我查看了 openJPA Slice 和 EclipseLink。它们都提供跨主机的分区（分片）管理。我们当然需要那个。但是我们还需要在单个主机内进行分区管理。但是，如果对此有更好或更优雅的解决方案，或者如果有完全不同的角度来看待这个问题，我会很高兴知道这一点。

如果您能提供任何见解，我将不胜感激。

谢谢。
普拉杰什

Answer 1

您是否考虑过使用 Postgres 的表分区？

http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html

Answer 2

感谢大家迄今为止的 cmets/answers。我们决定坚持我们已经拥有的东西（参见“我们已经拥有的东西”部分），并稍作修改。