【发布时间】：2018-09-06 05:47:28
【问题描述】：
甲骨文大师，
我们正在决定设计 500 列宽的表与 8 列宽但 40 亿行深的表的最佳方法。该表将每周更新一次，每周日在表中添加新的一周（过去的最后一周）数据。 由于数据因周数（财政）而异，我们对上述设计的优缺点有两组想法-
对于宽表 - 想法是设计一个包含 3 属性列的表，其中每个周数一直追溯到过去 160 周。所以这给了我们 160 x 3 = 480 列宽。这个想法是，每周当我们将上周的数据添加到表中时，我们将从表中删除最旧的周列，并将最新的周列添加到表中。根据 ColA - ColD 上定义的键，该表将包含大约 4000 万行（请参阅下图）。这是示例-
对于深度表 - ColA - ColD 字段保持不变，除了有一个新的周列，该列因在 ColA-ColD 上定义的键而异。当我们构建这个表时，我们的想法是只将最近的一周粘贴到具有适当周数的表中，并有一个单独的清除（维护）过程来从表中删除最旧的周行。该表将有大约 40 亿行和 8 列宽。这是一个关于它的外观示例 -
我们绝对理解需要在此处按周数对任一表进行分区，无论我们选择哪个表。 表格的使用 - 并发用户将多次查询该表格以获取过去 52 周的匹配周数和 ColA 值，并且期望在不到 5 分钟的时间内从中创建报告。 我在这里寻求 Oracle 大师的建议，无论您是否根据经验看到一个表宽到近 500 列，在我们向表中构建数据时每周都会删除或添加列，以及它如何影响性能用于高度并发的报告生成工具。相反，如果您使用的表深达 40 亿行（但列不会每周更改），那么使用此表的并发报告流程对性能有何影响。
谢谢你，非常感谢你的时间！！ 布伦登
【问题讨论】：
-
从我的角度来看，我宁愿有一个 [8 列的表 x 40 亿行]。虽然没有处理那么多数据的经验，但我认为编写处理有限列数（8 列，对吗？）的查询并调整它们比虚拟死要容易得多注意我是否从 500 列中选择了正确的 3-4 列。对我来说就像一场噩梦。
-
500 列。没有永不。永远不能。当他们想要过去 180 周时会发生什么。您必须更改您的表格并制作一个 600 多列的表格吗？您的 8 列表中的相同更改...不过是更多记录。在记录中增长，而不是在列中增长。分区和索引使其更快。40亿是很多，但不是那么大。
-
您建议每周为宽表删除一列并添加一个新列。主没有。那是疯狂的谈话。一次构建您的对象/模式（数据库、表、列）并且永远不要再次更改它们。这就是你应该瞄准的目标。
-
@JNevill 谢谢，我完全明白并且完全同意它。这也是我的想法，但我想做一个尽职调查，以了解宽表逻辑从性能的角度来看是否有任何优点。特别是当我们希望每次都以良好的并发度（同时超过 10 个用户）对该表运行严格的周选择查询时。谢谢！！
-
按周分区意味着当人们对这个巨大的表进行选择时，他们实际上只会命中该分区中的记录。这意味着实际查询仅达到 40 亿条记录的 1/160，即大约 2500 万条记录。对您将针对此运行的任何查询进行适当的索引将非常有帮助。这基本上是每个 RDBMS 的设计目的。快速查询巨大的“深”表并允许调整以实现这一目标。它们的设计目的不是为了让它们的列定期翻转和翻转，并在非常广泛的选择中提供快速检索。
标签： oracle performance plsql oracle12c bulk-operations