Cloud Bigtable – 完全代管的 NoSQL 資料庫服務 (二)

繼 上篇 介紹了 Cloud Bigtable 的優勢及儲存模式後，iKala Cloud 將繼續為您介紹  Cloud Bigtable 的架構。

Cloud Bigtable 架構

下圖顯示了Cloud Bigtable 整體架構的簡化版本：

如圖所示，所有客戶端的請求在發送到 Cloud Bigtable 節點前都會通過前端伺服器。（在原來的 Bigtable白皮書 中，這些節點被稱為「tablet servers」。）節點被組織成一個 Cloud Bigtable 集群，它屬於一個 Cloud Bigtable 實例，此實例即包含一個群集。在集群中的每個節點會處理部分對對集群的請求。通過向群集添加節點，你可以增加群集可以處理的請求數，和整個群集的最大吞吐量。

一個 Cloud Bigtable 表被分成幾塊連續的列，稱為 tablets，以幫助平衡查詢的工作量。（ tablets 與 HBase regions的概念類似。） tablets 以 SSTable 格式存儲在 Google 文件系統 Colossus 上。SSTable 提供了一個從鍵到值的永久儲存，經排序過，且不可改變的對照表(persistent, ordered immutable map)，其中鍵和值都是任意的字符串。每個  tablets 都與特定的 Cloud Bigtable 節點相關聯。除了SSTable 文件之外，在Cloud Bigtable 確認後，所有的寫入操作都立即儲存在Colossus 的共享日誌中，進而提高了資料的耐久性。

重要的是，資料永遠不會存儲在 Cloud Bigtable 本身的節點中; 每個節點都會指向儲存在 Colossus 上的一組 tablets 。因此：
⬩ 從一個節點到另一個節點重新平衡  tablets  的速度非常快，因為實際資料沒有被複製。Cloud Bigtable 只是更新每個節點的指針。
⬩ 當 Cloud Bigtable 故障時可以迅速復原，因為只有 metadata 需要遷移到替代的節點。
⬩ 當 Cloud Bigtable 節點故障時，不會丟失任何資料。

負載平衡

每個 Cloud Bigtable 區域都由主進程(master process) 進行管理，負責在群集間平衡工作負載和資料量。主機將較繁忙/較大的 tablets 分成兩半，並將較少訪問/較小的 tablets 合併在一起，並依需求將這些 tablets 分配到適當的節點。如果某個  tablet 遇到流量高峰，主伺服器會將tablet 分成兩部分，然後將其中一個新的 tablet 移到另一個節點。Cloud Bigtable自動管理所有拆分，合併和重新平衡，減少用戶手動管理 tablet 的時間和工作量。如果想更仔細的了解這個過程，可以參考 Cloud Bigtable Performance。

為了在 Cloud Bigtable 有最佳的寫入性能，盡可能均勻地在各個節點間分配寫入是非常重要的。實現這一目標其中一種方法是使用不符合可預測順序的列鍵。例如，只要避免 hash collisions，就可以使用字串的散列而不是實際的字串。

