AWS Big Data Data Driven Database Google Cloud Platform

Row-Oriented 資料庫 v.s. Columnar 資料庫?

Row, 以及 Column-based 數據很直接的會影響雲端上的儲存成本以及應用端的處理效率。而且當企業在同時擁有 Row 以及 Column-based 的時候,會做很多資料的複製以及管理,沒有適當管理的話就會照成企業長期的數據債問題。

在做一些數據工程的時候,會常常聽到兩種非常不同的資料庫儲存方式一種是 Row-based 另一種是 Columnar-based。近幾年來 Columnar 的 database 也越來越受到重視,由於在數據分析的 data warehouse 時,某些情境 Columnar 的資料庫會比 Row-based 來得有效率很多。

讓我們來了解這兩個最大的差異吧!

Row-based Database

有哪些資料庫是屬於 Row-based 的資料庫呢?

  • MySQL
  • PostgreSQL
  • MSSQL

這些數據庫基本上都是 Row-based 的資料庫,以下為一個 Row-based 的儲存方式。

每一列儲存一個數據項目。所以一般 Row-based 的資料庫在儲存資料的時候存在 disk 上會長得像這樣

001:10,Smith,Joe,60000;
002:12,Jones,Mary,80000;
003:11,Johnson,Cathy,94000;
004:22,Jones,Bob,55000;

Row-based 設計上是為了很快的得到一個列的資訊,例如我可以很快地使用一個 id 去取得一列的整個資訊。

Columnar Database

有那些數據庫是 columnar 的數據庫呢?

  • Amazon Redshift
  • BigQuery

而 Columnar 的 Database 所儲存的方式就和 Row-based 非常不一樣,以下為他會在 disk 上儲存的樣式。

10:001,12:002,11:003,22:004;
Smith:001,Jones:002,Johnson:003,Jones:004;
Joe:001,Mary:002,Cathy:003,Bob:004;
60000:001,80000:002,94000:003,55000:004;

可以看到他是從一個 column 的資訊一項一項的存進來,而不是一列一列的存。

Row-based 和 Column-based 最大的不一樣是他如何儲存數據。這會使得應用在不同的情境時它的效能差異會非常大。

什麼時候應該用 Row-based DB?

一般來說,Row 的儲存方式是何在 transaction 的處理,以及常常需要獲取一個範圍的列搜尋,如果使用 Column-based 會把所有的 columns 都掃完才會到下一個欄位項目,這會造成很多不必要的數據掃描,通常這會很直接地影響到雲運算成本。

像是做網站以及 App 應用,很多時候要拉出一個客戶的資料,使用他的例如 customer_id 這時候用 Row-based Database 是個適合的選項而不是 Column-based 的數據庫。

什麼時候應該用 Column-based DB?

Column-based 的數據庫適合在數據分析的時候去使用,在某些像是欄位的掃描 max, min 時他不會像是 Row-based 要把整個 database 全部掃描完才能夠運算,這時候使用 Row-based 會造成雲運算成本大增。

還有一點就是 Column-based 所儲存的數據會把每個 column 的數據存在不同的檔案或文件中。所以通常在做資料分析的時候不需要把所有欄位的資料一次拉出來,通常會只想要針對幾個欄位的資料做數據運算。這時候使用 Column-based 的數據運算可以節省非常多的雲端數據處理以及費用,而且更快速。

資料庫正規化 v.s. 反正規化

談到 Row-based 以及 Columnar 的數據庫,通常都是會混合使用這兩個非常不同的數據庫。原因是使用的情境是完全不一樣,所以通常我們會把正規化的資料放在 Row-based 的數據庫中,而反正規化的資料放在 Columnar 數據庫中。

什麼是正規化?資料庫正規化,又稱正規化標準化,是資料庫設計的一系列原理和技術,以減少資料庫中資料冗餘,增進資料的一致性。

  1. 欄位唯一性 (Field Uniqueness)
  2. 主關鍵欄位 (Primary Key)
  3. 功能關聯性 (Function Dependence)
  4. 欄位獨立性 (Field Independence)

簡單來說就是正規化,我們希望資料庫存的資料是最一致而且有效率的儲存。所以我們在設計 MySQL 的資料庫的時候我們都會有 Primary Key, Foreign Key 把相同的數據拉開到不同的 Table 中。

反正規化則是希望把四五個不同的 Table 的資料,先把很多常用的資料做操作像是 Join 以及合併變成一個 Table ,這樣未來在做數據分析以及運算的時候不用一直在拉出很多 Table 做很昂貴的運算,而且可以針對所需要的後續分析的情境做最有效的反正規化設計,幫助未來在 Query 以及運算時會更快。

但反正規化有他的缺點,他會需要有很多重複的欄位在不同的資料集中,因為他可能會依照未來的使用做最有效的資料結構設計,而不是在儲存上最佳化。

Image result for normalization vs denormalization
Source

結論

是的,數據管理是一個很大的學問,光是 Row, 以及 Column-based 數據很直接的會影響雲端上的儲存成本以及應用端的處理效率。而且當企業在同時擁有 Row 以及 Column-based 的時候,會做很多資料的複製以及管理,沒有適當管理的話就會照成企業長期的數據債問題。

想要有效地處理數據嗎?

Canner, Inc 讓企業導入數據導向決策更簡單。Canner, Inc 所開發的 CannerFlow 是一個 Cloud-Native 的數據管理平台,解決在 Cloud Providers 上面的缺點專業人才、流程複雜、操作不易, CannerFlow 內建的數據整合系統可以節省大部分製作 ETL 流程。幫助企業導入數據分析流程更省錢快速地得到 Data-driven insights!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: