2.1 Greenplum 相關概念

2.1.1 整體介紹

Greenplum的架構採用了MPP(大規模並行處理)。在 MPP 系統中，每個 SMP節點也可以執行自己的作業系統、資料庫等。換言之，每個節點內的 CPU 不能訪問另一個節點的記憶體。節點之間的資訊互動是通過節點網際網路絡實現的，這個過程一般稱為資料重分配(Data Redistribution) 。與傳統的SMP架構明顯不同，通常情況下，MPP系統因為要在不同處理單元之間傳送資訊，所以它的效率要比SMP要差一點，但是這也不是絕對的，因為 MPP系統不共享資源，因此對它而言，資源比SMP要多，當需要處理的事務達到一定規模時，MPP的效率要比SMP好。這就是看通訊時間佔用計算時間的比例而定，如果通訊時間比較多，那MPP系統就不佔優勢了，相反，如果通訊時間比較少，那MPP系統可以充分發揮資源的優勢，達到高效率。

中國已有：中信實業銀行，東方航空公司，阿里巴巴，華泰保險，中國遠洋(Cosco)，李寧公司等大型企業使用者選擇Greenplum的產品。

2.1.2 shared-nothing概念

Shared Everthting:一般是針對單個主機，完全透明共享CPU/MEMORY/IO，並行處理能力差，典型的代表SQLServer。 shared-everything架構優點很明顯，但是網路，硬碟很容易就會成為系統瓶頸。

Shared Disk:各個處理單元使用自己的私有 CPU和Memory，共享磁碟系統。典型的代表Oracle Rac， 它是資料共享，可通過增加節點來提高並行處理的能力，擴充套件能力較好。其類似於SMP（對稱多處理）模式，但是當儲存器介面達到飽和的時候，增加節點並不能獲得更高的效能 。

SharedNothing:各個處理單元都有自己私有的CPU/記憶體/硬碟等，不存在共享資源，各處理單元之間通過協議通訊，並行處理和擴充套件能力更好。各節點相互獨立，各自處理自己的資料，處理後的結果可能向上層彙總或在節點間流轉。Share-Nothing架構在擴充套件性和成本上都具有明顯優勢。

2.1.3 MPP 理解

大規模並行處理系統是由許多鬆耦合處理單元組成的，藉助MPP這種高效能的系統架構，Greenplum可以將TB級的資料倉庫負載分解，並使用所有的系統資源並行處理單個查詢。

2.1.4 MVCC 概念

 與事務型資料庫系統通過鎖機制來控制併發訪問的機制不同， GPDB使用多版本控制(Multiversion Concurrency Control/MVCC)保證資料一致性。

 這意味著在查詢資料庫時，每個事務看到的只是資料的快照，其確保當前的事務不會看到其他事務在相同記錄上的修改。據此為資料庫的每個事務提供事務隔離。

MVCC以避免給資料庫事務顯式鎖定的方式，最大化減少鎖爭用以確保多使用者環境下的效能。在併發控制方面，使用MVCC而不是使用鎖機制的最大優勢是，

MVCC對查詢(讀)的鎖與寫的鎖不存在衝突，並且讀與寫之間從不互相阻塞。

2.2 OLTP與OLAP的理解

2.2.1 描述概念

Greenplum 支援OLTP與OLAP機制，同時也支援AO表與堆方式儲存，其中OLTP與OLAP的特點如下:

OLTP（On-Line Transaction Processing，聯機事務處理）系統也稱為生產系統，它是事件驅動的、面向應用的，比如電子商務網站的交易系統就是一個典型的OLTP系統。OLTP的基本特點是：

資料在系統中產生,

基於交易的處理系統（Transaction-Based）,

每次交易牽涉的資料量很小,

對響應時間要求非常高,

使用者數量非常龐大，主要是操作人員,

資料庫的各種操作主要基於索引進行。

OLAP（On-Line Analytical Processing，聯機分析處理）是基於資料倉庫的資訊分析處理過程，是資料倉庫的使用者介面部分。OLAP系統是跨部門的、面向主題的，其基本特點是：

本身不產生資料，其基礎資料來源於生產系統中的操作資料（OperationalData）

基於查詢的分析系統,

複雜查詢經常使用多表聯結、全表掃描等，牽涉的資料量往往十分龐大,

響時間與具體查詢有很大關係,

