在 oracle 中为大表设计模式

Question

我有一个用户表、事务表和 user_transaction 表。用户数约为 75,000 应用程序中可能的唯一事务数约为（事务表中的行在 1 到 300 万之间）。 user_transaction 是上述两个表的连接，存储用户在什么日期和时间做了哪些事务。所以这个表对于 1 年的数据来说将是巨大的（我们将从表中清除活动数据并在 1 年后将其归档）年）。我们预计计数约为 50-6000 万行。这将是年底的最终数据大小。

我会说平均大小约为 3000 万条记录。 此外，每晚导入作业都会更新所有这些表，这是在这些表中完成插入时的唯一部分，我们只能从我们的应用程序访问数据（使用选择查询）。

设计连接表以更快地从庞大的事务表中检索的最佳方法是什么？我们在表中添加了许多字段以对其进行去规范化并减少连接，并且几乎所有数据都仅在事务中可用，并且user_transaction 表。

如果我们想对表进行分区，我们如何进行分区？该应用程序用于最频繁地查询最近的数据。

我们正在考虑按月对事务表进行分区，这样我们每个月就会有 1 个表..

我们考虑的其他选项是每周 1 天有 7 个表，但考虑到我们正在使用休眠，这大大增加了查询的复杂性。

我们如何设计大约 6000 万的巨大桌子

根据要求提供更多详细信息：
我将不得不从模式中制作一个图表，同时这里还有更多信息：关系并不复杂，它大约有 4 个表：用户、事务、users_transaction、资源表。 user_transaction 是包含所有其他三个表 id 的连接表，这将是一个巨大的表，因为它将在每个 id 上都有单独的条目，并且还会根据时间戳进行单独的条目。
目前该应用程序的用户数量非常少，例如 表的主要消费者是：
1) 每周自我审核报告作为电子邮件发送，其中包含这些表格中过去一周的用户活动详情。这些将（最终）发送给 75,000 名用户，生成报告并为 1 个用户发送电子邮件目前大约需要 1 分钟（试验阶段的测试）。我们需要认真提高这方面的性能，以使每封电子邮件的时间少于 5 秒。这是一个在晚上运行的后端作业（最多应该消耗 3-4 小时）
2) 仪表板包含图表，这些图表显示了这些表格中的交易摘要视图。这些查询根据日期范围内的各个字段运行和汇总数据。 因此，如果所有其他字段都相同（用户 ID、资源 ID、资源事件 ID、位置），我们计划汇总 user_transactions 表存储每天（不包括时间）的计数。
并根据月份对这些汇总表进行分区。 （每个月一个）
注意事项：该解决方案应该适用于所有数据库（MySQL、DB2 等），而不仅仅是 oracle。

问候， 普里扬克·德维尔卡

Answer 1

好的，首先要做的事情。

1. 按照 Oracle 标准，包含 3000 万行的表并不庞大。
2. 说您有 75,000 个用户意味着数据库没有管理您的用户登录，并且可能有一些角色正在处理数据库。

审计...

Oracle 具有非常强大的审计功能，因此在尝试使用自己的审计功能之前应先了解这些功能。

如果您真的想推出自己的产品，那么用户和交易之间存在一对多的关系。现在我在这里非常松散地使用术语事务，因为您似乎想要做的是记录用户 X 何时修改表或表中的行。

最简单的做法是使用您使用的任何前端代码来插入该表，例如：

插入审计表（userID、Operation）值（'fred'、'更新表支付并将某些列旧值更改为新值'）；

我会创建一个用户 ID 和时间戳的复合索引，以便可以在这两个列上作为单个实体查询 if。该表看起来像：

create table user_audit as 
(
user_id number,
action_timestamp systimestamp,
db_action clob
)

CREATE INDEX idx_user_audit_ia ON  user_audit (user_id,action_timstamp);

复合索引的作用是创建几乎两个键的哈希，当您通过这两列查询时它们非常非常快。

这个单表对于删除和插入将非常非常快。您可以通过以下方式使其更快：

• 没有主键约束。
• 关闭此表或其所在表空间的日志记录。

• 没有返回用户表的 FK（这真的毫无意义）。

• 如果您在数据库计算机上有足够的内存，请将其设置为缓存缓冲区，但仅如果您有足够的内存，否则您会将服务器放入容器中。 p>

• 如果您选择分区，则只有在仔细阅读并理解Oracle上的分区后选择您的方法。

• 确保您的表空间在定义时是 BIG TABLE，因为这将确保您不会超出大小限制（在 linux 上至少 ) 的单个文件。

至于您处理的其他数据库将有各自的调优问题，因此每一个都是一组适合一个数据库引擎但不适合另一个数据库引擎的一次性条件。

时刻牢记unix的座右铭，做one一件事，然后做好。