測試實例

創建AnalyticDB PostgreSQL版實例的具體操作，請參見創建實例。

實例規格信息如下：

• Serverless模式實例
  • Segment節點規格：4C16G
  • Segment節點數量：4個
• 存儲彈性模式實例
  • Segment節點規格：2C16G
  • Segment節點數量：4個

測試數據

生成并導入測試數據的具體操作，請參見TPC-H。

測試數據具體信息如下：

• 測試數據量：100 GB。
• 測試數據表：lineitem、orders。

  lineitem建表語法如下：

  CREATE TABLE lineitem (
      l_orderkey bigint NOT NULL,
      l_partkey integer NOT NULL,
      l_suppkey integer NOT NULL,
      l_linenumber integer NOT NULL,
      l_quantity numeric(15,2) NOT NULL,
      l_extendedprice numeric(15,2) NOT NULL,
      l_discount numeric(15,2) NOT NULL,
      l_tax numeric(15,2) NOT NULL,
      l_returnflag character(1) NOT NULL,
      l_linestatus character(1) NOT NULL,
      l_shipdate date NOT NULL,
      l_commitdate date NOT NULL,
      l_receiptdate date NOT NULL,
      l_shipinstruct character(25) NOT NULL,
      l_shipmode char(10) NOT NULL,
      l_comment varchar(44) NOT NULL
  )
  distributed by (l_orderkey) order by (l_shipdate,l_orderkey);

  orders建表語法如下：

  CREATE TABLE orders (
      o_orderkey bigint NOT NULL,
      o_custkey integer NOT NULL,
      o_orderstatus character(1) NOT NULL,
      o_totalprice numeric(15,2) NOT NULL,
      o_orderdate date NOT NULL,
      o_orderpriority character(15) NOT NULL,
      o_clerk character(15) NOT NULL,
      o_shippriority integer NOT NULL,
      o_comment character varying(79) NOT NULL
  )
  distributed by (o_orderkey) order by (o_orderdate, o_orderkey);

• 測試數據行數：lineitem表6億行，orders表1.5億行，合計7.5億行。

  lineitem和orders表均根據時間列按天均勻分布數據，lineitem表每天約有25萬行數據；orders表每天約有6萬行數據。因此示例語句中的時間范圍可以決定查詢的數據量，本次性能測試的時間范圍和數據量如下：

  • 一天，約有31萬行數據。
  • 半個月，約有466萬行數據。
  • 一個月，約有965萬行數據。

測試語句

測試語句（DELETE和UPDATE）將根據lineitem表和orders表的時間列進行批量操作，測試語句示例如下：

• DELETE語句
  • lineitem表

    DELETE FROM lineitem WHERE l_shipdate >= YYYYMMDD AND l_shipdate <= YYYYMMDD;

  • orders表

    DELETE FROM orders WHERE o_orderdate >= YYYYMMDD AND o_orderdate <= YYYYMMDD;

• UPDATE語句
  • lineitem表

    UPDATE lineitem SET l_quantity = 100.00, l_shipmode = 'test', l_comment = 'only_for_test'
    WHERE l_shipdate >= YYYYMMDD AND l_shipdate <= YYYYMMDD;

  • orders表

    UPDATE orders SET o_totalprice = 100.00, o_shippriority = 10, o_comment = 'only_for_test'
    WHERE o_orderdate >= YYYYMMDD AND o_orderdate <= YYYYMMDD;

• SELECT語句

  每次進行DELETE或UPDATE操作后，執行SELECT count(1)語句查看數據變更后的SELECT性能。

  • lineitem表

    SELECT count(1) FROM lineitem;

  • orders表

    SELECT count(1) FROM orders;

測試結果

未進行DELETE和UPDATE操作前，在lineitem表和orders表中執行SELECT count(1)語句。測試結果如下：

在Serverless模式實例和存儲彈性模式實例中并發對lineitem表和orders表執行DELETE和UPDATE操作，測試三遍，取平均值。測試結果如下：

通過以上測試結果可以得出以下信息：

• 批量執行DELETE和UPDATE時，Serverless模式實例比存儲彈性模式實例執行速度快3~20倍，批量執行的數據量越大，性能差異越明顯。

  原因：批量執行DELETE和UPDATE是根據ORDER BY進行篩選的，Serverless模式實例的表采用了行列混存加ORDER BY的存儲模式，對單列的過濾效率很高；而存儲彈性模式實例的表在對列進行過濾時，需要讀取所有數據，存在讀放大的問題，且該列的過濾不會進行二分查找，所以性能相比Serverless模式較差。

• Serverless模式實例執行SELECT count(1)比存儲彈性模式實例執行SELECT count(1)速度快4~5倍。

  原因：Serverless模式實例的表的count(1)會按照列快速進行count，而存儲彈性模式實例的表需要讀取所有數據，存在讀放大的問題。

• Serverless模式實例批量執行DELETE和UPDATE操作后再進行SELECT count(1)，性能方面幾乎無差異。

  原因：Serverless模式實例的表按照列快速進行count并從delete bitmap中快速進行數據刪除校驗，不存在讀放大的問題。