使用者數量相對較小，其使用者主要是業務人員與管理人員,

由於業務問題不固定，資料庫的各種操作不能完全基於索引進行。

2.2.2 圖示解釋

OLTP與OLAP的比較

OLTP與OLAP對於硬體的要求

2.3 其他名詞概念

2.3.1 HTAP概念

HTAP（Hybrid Transactional / Analytical Processing）

一份資料，支援線上事務與線上分析

分散式share nothing架構，線性擴充套件

3-15倍壓縮

https://yq.aliyun.com/articles/193401?utm_content=m_29900

2.3.2 Append-only 的概念

AO表為追加儲存，當刪除、更新記錄時，有一個BITMAP物件來儲存對應的記錄是否被刪除。對於AO儲存，雖然是appendonly，但實際上GP是支援DELETE和UPDATE的，被刪除或更新的行，通過BITMAP來標記，性需要用vacuum來釋放。

2.4 資料倉庫設計規則

2.4.1 資料倉庫概念

資料倉庫，英文名稱為Data Warehouse，可簡寫為DW或DWH。資料倉庫，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它是單個數據儲存，出於分析性報告和決策支援目的而建立。 為需要業務智慧的企業，提供指導業務流程改進、監視時間、成本、質量以及控制。

2.4.2 資料倉庫設計規則相關資料

具體的可以參考資料倉庫之父Bill Inmon在1991年出版的"Building the Data Warehouse"，下載地址為:連結: https://pan.baidu.com/s/1I5ImKxDv0Jbx3psqTY2TzQ 提取碼: gm8k

2.4.3 資料倉庫設計規範參考

詳細資料請參考:https://blog.csdn.net/xfg0218/article/details/85092196

2.5 常用命名規範

在資料庫中常用到表,序列,過程,觸發器,索引等的命名規範

2.5.1 表的命名規範

2.5.1.1 表的規範

1、表的命名應該簡單明瞭，禁止使用關鍵字作為表名。

2、表明應以下劃線作為作為單詞的劃分，增量表應該新增字尾的日期,例如:t_ent_baseinfo_20181024

3、同一模組的表使用相同的字首，表名含義簡單明瞭

4、表名的長度不得超過40個字元

2.5.1.2 欄位的命名規範

1、欄位使用英文單詞的全稱或簡寫，意思簡單明瞭，單詞之間以下劃線分割，禁止使用駝峰規則。

2、各表之間的相同的欄位的含義保持一致

2.5.2 索引的命名規範

索引的建立要以表明加欄位名加INDEX作為組合使用,例如:t_ent_baseinfo_pripid_index

2.5.3 函式命名規範

1、函式的名字禁止超過40個字元

2、資料處理的過程採用proc加業務的名字,例如:proc_t_ent_baseinfo_sink2hdfs該名字代表把t_ent_baseinfo表中的資料載入到HDFS上

3、公共方法採用fn加業務的名字,例如:fn_t_ent_baseinfo_convert_finled表示在表t_ent_baseinfo中轉換欄位

2.5.4 檢視命名規範

1、檢視採用v加表明加加具體的業務含義,例如:v_t_ent_baseinfo_convert_finled表示在表t_ent_baseinfo中欄位的轉換即可。

2.6 SQL使用規範

2.6.1 SQL最基本的原則

1、程式碼行清晰、整齊、層次分明、結構性強，易於閱讀。

2、程式碼中應具備必要的註釋以增強程式碼的可讀性和可維護性。

3、程式碼應充分考慮執行效率，保證程式碼的高效性。

2.6.2 避免不必要的操作

1、避免使用select * from tablename查詢資料與欄位資訊

2、 查詢記錄行的個數不要使用count(*),而要制定一個有索引的欄位

3、如果有分割槽表,儘量把分割槽鍵作為查詢的第一個條件

4、刪除表中的所有資料時，要使用truncate不要使用delete

5、查詢語句中查詢條件儘量在索引欄位上，避免做大表的掃描

6、避免在索引上進行計算,例如

低效:

SELECT * FROM DEPT WHERE SAL * 12 > 25000;

高效:

SELECT * FROM DEPT WHERE SAL > 25000 / 12;

1. 避免在索引列上使用IS NULL和IS NOT NUL,例如:

低效:(索引失效)

SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;

高效:(索引有效)

SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;