文章目錄

• MPP架構數據庫優化總結——華為LibrA(MPPDB、GuassDB)
• • 1. 簡介
  • 2. 優化點
  • • 2.1 建表時選擇合適的數據類型
    • 2.2 選擇合理的存儲模型（行存和列存）
    • 2.3 選擇表的分布方式
    • 2.4 選擇合適的分區鍵
    • 2.5 創建索引，提高數據的訪問速度
    • 2.6 分析SQL執行計劃
    • 2.7 SQL編寫優化
    • 2.8 根據業務優化表設計
    • 2.9 大批量的數據導入、導出
    • 2.10 壓縮，減少空間占用
    • 2.11 使用VACUUM和ANALYZE命令定期對每個表進行維護
    • 2.12 減少數據庫存儲過程的使用
    • 2.13 結束長時間運行的SQL

MPP架構數據庫優化總結——華為LibrA(MPPDB、GuassDB)

1. 簡介

• 大數據在關系型數據處理這塊，為了能夠快速的查詢、寫入海量的數據，通常會采用MPP (Massively Parallel Processing)架構的分布式數據庫。華為LibrA(MPPDB、GuassDB)與GreenPlum正是這樣一款產品。通常實際生產環境中，每張表會存入海量的數據（例如我這里會有4TB、8TB、14TB等大小的表），為了解決這些存有海量數據的表的性能問題，需要給出很多優化方案，在這里我總結出工作中常用的一些優化手段。

2. 優化點

2.1 建表時選擇合適的數據類型

• 正確地選擇字段的數據類型可以提高效率、減小空間占用
• 例如，人的年齡沒必要使用int，可以采用TINYINT（占用1字節，范圍為0~255）
• 例如，字段長度不確定時，優先使用TEXT和VARCHAR類型，盡量不要使用CHAR，以降低存儲空間的使用。如果表中所有行該字段的長度基本一致，優先使用CHAR。

2.2 選擇合理的存儲模型（行存和列存）

• 行存表：適用于對數據需要經常更新的場景。
• 列存表： 適合數據批量插入、更新較少和以查詢為主統計分析類的場景。列存表不適合點查詢，插入單條記錄性能差。
• 如何選擇？
  • 如果更新頻繁，選擇行存
  • 如果經常點查詢，選擇行存
  • 如果經常進行聚合查詢，選擇列存
  • 經常一次插入大批量數據，選擇列存
  • 表字段較多，可以嘗試列存
  • 存儲空間有限，希望更好的壓縮數據，選擇列存

2.3 選擇表的分布方式

• 小表選擇Replication方式（例如表大小為5MB），會在每一個DataNode上存儲一份全量表數據
• 大表選擇Hash方式，會根據hash值把數據映射到對應的DataNode上
• 使用Hash分表策略時，需要選擇合理的分布列（即字段），選擇的列要具有隨機性，以保證數據均勻的分布到各個DataNode上。檢查數據是否分布均勻的SQL如下:-- 如果每個node_name對應的count相差不大，即代表分布基本均勻 SELECT a.count,b.node_name FROM (SELECT COUNT(*) AS count,xc_node_id FROM 表名 GROUP BY xc_node_id) a, pgxc_node b WHERE a.xc_node_id=b.node_id ORDER BY a.count DESC;

2.4 選擇合適的分區鍵

• 合適的分區鍵可以有效改善數據庫的查詢性能，增強可用性，方便維護，以及均衡I/O等
• 通常根據業務，我們可以按照日期對表進行分區（例如天、月）。查詢時，選擇對應的分區查詢即可，可以提高效率

2.5 創建索引，提高數據的訪問速度

• 根據業務需求選擇合理的索引字段，例如經常被用作查詢條件的字段、被要求排序的字段
• 如何選擇索引字段？
  • 經常使用WHERE子句的字段
  • 經常出現在ORDER BY、GROUP BY、DISTINCT后的字段
  • 經常進行多表連接的字段 JOIN
• 單鍵/聯合索引，滿足業務條件下，優先選擇聯合索引。如果需要創建聯合索引，應注意后續SQL中的where條件的字段（最左前綴）。
• 表的數據量較少（例如100條數據），不用創建索引-- 分區表需要在最后加上LOCAL，非分區表不用 CREATE INDEX 索引名 ON 表名 (索引字段) LOCAL;

2.6 分析SQL執行計劃

• 查看執行計劃的邏輯，檢查是否存在不合理的執行，再進行SQL優化
• 執行計劃分析內容較多，請自行百度其他數據庫的執行計劃分析，都是類似的

2.7 SQL編寫優化

