Cloud BigTable 總覽

Cloud Bigtable 是一種稀疏型資料表,可以擴充到數十億資料列和數千個資料欄,讓您儲存數 TB 甚至是數 PB 的資料。每一列的單一值均經過索引;這個值又稱為資料列索引鍵。Cloud Bigtable 非常適合儲存極大量且延遲時間極短的單一索引鍵值資料。其支援短延遲時間的高讀取和寫入總處理量,也是 MapReduce 操作的理想資料來源。

應用程式可以透過多種用戶端程式庫使用 Cloud Bigtable,其中包括 Java 版 Apache HBase 程式庫。因此可以和開放源碼大數據軟體中現有的 Apache 生態系統整合在一起。

Cloud Bigtable 功能強大的後端伺服器提供超越自行代管 HBase 設備的關鍵優勢:

  • 超高擴充性。 Cloud BigTable 的擴充能力與叢集中的機器數量成正比。自行管理的 HBase 安裝設計上具有瓶頸,在達到特定門檻後效能會受到限制。Cloud BigTable 則不會遇到這個瓶頸,因此您可以擴充叢集以處理更多的讀取和寫入作業。
  • 管理簡單。 Cloud Bigtable 以透明化的方式處理升級和重新啟動,並自動維持高度的資料持久性。若要複製您的資料,只需要新增第二個叢集到執行個體,就會自動啟動複製功能。不再需要代管主機或區域;您只需要設計資料表的結構定義,其餘的就交給 Cloud Bigtable 來處理。
  • 毋需停機即可調整叢集大小。 您可以在幾個小時之內增加 Cloud Bigtable 叢集的大小,以處理巨大的負載量,然後將叢集再度縮小 ─ 這些操作全部不需停機。當您改變叢集大小後,Cloud Bigtable 在負載情況下,通常只需要幾分鐘就可以讓叢集中各節點之間的效能達到平衡。

適用場合

Cloud Bigtable 非常適合需要為非結構化的鍵/值資料提供高總處理量與可擴充性的應用,其中每一個值的大小通常不超過 10 MB。Cloud Bigtable 也是優異的儲存引擎,適用於 MapReduce 批次作業、串流處理/分析和機器學習運用。

您可以使用 Cloud Bigtable 儲存和查詢下列類型的資料:

  • 時間序列資料,例如多部伺服器在不同時間的 CPU 和記憶體使用狀況。
  • 營銷資料,例如購買歷史紀錄和消費者喜好。
  • 金融資料,例如交易歷史紀錄、股價和貨幣兌換匯率。
  • 物聯網資料,例如電錶和家用電器的使用報告。
  • 圖形資料,例如有關使用者間連接方式的資訊。

Cloud Bigtable 儲存模型

Cloud Bigtable 將資料儲存於高度可擴充的資料表中,每一資料表均為排序過的鍵/值映射。資料表由「資料列」和「資料欄」組成,通常每一資料列描述單一實體,資料欄則包含各資料列個別的值。每一資料列由單一「資料列索引鍵」進行索引,彼此關聯的資料欄通常會被分組為「資料欄系列」。每一資料欄以資料欄系列加上「資料欄限定詞」的組合來識別,這個限定詞是該資料欄系列中的唯一名稱。

每個資料列/資料欄的交集在不同的時間戳記可包含多個「儲存格」(又稱為「版本」),為我們提供已儲存資料的歷來修改變化記錄。Cloud Bigtable 資料表空間稀疏;如果一個儲存格不含任何資料,則不會佔據任何空間。

例如,假設您正在建立美國總統的社交網路,我們稱它為 Prezzy。每一位總統都可以關注其他總統的貼文。下圖的 Cloud Bigtable 資料表顯示在 Prezzy 上追蹤每一位總統正在關注的人物:

一份 Cloud Bigtable資料表,每一個使用者名稱都有一個資料列。

在本圖中有幾點值得注意:

  • 資料表包含一個資料欄系列,即 follows 系列。這個系列包含許多個資料欄限定詞。
  • 使用資料欄限定詞作為資料。 這項設計選擇充分利用了 Cloud Bigtable 資料表的稀疏性,以及新的資料欄限定詞可以即時新增的事實。
  • 使用者名稱作為資料資料列索引鍵。 假設使用者名稱在不同字母之間均勻地散佈,在整份資料表中進行資料存取應也是合理地均勻。如要瞭解 Cloud BigTable 如何處理不平衡的負載,請參閱負載平衡;如要瞭解關於挑選資料列索引鍵的進階訣竅,請參閱選擇資料列索引鍵

