我目前正在处理的应用程序有一个归档逻辑，其中超过6个月的所有记录将被移动到同一模式中的历史表中，但是在不同的表空间中。这是使用每天执行的存储过程实现的。
对于前。 TABLE_A（现场，最近6个月）==＆gt; TABLE_A_H（存档，超过6个月，最长8年）。
到目前为止没有问题。现在，该业务已经提出了一项新要求，其中存档数据也应该可供选择和使用。更新。即使对于一年前的数据，也可能发生更新。
选择可以是直接的，
从TABLE_A中选择*，其中id ='something'
或者它可以是开放式查询，例如，
从TABLE_A中选择*，其中created_date＆lt; 'XYZ'
更新通常用于特定记录。
这些查询作为REST服务公开给客户端。有可能存在垃圾/空值（应用程序无法清理输入）。
数据库的当前快照是
PARENT_TABLE（10M记录，每条记录10-15K）
CHILD_TABLE_ONE（28M记录，每条记录少于1K）
CHILD_TABLE_TWO（25M记录，每条记录少于1K）
CHILD_TABLE_THREE（46M记录，每条记录少于1K）
CHILD_TABLE_FOUR（57M记录，每条记录少于1K）
记忆不是一个约束 - 如果需要，我可以获得额外的2 TB空间 问题是如何在访问存档表时保持响应时间更短？ 在构建解决方案时，我应该考虑哪些方面？
解决方案1：对于直接选择/更新，请检查实时表中是否有记录。如果存在，请对实时表执行操作。如果不是，请对存档表执行操作。
对于开放式查询，请使用UNION ???
解决方案2：使用按月分区并将所有8年的数据保存在一组表中？ oracle是否可以在单个表中处理150多万条记录以便有效地进行选择/更新？
解决方案3：像Couchbase一样使用NoSQL吗？由于涉及的基础设施/成本，目前不是一个可行的解决方案。
解决方案4：???
Tech Stack：使用在JBoss上托管的Spring / Hibernate（Java 1.6）的Oracle 11G，J2EE应用程序。
非常感谢您的回复。
答案 0 :(得分：0)
如果我是你，我会选择解决方案2，并确保您有相关索引可用于您希望运行的查询类型。
按月分区意味着您可以利用分区修剪，假设查询涉及要分区的列。
这也意味着您无需修改现有代码即可选择或更新存档数据。
你必须设置内务处理以添加新的分区 - 除非你去区间分区，但它有自己的一套陷阱。