按Oracle分组将数据从一个表插入到两个表

我的情况是，我需要在一个加载表中收集大量数据，每天90多亿个数据，该加载表包含如下字段 -台式装载机

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

需要拆分为两个重复数据消除的表

-决赛

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

及 -表时间戳

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

我可以创建模式并执行类似的选择

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

将数据放入最终的表中。为了获得最佳性能，我想看看是否可以使用insert all将数据从加载程序移动到这两个表，或者使用数据库中的触发器来尝试实现这一点。关于解决这个问题的最佳方法有什么想法和建议吗

每天90多亿美元

这不仅仅是大量的行：这是一个巨大的数字，需要特殊的工程来处理

首先，您不仅需要INSERT语句。维护现有请求、类型和响应元组的计数的要求也需要更新。在这种情况下，需要生成并返回合成密钥是有问题的。它排除了MERGE，这是实现upserts的最简单方法，因为MERGE语法不支持RETURNING子句

除此之外，试图在一个事务中处理90亿行是个坏主意。处理需要多长时间？如果中途失败怎么办？您需要定义一个更细粒度的工作单元

尽管如此，这也引发了一些商业问题。在一天结束后，用户只想看到整个画面是什么？或者他们会从看到日内结果中获益吗？如果是，如何区分日内和日终结果？如果否，如何在其余结果仍在运行时隐藏部分处理的结果？此外，他们希望在当天结束后多久看到这些总数

然后是架构方面的考虑。这些数字意味着每秒处理超过10万到10万行。这需要严重的困难和昂贵的额外许可。显然，企业版适用于并行处理，但也适用于分区和RAC选项

现在你应该知道为什么没有人直接回答你的问题了。这是一个咨询工作，不是一个问题

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

我们必须对传入的原始数据进行连续处理。因此，我们将记录流化，以便与加载器表一起加载到FINAL表和TIMESTAMP表中，这将成为对原始数据的审计，否则我们可能会完全删除加载器表。 我们需要对传入记录进行批处理，以利用基于集合的操作。根据合成键实现的不同，我们的目标应该是纯SQL，否则就是批量PL/SQL。 让事情继续进行是至关重要的，因此我们需要注意批量错误处理。 理想情况下，目标表可以分区，因此我们可以加载到脱机表中，并使用分区交换将清理后的数据联机。 对于合成键，我倾向于使用基于请求、类型、响应元组的哈希键，而不是序列，因为这将为我们提供独立加载时间戳和FINAL的选项。碰撞是极不可能的。

---

要清楚的是，这是一件小事，不是一个严肃的架构。您需要根据生产等效硬件上的实际数据量对各种方法进行试验和基准测试

关于这个问题还没有答案吗？只是想澄清一下：您希望每个不同的请求都有一条记录，包括您希望与每个时间戳关联的生成ID？另外：该表每天都有一组新的数据。如果昨天有mydomain.com的最终记录，那么今天mydomain.com的ID应该是什么？很抱歉没有提供足够的详细信息。不同的记录来自请求、类型和响应元组。在具有唯一ID的最后一个表中，这些记录应该是不同的。如果mydomain.com的另一批中出现了新记录，如143000000、mydomain.com、A、203.11.12.1900，则ID=1的总命中数应增加，并相应地向时间戳表中添加一行时间戳1430000000.APC！完全同意。计划是按每小时或更近的时间段加载数据。我们已经用类似云的解决方案Netezza、Vertica和Hadoop平面文件对此进行了测试，但客户的一个站点更喜欢oracle，并且支持RAC EE的生产。大多数查找的用例是在一个时间范围内验证请求的存在。也许60天的时间窗是保存数据的好时机。