Cloud Bigtable 架構

下圖顯示簡化版 Cloud Bigtable 的整體架構:

Cloud Bigtable 的整體架構。

如圖所示,所有的客戶端要求會先通過一台前端伺服器,再被送到 Cloud Bigtable 節點。(在原始的 Bigtable 白皮書中,這些節點稱為「子表伺服器」)。這些節點組織成 Cloud Bigtable 叢集,隸屬於某個 Cloud Bigtable 執行個體,亦即叢集的容器。

叢集的每一個節點處理一部分對叢集的請求。在叢集中新增節點,可以增加叢集能同時處理的請求量,以及整個叢集的最大總處理量。如果您透過新增第二個叢集啟動複製功能,您也可以把不同的流量類型傳送到不同的叢集,如果其他叢集無法使用,您也可以容錯移轉到某一叢集上。

Cloud Bigtable 資料表被分割成連續資料列組成的區塊,稱為 「子表」,以協助平衡查詢的工作負載。(子表類似於 HBase 區域。) 子表係以 SSTable 格式儲存於 Google 的檔案系統 Colossus 上。SSTable 提供從鍵到值的不可變更有序映射,其中的鍵和值均為任意位元組字串。每一子表與一特定的 Cloud Bigtable 節點關聯。除了 SSTable 檔案之外,所有的寫入操作一旦被 Cloud Bigtable 認可,均儲存於 Colossus 的共享日誌中,更提高了資料的持久性。

重要的是,每個 Cloud Bigtable 節點本身一律不會儲存任何資料,而是設定了資料連結,指向一組儲存在 Colossus 的子表。因此:

  • 不同節點之間子表的重新平衡非常迅速,因為實際的資料並沒有被複製。Cloud Bigtable 只是更新了每一個節點的資料連結。
  • 故障 Cloud Bigtable 節點的復原非常迅速,因為只需要將中繼資料遷移到替代節點。
  • Cloud Bigtable 節點故障時,並不會遺失任何資料。

如要深入瞭解如何使用這些基本元素,請參閱執行個體、叢集和節點一文。

負載平衡

每一 Cloud Bigtable 區域均由一主程序管理,此程序會平衡叢集內的工作負載和資料量。主程序會將存取頻率較高、資料量較大的子表分成兩半,並將存取頻率較低、資料量較小的子表合併在一起,依需要重新分佈在各節點之間。如果某一子表遭遇尖峰流量,主程序會將該子表分成兩半,然後將其中的一個新子表移到另一個節點。Cloud Bigtable 管理所有的分割、合併,並自動重新平衡,讓使用者省下手動管理子表的精力。瞭解 Cloud Bigtable 的效能提供關於此一程序的詳細資料。

為了獲得從 Cloud Bigtable 寫入的最佳效率,盡可能將寫入操作均勻地分配給各節點是很重要的。達到這個目標的一種方法是使用不遵循可預測順序的資料列索引鍵。例如,使用者名稱往往在各字母之間大致均勻地分佈,因此將使用者名稱放在資料列索引鍵的開頭,可使寫入操作分佈地更均勻。

