【问题标题】:insert data from one table to two tables group by for Oracle将数据从一张表插入到两张表中,Oracle 分组依据
【发布时间】:2015-05-25 20:57:58
【问题描述】:

我有一种情况,我需要在加载表中收集大量数据(每天 9+ 十亿)数据,该表具有以下字段 -表加载器

first_seen,request,type,response,hits
1232036346,mydomain.com,A,203.11.12.1,200
1332036546,ogm.com,A,103.13.12.1,600
1432039646,mydomain.com,A,203.11.12.1,30

需要拆分成两个表(去重)

-TABLE 最终

request,type,response,hitcount,id
mydomain.com,A,203.11.12.1,230,1
ogm.com,A,103.13.12.1,600,2

和 -TABLE 时间戳

id,times_seen
1,1232036346
2,1432036546
1,1432039646

我可以创建模式并进行选择

select request,type,response,sum(hitcount) from loader group by request,type,response;

将数据放入最终表格。为了获得最佳性能,我想看看是否可以使用“全部插入”将数据从加载器移动到这两个表中,并可能使用数据库中的触发器来尝试实现这一点。有关解决此问题的最佳方法的任何想法和建议?

【问题讨论】:

  • 这个问题还没有答案吗?
  • 要明确一点:您希望每个不同的 REQUEST 有一条记录,包括要与每个时间戳关联的生成 ID?另外:该表每天都有一组新数据。如果昨天有mydomain.com 的最终记录,mydomain.com today 的 ID 应该是什么?
  • 很抱歉没有提供足够的细节。不同的记录来自“请求、类型、响应”元组。这些在具有唯一 ID 的“最终”表中应该是不同的。如果新记录出现在 mydomain.com 的另一批中,例如“14330000000,mydomain.com,A,203.11.12.1,900”,则“id”=1 的总命中数应该增加,并且在“timestamps”表中添加一个新行时间戳 143300000000 对应。

标签: oracle database-design etl


【解决方案1】:

“每天 9+ 亿”

这不仅仅是大量的行:这是一个巨大的数字,需要特殊的工程来处理它。

对于初学者,您不仅需要 INSERT 语句。维护现有(request,type,response) 元组的计数的要求也指向更新。在这种情况下,需要生成和返回合成密钥是有问题的。它排除了 MERGE,这是实现 upsert 的最简单方法(因为 MERGE 语法不支持 RETURNING 子句)。

除此之外,尝试在单个事务中处理 90 亿行是一个坏主意。处理需要多长时间?如果中途失败会怎样?您需要定义更细化的工作单元。

不过,这会引发一些业务问题。在收盘后,用户只想看到全貌?或者他们会从看到日内结果中受益吗?如果是,如何区分日内结果和收盘结果?如果不是,如何在其余部分仍在运行时隐藏部分处理的结果?另外,他们希望在收盘后多久看到这些总数?

然后是架构方面的考虑。这些数字意味着每秒处理超过十万(十万)行。这需要严重的紧缩和昂贵的许可额外费用。显然企业版用于并行处理,但也有分区和 RAC 选项。

现在您应该知道为什么没有人立即回答您的问题。这是一个咨询工作,而不是 StackOverflow 问题。

但让我们草拟一个解决方案。

  1. 我们必须对传入的原始数据进行连续处理。因此,我们将记录流式传输到 LOADER 表旁边的 FINAL 和 TIMESTAMP 表中,这成为对原始数据的审计(或者我们可能完全摆脱 LOADER 表)。
  2. 我们需要批处理传入的记录以利用基于集合的操作。根据合成密钥的实现,我们应该针对纯 SQL,否则为 Bulk PL/SQL。
  3. 让事情继续下去是至关重要的,因此我们需要注意批量错误处理。
  4. 理想情况下,目标表可以分区,因此我们可以加载到离线表中并使用 Partition Exchange 使清理后的数据在线。
  5. 对于合成键,我很想使用基于(request,type,response) 元组而不是序列的散列键,因为这样我们可以选择独立加载 TIMESTAMP 和 FINAL。 (碰撞的可能性极小。)

需要明确的是,这是一个小事,而不是一个严肃的建筑。您需要针对生产等效硬件上的实际数据量对各种方法进行试验和基准测试。

【讨论】:

  • APC !完全同意。该计划是根据需要以每小时或更近的时间块加载数据。我们一直在使用类似云的解决方案(Netezza、Vertica 和 Hadoop 平面文件)对此进行测试,但其中一个客户站点首选 oracle,并为 RAC EE 提供生产支持。大多数查找的用例是在时间范围内验证“请求”的存在。可能有 60 天的窗口可以保存数据。
猜你喜欢
  • 1970-01-01
  • 2023-03-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-06-25
相关资源
最近更新 更多