ran*_*tic 8 index oracle partitioning
我对数据库很陌生,所以如果我的问题非常基本,我深表歉意......
无论如何,我正在创建一个包含大量数据的表(现在有 5 亿行,未来可能会翻倍)。现在,我需要一种方法来快速访问该表中的数据,因此我正在研究分区和索引。但是,我对何时要创建分区与索引感到困惑。我有三列似乎是分区或索引的合理候选者:
当针对这个表运行未来选择时,我很可能会过滤客户端 id 以及想要做一些采样(我想通过“令牌”变量来做)。我可能偶尔也会按时间变量进行过滤。
所以,我的问题是:我应该如何组织我的桌子?是不是应该按Client和Token进行分区,然后按时创建索引?或者只是在客户端上分区并按时间和令牌创建索引?而且,更重要的是,您推荐的策略背后的逻辑是什么?
此外,在我创建了表之后,如果我向其中添加更多数据(尤其是相同日期/令牌范围的新客户端),索引是否会中断?重新创建索引相对简单吗?
非常感谢您的帮助,如果您需要我提供更多信息,请告诉我。
Dav*_*dge 15
简而言之,索引允许快速访问表的一小部分。这是因为它们访问的数据分散在数据段中的许多块中,因此除非您要查找的行聚集在少量块中,否则访问所有这些单个块的总成本将很快变得比仅仅扫描更大一张桌子。
如果您访问表的 20% 的行,您可能会从索引中受益,但 1-5% 更有可能是一个有效限制。
如果您想有效访问更大比例的行,比如 10% 的行,那么如果您可以使用分区方案将“可查询”组隔离到分区中,那么它们可以被非常快速地查询。即使您正在访问表的 1% 的行,那么如果查询可以从仅包含具有完整分区扫描的那些行的分区中检索它们,那么这将比通过索引访问它们更快——大约是 1/100执行全表扫描的时间(忽略并行查询)。
因此,如果您的查询经常在客户端 ID 上包含谓词,那么我会建议对其进行分区 - 列表分区。如果您还查询日期范围,则考虑对时间列进行范围分区。
因此,您可以按范围列表或列表范围组合分区。如果您想轻松删除旧数据,那么范围列表可能会更好,但我不确定它们之间有很多选择。
令牌听起来可能是索引的一个很好的候选者。索引是自我维护的,修改数据不会使它们失效。显然,维护它们是有开销的,但是通常查询数据的次数比修改数据的次数要多得多,因此总的来说,我倾向于“先建立索引,然后再提问”。
归档时间: |
|
查看次数: |
12745 次 |
最近记录: |