【问题标题】:Is it suggestible to have 2 separate tables for Read and DML是否建议为 Read 和 DML 设置 2 个单独的表
【发布时间】:2021-12-06 10:14:55
【问题描述】:

到目前为止,我们有一个包含 600 多列和 30M 多行的表。有20多列,其中定义了Index,表分布在5个分区中。

有超过 5 个实时运行的进程(写入特定分区),它们插入/更新到此表(每天大约 10k 插入和 1-2 百万次更新)。

此外,还有 20 多个进程,包含底层过程/视图/查询,它们连续读取该表。如果我将表中的select 与其他数据库进行比较,尽管有索引,但它的速度很慢。

现在我们计划重新设计和拆分表,因为现在许多列已经过时,并且许多列仅对特定分区有效。所以我们希望有 5 个单独的表,每个分区都有一个具有特定于该分区的属性的表。

是否建议有两组单独的表,一组用于 DML,一组用于 Select,并通过触发器同步它们?任何其他 关于表的拆分/同步的建议确实是 赞赏。

我尝试用下面的 2 个分区复制场景。第一个表是当前正在使用的表,我们将删除它并为每个分区创建 2 个单独的表,并具有特定于该分区的属性。

现有表:t,稍后我们将删除它。表是由REGION分区的

+----+--------+-------+-------+-------+-------+
| ID | REGION | NAME  | COL_1 | COL_2 | COL_3 |
+----+--------+-------+-------+-------+-------+
|  1 | A      | FOO   |    12 | Y     |       |
|  2 | A      | BAR   |    13 | N     |       |
|  3 | B      | ALPHA |    14 |       |     1 |
+----+--------+-------+-------+-------+-------+

新表:t_A

+----+--------+------+-------+-------+
| ID | REGION | NAME | COL_1 | COL_2 |
+----+--------+------+-------+-------+
|  1 | A      | FOO  |    12 | Y     |
|  2 | A      | BAR  |    13 | N     |
+----+--------+------+-------+-------+

新表:t_B

+----+--------+-------+-------+-------+
| ID | REGION | NAME  | COL_1 | COL_3 |
+----+--------+-------+-------+-------+
|  3 | B      | ALPHA |    14 |     1 |
+----+--------+-------+-------+-------+

【问题讨论】:

  • "...尽管有索引,但从表中选择很慢..." -- 不应该这样,除非您在每个 SELECT 上读取大量行。我的猜测是你没有最好的索引。也许解决方案只是调整 SELECT。如果是这种情况,请将它们包括在内,以便我们帮助您调整它们。
  • 表格有“600 多列”这一事实高度暗示设计存在严重缺陷。严格按照第三范式设计所有表格,95% 的问题都会自行消失。

标签: sql oracle oracle19c


【解决方案1】:

您几乎肯定不想手动创建单独的表集以供读写。读取器和写入器在 Oracle 中不会相互阻塞,除非您遇到一些极其罕见的情况,否则这 25 个并发进程不会导致热块性能问题。

拆分表更有可能在缓存和复制方面产生新问题。数据量翻倍也意味着可能有两倍的数据要尝试塞入内存。而且自定义复制程序会显着降低写入性能,因为所有写入都是重复的,并且触发器的上下文切换会更多。

唯一有意义的情况是为读取和写入创建单独的表是如果您已经有一个只读系统,例如如果您使用数据保护来创建逻辑备用数据库。在这种情况下,您可以使用 Oracle 的内置复制,它可能比自定义版本更快、更准确。如果您的第一个数据库资源不足,则第二个数据库可能有助于提高性能。 (理想情况下,将所有内容保存在单个数据库中总是会更快,但实际上,您的服务器只能增长到如此之大。)

正如其他人所提到的,在考虑分离表之前,您可能应该投入更多时间来调整现有查询。

【讨论】:

    猜你喜欢
    • 2016-04-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-07-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多