【问题标题】:Best way to design for one-to-many code values in Oracle在 Oracle 中设计一对多代码值的最佳方法
【发布时间】:2015-08-12 19:26:05
【问题描述】:

我们每天会收到数百万条温度指标记录。这些记录的大部分相关元数据按日期(月)保存在单个分区表中。我们将开始接收多达 20 个与此数据相关的单独代码。目的是最终允许通过这些代码进行搜索。

存储这些数据以最大限度地缩短搜索响应时间的最有效方法是什么?数据库是 Oracle 11gR2。

我正在考虑的一些选项:

(1) 使用主记录 id 和代码值创建一个单独的表。类似的东西

id        code
--        ----
 1        AA
 1        BB
 1        CC
 2        AA
 2        CC
 2        DD

关注点:

  • 可能需要在代码列上使用位图索引,但该表是高度事务性的,因此没有位图
  • 随着时间的推移,表格会变得越来越大,每个主记录最多包含 20 个代码

(2) 创建一个按代码值分区的单独表。

关注点:

  • 新代码的分区维护
  • 搜索性能

(3) 在现有表中添加一个 XMLType 列,并将每条记录的代码格式化为 XML,并在该列上创建一个 XMLIndex:类似于:

<C1>AA</C1>
<C2>BB</C2>
<C3>CC</C3>

关注点:

  • 在 CODE 上搜索时的查询响应时间可能会很短

欢迎任何建议。

谢谢。

【问题讨论】:

  • 用主记录 id 和代码值创建一个单独的表。代码上的索引对于查询将执行得足够好,并且不会过多地减慢插入速度。我假设在这个单独的表上不会有更新或删除。
  • 您的意思是将来您想查询一个表以查找所有具有代码 A 的 ID 或其他代码?每天多达 2000 万条记录的数据量将很快变得难以理解。

标签: oracle performance database-design oracle11g database-partitioning


【解决方案1】:

您需要对不同的方法进行基准测试。如果对您的场景有更多了解,我们无法为您提供有意义的解决方案。总共会有多少种不同的代码?每次读取的平均代码数是多少?代码的分布是否会出现明显的偏差? code搜索需要支持哪些访问路径?

然后是如何加载数据的问题(批量?滴灌?)。以及您可以从使用分区中获得哪些好处。

无论如何。这是另一种方法,它是您的 (1) 和 (2) 的合并。

鉴于您的主表是按月分区的,您可能应该使用相同的方案对任何子表进行分区。您也可以通过code 进行子分区。

create table main_codes
    ( reading_dt date not null
      , main_id number not null
      , code varchar2(2)
      , constraint main_codes_pk primary key (code, reading_dt, main_id) using index local
     )
partition by range (reading_dt) 
subpartition by list (code) 
subpartition template 
( 
    subpartition sp_aa values ( 'AA' ), 
    subpartition sp_bb values ( 'BB' ), 
    subpartition sp_cc values ( 'CC' ), 
    subpartition sp_dd values ( 'DD' )
) 
(
    partition p_2015JAN values less than (date '2015-02-01' ),
    partition p_2015FEB values less than (date '2015-03-01' ),
    partition p_2015MAR values less than (date '2015-04-01' )
)
/ 

你可能也想在主桌子上放一个外国人:

alter table main_codes 
    add constraint code_main_fk foreign key (reading_dt, main_id)
    references main_table (reading_dt, main_id)
/

create index code_main_idx on  main_codes (entry_dt, id) local
/

根据您拥有的代码数量,创建子分区模板可能很乏味。这就是大自然给予我们剪切和粘贴的原因。

但无论你做什么,不要走 XML 路径

【讨论】:

  • APC,非常感谢您的详细回复。总共将有 20 个左右不同的代码,未来可能会添加更多。代码应该均匀分布(即没有倾斜)。数据将以点滴形式输入,每天加载的每 2-3 百万条记录大约有 20 个代码,因此每天有 40-60 百万个代码。我们需要提供按代码本身搜索或按日期和代码搜索的功能。对于这种性质的代码,位图显然是理想的解决方案,但由于该表的高度事务性质,这是不可能的。
  • (续)。我正在考虑复合分区(按日期,然后按代码),但如果用户只按代码搜索,这将扫描所有分区。当然,这对于日期和代码搜索很有效。不幸的是,这似乎是使用任一分区替代方案的 catch-22。我希望我能想出一个解决方案,可以在未来无缝适应任何新代码,而无需人工干预和/或停机(即分区维护)。再次感谢您的洞察力。顺便说一句,感谢 APC 很好地格式化了我的原始帖子。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-08-02
  • 2015-05-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-09-05
相关资源
最近更新 更多