甲骨文大师,
我们正在决定设计一个500列宽的表和一个8列宽但深40亿行的表的最佳方法。该表将每周更新一次,每周日在表格中添加新的一周(过去的最新一周)数据。由于数据因周数(财政)而异,我们对上述设计的利弊有两种看法:
对于宽表,思想是设计一个包含三个属性列的表,用于每周数,在过去的160个星期中一直如此。因此,我们得到一个16x3= 480列宽。我们的想法是,每周向表中添加最后一周的数据时,我们将从表中删除最古老的周列,并将最新的周列添加到表中。根据ColA - ColD上定义的键,该表中将有大约4000万行(请参阅下面的图片)。举个例子-

对于深表- ColA-ColD字段保持不变,除了一个新的周列的变化,由键上的可乐-冷。当我们构建这个表时,我们的想法是只将最近的一周与适当的周号粘在表上,并有一个单独的清除(维护)过程,以从表中删除最古老的周行。这个表将有大约40亿行和8列宽。这是一个关于它的样子的样本-

我们绝对理解按周数对任一张表进行分区的必要性,无论我们选择哪一张表。表的使用-并发用户将对表进行多次查询,以获得过去52周内匹配的周数和ColA值,并期望在不到5分钟内从表中创建报告。我在这里征求Oracle Gurus的意见,在您的经验中,您是否见过一张宽到每周都有近500列的表格,在我们将数据生成到表中时,会减少或添加列,以及它如何影响高度并发的报表生成工具的性能。相反,如果您处理过一个深度高达40亿行的表(但这些列不会每周更改一次),那么使用此表的并发报告过程对性能有什么影响。
谢谢您,非常感谢您的时间!布兰登
发布于 2018-03-28 07:41:51
你想要一张投影一致的桌子。这意味着8列,40亿行配置。
删除列本身是一项昂贵的任务。除此之外,您还需要更改每周引用表的所有代码,这似乎不是一个好主意。另一种方法是对此表上的每个调用使用动态SQL,这甚至更不可取。
有了40亿行,您肯定应该购买分区选项。假设您的大多数查询使用WeekNumber,您的查询将受益于分区剪枝。但是,通过分区Exchange加载数据并使用Drop分区删除数据的能力在大量数据的争论中是非常宝贵的。
https://stackoverflow.com/questions/49519302
复制相似问题