同時,將相關的資料列分組,使其彼此相鄰是很有用的,可以讓同時讀取數個資料列變得很有效率。例如,如果您儲存在不同時間下不同類型的氣象資料,您的資料列索引鍵可能是收集資料的地點,隨後跟著時間戳記 (例如 WashingtonDC#201803061617)。這種資料列索引鍵會把來自一個地點的資料聚集成連續的資料列範圍。對於其他地點,資料列將以不同的識別碼開頭;對於以相同速率收集資料的許多地點而言,寫入操作仍然會均勻地分佈於各子表之間。

如需有關為資料選擇合適鍵值的詳細資訊,請參閱選擇資料列索引鍵

支援的資料類型

對於大部分用途而言,Cloud Bigtable 會把所有的資料視為原始的字元組字串。 Cloud Bigtable 只有在進行增量操作時,才會嘗試決定資料類型,此時標的必須為一 64 位元的整數,且編碼成大端序 8 位元組的值。

記憶體和磁碟使用情況

下列各節描述 Cloud Bigtable 的一些組件如何影響叢集的記憶體和磁碟使用情況。

清空儲存格

Cloud Bigtable 資料表中的空白儲存格不佔據任何空間。每一資料列基本上是一組鍵/值項目,其中鍵值是資料欄系列、資料欄限定詞和時間戳記的組合。如果某一資料列不包含特定鍵的值,則鍵/值項目不會存在。

資料欄限定詞

資料欄限定詞會佔據資料列的空間,因為資料列使用的每一個資料欄限定詞均儲存於該資料列中。因此,使用資料欄限定詞作為資料通常很有效率。在上方顯示的 Prezzy 範例中,follows 系列中的資料欄限定詞是受追蹤使用者的使用者名稱;這些資料欄的鍵/值項目只是一個預留位置值。

壓縮

Cloud Bigtable 會定期重新寫入您的資料表,以移除被刪除的項目,並重新組織您的資料,使讀取和寫入更有效率。這個過程稱為壓縮。壓縮並沒有設定檔,Cloud Bigtable 會自動將您的資料壓縮。

變異和刪除操作

資料列的變異或變更操作會佔據額外的儲存空間,因為 Cloud Bigtable 會連續儲存變異操作,只偶爾會將其壓縮。Cloud Bigtable 壓縮資料表時,會移除不再需要的值。如果您更新了儲存格中的值,原始值和新的值都會儲存於磁碟上一段時間,直到資料被壓縮為止。

刪除操作也會佔據額外的儲存空間,至少短時間內是如此,因為刪除其實是一種特殊型態的變異操作。刪除操作會使用額外的儲存空間,而不是將儲存空間釋放出來,直到資料表被壓縮為止。

資料壓縮

Cloud Bigtable 使用智慧型演算法自動壓縮您的資料。您無法為您的資料配置壓縮設定值。不過,知道如何儲存資料,使其能有效率地壓縮,是很有用的:

  • 相較於規律性資料,隨機性資料的壓縮效率較低。 規律性資料包括文字內容,例如您現在所瀏覽的頁面內容。
  • 相同的值彼此靠近時,壓縮效果最理想 (不論是在同一資料列或相鄰的資料列)。如果您將鍵值安排成相同的資料區塊彼此相鄰,資料將可有效率地壓縮。

資料持久性

當您使用 Cloud Bigtable 時,會利用 Google 資料中心的儲存裝置,將您的資料儲存於 Google 內部極為耐用的檔案系統 Colossus 上。使用 Cloud Bigtable 時,不需要執行 HDFS 叢集或使用任何其他檔案系統。如果您的執行個體使用複製功能,Cloud Bigtable 會為執行個體中的叢集各建立一份複本並存放在 Colossus 中。每份複本位於不同區域或地區,可進一步提升資料的耐用性。

Google 在幕後使用獨家的儲存方法,超越了標準 HDFS 三路複製所能提供的資料持久性。此外,我們還為您的資料建立了備份,以預防災難性事件,並為災難恢復做好準備。

安全性

您的 Cloud Bigtable 資料表存取權限是由您的 Google Cloud Platform 專案,以及您指定給使用者的 Cloud 身分與存取管理角色共同控制的。例如,您可以指定 Cloud IAM 角色,防止個別使用者讀取資料表、寫入資料表或建立新的執行個體。如果某人無權存取您的專案,或不具備 Cloud Bigtable 適當權限的 Cloud IAM 角色,他將無法存取您的任何資料表。

您可以管理專案層級和執行個體層級的安全性。Cloud BigTable 不支援資料表層級、資料列層級、資料欄層級或儲存格層級的安全性限制。

其他儲存空間和資料庫選項

Cloud BigTable 並非關聯資料庫,除了無法支援 SQL 查詢或彙整作業,也不支援多資料列交易。此外,在資料量小於 1 TB 的情況下,這項服務並不是理想的解決方案。

  • 如果您需要線上交易處理 (OLTP) 系統的完整 SQL 支援,請考慮使用 Cloud SpannerCloud SQL
  • 如果您需要線上分析處理 (OLAP) 系統的交互式查詢功能,請考慮使用 BigQuery
  • 如果您需要儲存大於 10 MB 的不可變二進位大型物件 (例如大型影像或影片),請考慮使用 Cloud Storage
  • 如果您需要在文件資料庫中儲存高度結構化物件,並支援 ACID 交易和類似 SQL 的查詢功能,請考慮使用 Cloud Firestore

如要進一步瞭解其他資料庫選項,請參閱資料庫服務總覽

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Bigtable 說明文件