同時，將相關的列分組在相鄰位置也是很有用的，這樣可以同時讀取多列。例如，如果您隨時儲存不同類型的天氣資料，則您的列鍵可能是由收集資料的位置加上時間戳所組成(例如WashingtonDC#201503061617)。這種類型的列鍵可以將來自同一位置的所有資料組合在一起。對於其他位置，列會針對不同位置進行標識。 許多位置以相同的速率、寫入收集來的資料，會平均分佈在 tablets 上。

想了解更多如何挑選適當的列鍵可以閱讀 選擇列鍵 Choosing a row key。

支持的資料類型

Cloud Bigtable 將所有資料視為原始字串。Cloud Bigtable 唯一會確認類型的時候increment operations，其中目標必須是8-byte big-endian 編碼的 64-bit integer。

記憶體和和磁碟使用情況

以下的介紹將描述 Cloud Bigtable 的幾個元件會如何影響你的機器的記憶體和磁碟。

空儲存格 (Empty cells)

Cloud Bigtable 表格中的空儲存格不佔用任何空間。每列都是鍵/值的集合，其中鍵是行族、Column qualifiers 和時間戳的總合。如果一列沒有包含特別鍵值，這個鍵/值項目就不存在。

Column qualifiers

Column qualifiers 會佔用列中的儲存空間，因為在每一列使用的 Column qualifiers 會存儲在該列中。因此，通常我們會使用 Column qualifiers 作為資料。在前一篇顯示的 Prezzy 示例 中，在 follows family 裡的 Column qualifiers 是 followed users 的用戶名稱，這些行的鍵/值項目只是一個 placeholder value。

Compactions

Cloud Bigtable 會定期重寫你的表以除去已刪除的項目並重新組織資料好方便提高讀取和寫入的速度。這個過程被稱為「Compactions 」。Compactions 相關的設定不能更改 – Cloud Bigtable 會自動壓縮資料。

更動和刪除

列的突變或變化會佔用額外的儲存空間，因為 Bigtable 會依序儲存突變且只會定期壓縮它們。當 Cloud Bigtable 壓縮表格時，會刪除不再需要的值。如果在單元格中換上更新的值，原始值和更新值都會被儲存在磁碟上一段時間，直到資料被壓縮為止。

刪除也佔用額外的儲存空間，至少在短期內。因為刪除實際上是一種特殊類型的突變。在表格被壓縮之前，刪除使用額外的儲存而不是釋放出空間。

資料壓縮

Cloud Bigtable 使用智慧演算法自動壓縮資料。你無法為你的表配置壓縮設置。但是，了解如何儲存資料以便高效地壓縮資料非常有用：
⬩ 隨機資料不能像有規律的資料 (patterned data) 一樣地有效壓縮。 有規律的資料包括文字，例如你現在正在看的網頁。
⬩ 在相同的值彼此靠近時，壓縮效果最好，無論是在同一列還是在相鄰的列中。如果你使用列鍵，以便具有相同資料塊的列彼此相鄰，則可以有效地壓縮資料。

資料持久性

當你使用 Cloud Bigtable 時，你的資料會儲存在 Colossus，一個使用 Google 機房存儲設備、並被 Google 內部大量使用的文件系統中。也因此當你使用 Cloud Bigtable 時，你並不需要跑 HDFS 群集或是其他的文件系統。

Google 是使用特別的存儲方法讓資料持久性能夠高於標準的 HDFS 三向備份(three-way replication)。除此之外，Google 也提供了資料備份和災難復原的功能來應對災難性事件的發生。

安全

你可以透過雲端平台專案和身份和訪問管理（IAM）角色來控制誰能訪問你的 Cloud Bigtable 表格。透過指派 IAM roles 可以防止個別使用者讀取、寫入、建立新的機器。也就是說，如果沒有你的專案權限或是正確的 Cloud Bigtable IAM role，他們就無法訪問你的表格。

您只能在整個專案的層級控管資料安全。Cloud Bigtable 不支援 table-level、row-level、column-level 或 cell-level 的安全性限制。

Cloud Bigtable 和其他儲存選項

Cloud Bigtable 不是一個關聯式資料庫，所以它並不支援 SQL 查詢或 join，也不支援跨行交易(multi-row transaction)。也因此小於 1TB 的資料會比較不適合使用 Bigtable。
⬩ 如果你的線上交易處理（OLTP）系統需要全面的 SQL 支援，請參考 Google Cloud SQL。
⬩ 如果你需要在線上分析處理（OLAP）系統中進行交互式查詢，請參考 Google BigQuery。
⬩ 如果你需要存儲大於 10 MB 的 immutable blobs（例如大圖像或電影），請參考 Google Cloud Storage。
⬩ 如果你需要儲存高度結構化的物件，或者需要 ACID 交易和類似 SQL 查詢的支援，請參考 Cloud Datastore。

更多其他 GCP 儲存選項的資訊，請參考 選擇儲存工具 指南。

延伸閱讀

⬩ Bigtable 原始OSDI文件。
⬩ 如何使用Cloud Bigtable的示例。
⬩ Cloud Bigtable HBase client for Java。
⬩ Apache HBase。

相關文章：

上一篇：【GCP 專欄】Cloud Bigtable 的介紹與應用 (一)
(原文翻譯自：https://cloud.google.com/bigtable/docs/overview)