3

假设我们有三张桌子：
-建筑物 -房间-
人

一栋建筑可以有 1 到 30 个房间（假设平均是 3 个）
，一个建筑物可以有 0 到 30 个人（平均为 3 个）
一个房间和一个人只能属于一个建筑物。

每个月我们都会在我们的数据库中添加大约 50.000 座新建筑及其房间和人员。
我们可以删除超过 2 年的数据，因此我们将拥有大约 120 万个建筑物行。

主要问题是我们想要搜索并返回通常（但不总是）包含至少两个表（建筑物总是存在）的数据，因此我们必须执行连接。

我研究了 3 个解决方案。

  • 具有标准化数据（由于连接和可扩展性低而导致性能低下）
  • 在 Room 和 People 表中复制建筑数据。（很快，但我通常不喜欢非规范化）
  • Oracle 集群表。（似乎提供了良好的性能并且数据仍然是规范化的）

那么问题来了：
Oracle Cluster 适合这种情况吗？
可以连续向这样的集群添加行吗？
如果您不推荐 Cluster，为什么以及什么更适合？

细节：

簇：

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_C R
  INNER JOIN PEOPLE_C C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_C S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--17 consistent gets

自动跟踪输出

标准化：

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_N R
  INNER JOIN PEOPLE_N C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_N S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--44 consistent gets

自动跟踪输出

4

2 回答 2

6

集群是一种存储密切相关的表的方法，这些表通常连接到磁盘上的同一区域。集群键是在查询中通常用来连接表以节省 IO 的一列或多列。但是，如果单个 Cluster Row 中所有表行的总大小超过一个磁盘块的大小，那么您最终将处于链接状态，并且有一天，您将失去集群的所有优势。在我看来，最好避免，因为考虑到集群中所有 3 个表的滚动量为 1.2 M，这显然会产生 HWM 的影响，这将是一个开销。

最好去JOINS。

例如。

CREATE TABLE BUILDING_C ( BUILDING_ID NUMBER PRIMARY KEY,
                     ADDRESS_FIELD VARCHAR2 ( 25 ) );

CREATE TABLE PEOPLE_C ( BUILDING_ID NUMBER PRIMARY KEY,
                    CUSTOMER_ID NUMBER,
                    ROOM_ID NUMBER,
                    CUSTOMER_DETAILS VARCHAR2 ( 25 ) );

CREATE TABLE ROOM_C ( BUILDING_ID NUMBER PRIMARY KEY,
                  ROOM_ID NUMBER,
                  OPEN_DATE DATE,
                  CURRENT_OCCUPANCY CHAR ( 1 ) );

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'BUILDING_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'PEOPLE_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'ROOM_C',
                            NUMROWS  => 20000000 );
END;
/

在您的查询中，您的提示将不会生效，因为您使用SELECT * /*+ FIRST_ROWS(200)*/了而不是SELECT /*+ FIRST_ROWS(200)*/ *所以您最终会使用 OPTIMIZER MODE=ALL_ROWS 而不是 OPTIMIZER MODE=FIRST_ROWS

SET AUTOTRACE ON

SELECT
      *
FROM
      (SELECT
            /*+ FIRST_ROWS(200)*/
            *
       FROM
            BUILDING_C R
            INNER JOIN PEOPLE_C C
                ON ( R.BUILDING_ID = C.BUILDING_ID )
            INNER JOIN ROOM_C S
                ON ( S.BUILDING_ID = R.BUILDING_ID )
       WHERE
            S.OPEN_DATE >=   SYSDATE - 60 - 1
            AND S.OPEN_DATE <= SYSDATE - 60
       ORDER BY
            S.OPEN_DATE)
WHERE
      ROWNUM < 200;


Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=HINT: FIRST_ROWS (Cost=54189 Card=199 Bytes=38 K)
   1    0    COUNT STOPKEY
   2    1      VIEW (Cost=54189 Card=50 K Bytes=9 M)
   3    2        SORT ORDER BY STOPKEY (Cost=54189 Card=50 K Bytes=9 M)
   4    3          FILTER
   5    4            NESTED LOOPS
   6    5              NESTED LOOPS (Cost=52041 Card=50 K Bytes=9 M)
   7    6                MERGE JOIN (Cost=2020 Card=50 K Bytes=5 M)
   8    7                  TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.BUILDING_C (Cost=826 Card=20 M Bytes=1G)
   9    8                    INDEX FULL SCAN REALSPIRITUALS.SYS_C00504893 (Cost=26 Card=20 M)
  10    7                  SORT JOIN (Cost=1194 Card=50 K Bytes=1 M)
  11   10                    TABLE ACCESS FULL REALSPIRITUALS.ROOM_C (Cost=660 Card=50 K Bytes=1 M)
  12    6                INDEX UNIQUE SCAN REALSPIRITUALS.SYS_C00504894 (Cost=0 Card=1)
  13    5              TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.PEOPLE_C (Cost=1 Card=1 Bytes=91)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  spare statistic 3
          0  gcs messages sent
          0  db block gets from cache
          0  physical reads direct (lob)
          0  queue position update
          0  queue single row
          0  queue ocp pages
          0  HSC OLTP Compressed Blocks
          0  HSC IDL Compressed Blocks
          0  rows processed

建议：

  1. 在 OPEN_DATE 列上使用索引
  2. 如果需要加速使用并行提示 /*+ parallel (table,n) */
  3. 尝试范围分区
于 2013-11-19T10:26:56.593 回答
3

你说“改进搜索”，但是，你真的实现了这个数据模型吗？您是否尝试过一些候选查询？他们的表现是否不够好？120 万行对 Oracle 来说是微不足道的。我有几张有数十亿行的表。我认识一个拥有超过 5万亿行的分区 IOT。

首先，标准化所有内容，并测试一些候选查询。他们表现如何？如果遇到问题，是否缺少任何索引？您认为什么是足够的性能？

根据我所阅读的内容，如果您无法从具有正确索引集的规范化数据模型中获得令人满意的性能，我会感到非常惊讶。

于 2013-11-15T15:17:12.663 回答