今天簡單比較一下 RDBMS, NoSQL Database, Object Storage 各自的使用情境
明天會介紹幾個常見的 NoSQL Database

上篇我們介紹了 資料保存 的一些方式, 但是對於一個系統來說, 如何讓其他服務存取 "想要的資料" 就是一個很難的問題
比如使用者驗證的服務要比對 hash 後的密碼, 就需要請求特定使用者的資料, 而 Storage Protocols 像是 SATA, NVMe, SMB 等等並沒有索引和查詢的功能, 這就牽扯到 Day 2 提到的 I/O 操作, 很花時間!
除此之外, Storage Protocols 也不支援 Concurrency (請自行查閱) 的處理

這時候就需要 Database 來優化查詢, 下面根據儲存的資料類型介紹幾種 Database

RDBMS

查詢
由於大多數 RDBMDS 是用 B+ Tree 作為索引 (Indexing) 的資料結構, 本身就有較好的查詢效率, 但是較差的寫入效率
著重資料之間的關係, 擅長處理 結構化資料, 即有 "固定格式" 的資料, 比如使用者年齡, 性別等等
一個簡單的判斷方式是 該資料是否能用 數值 或 字串 這種 primitives 表示

增刪改
更新資料時, 由於 RDBMDS 具有 ACID (Atomic, Consistency, Isolation, Durability, 請自行查閱) 特性, 所以有內建各種 "上鎖" 的機制, 比如表鎖和列鎖, 但這就犧牲了 增刪改 的效率
所以若是需要高 Concurrency 增刪改 特性的資料, 且效能是主要考量, 一致性為次要考量時, 就可以考慮改用 NoSQL Database, 比如 社群平台, 聊天平台, 電商, 遊戲排行榜 等等
一個簡單的判斷方式是 是否可以接受 "比較慢" 的資料更新 (Eventual Consistency)

常見的有 MySQL、Oracle、SQL Server, PostgreSQL

題外話
如果將圖片 base64 encode 後存起來, 從儲存的角度來說也是結構化資料; 但是從資料本身來說, 由於圖片 "本身" 沒有 "固定的格式" (metadata 不算), 所以仍然是屬於非結構化資料
聰明的你這時候肯定會想, Metadata 是否為結構化資料呢? 沒錯! Metadata 是結構化資料
所以 Metadata 將和 圖片本體 分開儲存, Metadata 可以存在 RDBMS, 圖片本身則存在 object store (或是分兩張表存), 就可以加快查詢速度

NoSQL Database

一個簡單區別 RDBMS 和 NoSQL Database 的方式: 看儲存的格式是否為 Schemaless
比如 RDBMS 的表 (Table) 需要預先定義好欄位和型別, 但是 NoSQL Database 則不需要, 我們可以動態的 增刪改 欄位

查詢
相對於 RDBMS 擅長儲存 結構化資料 和 資料間 的關係, NoSQL Database 則是專攻非結構化資料
但其實 NoSQL 也可以儲存結構化資料, 只是對於 write-heavy 操作的情境更有優勢, 而這個優勢是犧牲 ACID 換來的, 所以對於需要 ACID 保證的資料 (比如交易系統), 就不適合用 NoSQL 儲存

增刪改
由於 NoSQL 捨棄了 ACID 保證改用 Eventual Consistency, 且多為分散式架構, 所以在更新的速度比 RDBMS 快很多

常見的有 MongoDb, Redis, Amazon DynamoDB, Cassandra, InfluxDB 等等, 明天會繼續介紹

Object Storage

某方面來說 Object Storage 也算是 NoSQL 的一種, 但嚴格來說不算是 Database, 所以這邊額外獨立出來說明

Object Storage 是基於物件的存儲架構, 每個物件包括資料本體和其相關的 metadata, 類似 Linux 的 inode 架構
Object 存在 Bucket 中, 且不可修改 (Immutable), 只能更新版本

查詢
原生不支援 查詢 的功能, 可以透過 RESTful API 查詢 (如 Amazon S3), 針對大檔案或文件進行優化。Object Storage 系統設計用來處理大量非結構化資料, 如圖片, 影片, 備份, log
通常通過 RESTful API 來存取, 相較於 NoSQL Scalability 更好 (Decentralized, key-value store), 且成本更低 (更容易擴展)

增刪改
原生不支援 增刪改 的功能, 也需要透過 RESTful API, 但因為支援 multipart, streaming, 所以速度也還行

總結

要使用 RDBMS, Object Storage 還是 NoSQL Database 要根據資料特性, 資料用途 和 資料大小 決定
以下提供簡單的規則參考

資料特性

|                | 結構化 | 非結構化 |
| RDBMS          |   o   |         |
| NoSQL          |   o   |    o    |
| Object Storage |       |    o    |

資料用途

IOPS

|                | Read-heavy   | Write-heavy |
| RDBMS          |      o       |             |
| NoSQL          |      o       |      o      |
| Object Storage |      o       |      o      |

ACID
RDBMS >> NoSQL ~ Object Storage

大檔案

Object Storage >> RDBMS ~ NoSQL