• 使用索引時，應遵守最左前綴原則
• 不要在索引列上做任何操作（計算、函數等等），否則會導致索引失效
• !=、<>、IS NULL、IS NOT NULL會導致索引列失效
• OR可能會導致索引失效
• 關于like查詢，LIKE '%word%'會可能導致索引列失效，LIKE 'word%'仍能使用索引
• where中，能明確條件的，盡量少使用like模糊查詢（必須使用like時，盡量不要使用’%content%‘，應盡量使用’content%’）。如果like的是分區字段，則可以不用太在意。
• 能在where中搞定的條件，不要用having
• 執行較復雜的SQL，建議分多步執行，創建unlogged table或temp table緩存中間臨時數據（非日志表的性能比普通表有大幅度提升）
• 在實際業務中，如果2個表做union，能夠提前確定2個表沒有交集，那么建議使用union all替代union
• 2個表做Join時，小表在前、大表在后(小表驅動大表)
• 2個表Join時，盡量使用inner join，少使用left join
• 2個表Join時，如果不需要Null，請盡量加上is not null條件，對Join之前的數據進行過濾
• 做聚合分析時，可以提前做好where過濾，以減少聚合的數據量
• 查詢時不要使用SELECT * …，請直接指明所有字段名
• 針對同一個字段的多個or等于條件（name=‘xm’ or name=‘ls’ or name=‘xh’ …），請修改為in或者exist （規范：大表 in 小表，小表 exist 大表）
• 針對連續的數值條件查詢，不要使用in，盡量使用between(例如 WHERE id BETWEEN 2 AND 3)
• 對經常要查詢的SQL，創建視圖View，以方便下次直接查詢

2.8 根據業務優化表設計

• 沒有必要為了節省空間去設計多個關聯表（效率不高，大數據應該提倡以空間換時間）
• 針對經常要做統計的表，可以提前另作一個統計結果表，直接查詢該結果表既可
• 一個大表中，某個字段需要經常單獨用來去重或者判斷exist，而又不要求實時性，同時又只是一個單一的業務需要，沒有必要為其創建索引，可以每天做一次去重，單獨存一個表
• 根據實際業務需求，可以對日期進行分區。如果前臺每次默認查詢需要做一個聚合請求，在能滿足業務需求下，不要直接查全表日期的聚合，可以嘗試查近期的聚合（例如近1~2月）。因為業務方面通常也是想看近期的數據。
• 如果業務中要使用分頁類似的查詢方式，表中需要設計id。如果只使用offset，隨著表數據量的增大，會越來越慢。添加id后，可以用該語句代替：-- SELECT id,name FROM product LIMIT 20 OFFSET 100000; SELECT id,name FROM product WHERE id> 100000 LIMIT 20
• 多數業務情況下，表中應設計create_time、update_time字段，以表示該條數據的插入、更新時間，方便后續操作
• 如果一個表的業務通常是進行聚合操作，應該嘗試將該表設計為列存模式
• 利用業務需求，可以為表的字段設計二維索引（例如geohash），以做到某些特殊查詢需求

2.9 大批量的數據導入、導出

• 當業務中需要大批量的數據導入時，請不要再使用JDBC/ODBC等方式插入數據，可以使用數據庫自帶的批量導入工具。（華為LibrA可以參考LibrA批量數據導入，GreenPlum也自帶導入工具）。
• 如果要快速插入大量數據，盡量不要使用約束

2.10 壓縮，減少空間占用

• 如果系統空間不足，又無法添加新的硬件，可以考慮對表數據進行壓縮（會導致性能降低）。
• 示例，定義一個帶壓縮的列存表CREATE TABLE tb_name(code char(5),title varchar(40),did integer, ) WITH (ORIENTATION = COLUMN, COMPRESSION=HIGH);
• 列存表的有效值為YES/NO/LOW/MIDDLE/HIGH，默認值為LOW
• 行存表的有效值為YES/NO，默認值為NO

2.11 使用VACUUM和ANALYZE命令定期對每個表進行維護

• VACUUM可以回收表或B-Tree索引中已經刪除的行所占據的存儲空間（DELETE實際不會真正刪除數據）
• ANALYZE會收集與數據庫相關的統計信息，以便最有效的查詢執行計劃
• 可以嘗試每日自動對表進行維護，SQL示例如下：VACUUM ANALYZE tb_name;
• 另外可以嘗試VACUUM FULL，可以恢復更多的空間（耗時更長）

2.12 減少數據庫存儲過程的使用

• 該類型數據庫，使用存儲過程的性能并不好

2.13 結束長時間運行的SQL

• 有的SQL執行時間過長，很可能是數據庫BUG、表數據存在問題、SQL自身問題導致的，應該定期進行分析，結束掉這部分SQL
• 查詢長時間運行的SQL:SELECT current_timestamp - query_start AS runtime, datname, usename, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY 1 DESC;
• 查看語句執行的線程狀態:SELECT * FROM PG_THREAD_WAIT_STATUS WHERE db_name='db_name';
• 殺掉對應的tid的SQL語句:SELECT pg_terminate_backend(140532470773504);

總結

以上是生活随笔為你收集整理的MPP架构数据库优化总结——华为LibrA(MPPDB、GuassDB)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。