表分区的抽象层-JPA 事实 数据库：PostgreSQL（最新） 编程语言：Java 问题陈述（简化）

我们有两个表-概述和详细信息。“概述”中可能有数百万行，而“概述”的每一行在“详细信息”中可能有数百万行与其关联。外键details.overview\u id指的是overview.id。大多数查询都是一般形式的

SELECT*FROM details，其中overview_id=xxx和details.id>yyy和details.id

如果我们有一个用于详细信息的表，那么查询速度会太慢（尽管关于详细信息的查询几乎总是在主键上）。

有关DB活动性质的更多信息：插入和更新概览的情况很少发生。详细信息的插入速度很快，而对同一个表的更新几乎从不发生，有时也会发生批量删除

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

当前目标
目前，我们正在探索一种机制的选项，通过这种机制，分区可以在幕后进行——可能是由JPA提供商进行的（我知道这不是JPA规范的一部分），这样我们就可以在底层框架/层处理可伸缩性问题的同时关注应用程序

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

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

谢谢。

Prajesh
您研究过使用Postgres的表分区吗

感谢大家迄今为止的评论/回答。我们决定坚持我们已经拥有的（请参阅“我们已经拥有的”一节），只做一些小的修改。
关于父概览外键的索引详细信息，您做了哪些工作？如果您总是访问特定的子集，索引应该会有所帮助。@wrschneider99我想我理解您的建议。可以随时请求任何概览id的数据，包括对多个概览id的单个请求。所以，我想，这并没有什么乐趣。openjpa和postgresql分区表有一个问题