2

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

问候， Priyank Devurkar

4

1 回答 1

0

好的，所以首先要做的事情。

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

审核...

Oracle 具有非常强大的审计功能，因此在尝试使用自己的审计功能之前应该先研究一下。

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

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

插入审计表（用户ID，操作）值（'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 返回用户表（这真的毫无意义）。

  • 如果您在数据库机器上有足够的内存，请将其设置为缓存缓冲区，但前提是您有足够的内存，否则您会将服务器放入油箱中。

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

  • 当你定义它时，确保你的表空间是BIG TABLE，因为这将确保你不会突破单个文件的大小限制（至少在 linux 上）。

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

时刻牢记unix座右铭，做一件事，做好。

于 2015-02-08T23:43:22.023 回答