Tablestore

阿里雲Tablestore是一項基於阿里雲的 Apsara 散發式系統構建的可擴充且全託管的 NoSQL 資料存放區服務。該雲 NoSQL 資料庫服務使您能夠儲存海量結構化和半結構化的資料，同時實現即時存取、高度的一致性和單個毫秒的單行平均存取延時。

阿里雲Tablestore可將資料群組織清理到包含行和列的表格中，這些表格能夠利用資料分區和負載平衡技術快速且無縫地進行擴充。自動備份和故障檢測功能使表格服務非常可靠，靈活的資料模型使表格服務非常適合任何 IoT、遊戲、行動裝置 App、Web 和許多其他套用。

• 自動檢測故障，故障復原速度迅速。

• 服務可用工時可確保高達 99.9%。

• 多個雲資料備份，在備份發生故障時能夠快速復原。

• 服務可靠性高達 99.9999999%。

• 自動分區和基於 SSD 的技術。

• 提供卓越的處理能力：叢集中每個節點每秒處理超過 10,000 個查詢。

• 提供雲上託管的套用的無縫擴充

• 輕鬆根據即時套用託管需求來擴充預留的資源。

• 對每個要求進行身分識別驗證，以防止對 NoSQL 伺服器的未經授權的資料存取。

• 提供用戶等級的資料隔離、存取控制和權限管理機制。

• 旨在減少對 NoSQL 伺服器的 DDoS 和 CC 惡意探索的內建技術。

• 允許基於估計的資料輸送量為每個表格預留資源。

• 輕鬆根據一個套用的即時需求擴充預留的資源

• 為多種程式設計語言提供 RESTful API、基於 Web 的管理主控台和 SDK 開發包。

• 完整的產品文件，如適用於開發人員的開發人員手冊和 API 參考。

阿里雲Tablestore是一項功能強大的受管雲 NoSQL 資料庫服務，它使您能夠高速儲存和取出海量結構化和半結構化的資料，同時實現較強的讀寫一致性。

阿里雲Tablestore是一種以自動資料分區和負載平衡技術為基礎的高度可擴充的服務。該雲 NoSQL 資料庫服務非常適合需要大量記憶體和輸送量的套用（如 IoT、遊戲和行動裝置 App）。

• 自動管理資料分區、軟體和硬體升級、設定和叢集擴充。

• 使開發人員無需每天執行管理 NoSQL 資料庫的任務。

• 為大型伺服器上的多套用託管提供一致且快速的效能。

• 為任何行級資料動作提供穩定性。

• 支援套用儲存多種資料類型（包括整數、雙精確度、字元字串、二進位和布林值型）的資料。

• 允許每個資料行包括不規則數量的列，而不需要預定義表架構。

• 簡單易用的管理主控台，可用來監控資源的即時使用方式（包括每秒要求數、平均回應時延等資訊）。

• 提供詳細的表等級的監控資訊，包括資料大小、QPS、單元的讀寫能力以及 NoSQL 伺服器端平均回應時間。

Tablestore支援 5 種列值資料類型：

Tablestore從以下四個維度計量應用程式所使用的資源並收取相應的費用：資料存放區、公網流量、按量讀寫輸送量和預留讀寫輸送量。

開通Tablestore後預設根據上述計量項的實際使用量按小時計費（隨用隨付）。

該網頁價格僅作為參考，實際價格請以購買訂單網頁為準。

立即購買

Tablestore對實例的資料總量按小時計費。由於用戶的資料總量會動態變化，因此Tablestore以固定的時間間隔統計資料工作表所有分區的資料總量大小，計算每小時資料總量的平均值，將平均值乘以單價進行計費。

資料大小計費方式

Tablestore對套用存取Tablestore的外網下行流量進行收費。應用程式使用 HTTP 方式存取Tablestore返回的回應是下行流量的主要成分。即使動作失敗，Tablestore返回動作失敗資訊，也會產生下行流量。

Tablestore僅對外網下行流量收費，上行流量和通過內網存取的流量均不收費。不同 Region 間的存取也屬於外網存取。

按量讀/寫輸送量為每一秒鐘實際消耗的讀/寫輸送量中超出預留讀/寫輸送量的部份，統計周期為 1 秒。

Tablestore按照帳單周期對實例下所有表的按量讀輸送量和按量寫輸送量分別進行累加，並使用實際使用的按量輸送量的值乘以對應的單價進行計費。

按量讀輸送量說明 按量寫輸送量說明

預留讀/寫輸送量是表的一項屬性，預留讀寫輸送量能夠獲得較低的資源使用成本，為資料工作表設定合理的預留讀/寫輸送量能夠有效降低使用成本。

Tablestore對實例下所有表的預留讀/寫輸送量之和按小時計費。用戶設定的預留讀/寫輸送量可能會動態變化，Tablestore以固定的時間間隔統計表的預留讀/寫輸送量，計算每個小時的預留讀/寫輸送量的平均值，再將平均值乘以小時單價進行計費。

容量型實例不支援預留讀寫輸送量。

預留讀輸送量說明 預留寫輸送量說明

這是阿里雲的一個提供 NoSQL 資料庫服務的典型套用場景 — Tablestore針對的是外網終端使用者。在此類場景中，Tablestore將終端使用者的結構化/半結構化資料（ 如電子郵件、刊物、議程和用戶資訊）儲存在Tablestore中，以實現可隨時隨地存取的高度強固儲存。

這些類型的用例的資料量、用戶數量和存取頻率會快速增加。

推薦的設定：是必需的設定

在此類場景中，資料量多達數百兆MB的中繼資料需要儲存。每一條資料都包含多維屬性，這些屬性可能隨時增加或減少。因此，很難定義嚴格的資料模型。

整頁模式的數量也很大。查詢的數量可多達每天數萬億，最高可達 100,000 QPS，這需要時延（以毫秒計）。

對於此類場景，阿里雲Tablestore是理想的選擇，因為它可以實現一致的讀寫，在讀寫中可以進行新的記錄和更新。如今，許多套用都在使用阿里雲Tablestore，如阿里雲 MaxCompute 中繼資料（MaxCompute 表格/任務/安全和相關的中繼資料都儲存在阿里雲Tablestore中）。

此類套用託管通常會穩定地流入大量資料，並且需要持久儲存熱資料。套用一般會保留最後的資料並在最近的一段時間（如，1 個月或半年）更新，並放棄舊資料。

套用需要儲存和管理日誌和監控資料。此類套用會批量寫入阿里雲Tablestore，讀取量並不大。阿里雲 SLS 是此類用例的一個典型樣本。

存取阿里雲Tablestore CLI、阿里雲Tablestore API 和阿里雲Tablestore開發包，以管理您的資料庫。以下是所需的連結：

阿里雲管理主控台提供了一種簡單的基於 Web 的使用者介面，用於存取和設定Tablestore資源。使用此主控台，您可以建立並修改您的 NoSQL 管理的資料庫，變更所用的資源的容量，以及執行各種備份。快速入門手冊將說明您通過單擊動作來逐步執行這些任務。

阿里雲Tablestore使您能夠自由使用阿里雲Tablestore資源，並通過命令列介面 (CLI) 管理它們。您可以下載並安裝Tablestore CLI 資源套件，以啟用此服務。

您可以使用基於 Web 的阿里雲Tablestore API，輕鬆建立或修改資料庫。您可以控制存取、保護您的伺服器或實例，並通過此服務建立多個備份。此處是 阿里雲Tablestore API 指南，其中包含可用 API 的完整清單。

阿里雲Tablestore是一種以自動資料分區和負載平衡技術為基礎的高度可擴充的服務。它非常適合託管的套用，這些套用需要大量的記憶體和輸送量，如 IoT、遊戲和行動裝置 App。

使用阿里雲管理主控台和阿里雲文件，發揮阿里雲Tablestore的優勢。

以下是文件、開發包和其他資源的連結。

文件

快速入門手冊

用戶手冊

ApsaraDB for Redis

Elastic Compute Service

ApsaraDB for Memcache

雲資料庫 RDS 版

阿里雲Tablestore是阿里雲中的一項 NoSQL 管理的資料存放區服務。這項雲端式的 NoSQL 資料庫服務擁有散發式結構化和半結構化的資料模型，與支援 MySQL 和 SQL 伺服器的傳統 RDS 不同。

• Tablestore的資料模型為 2D 表，中心是行和列。但與傳統的資料庫不同的是，Tablestore的表具有不規則性，允許一行中包含不同的列。

• 在Tablestore中，可以動態新增或減少屬性列，在建立表時對於屬性列沒有嚴格的架構要求。

• 與傳統資料庫的豐富功能（如檢視、索引、交易和大量 SQL 陳述式）相比，Tablestore提供相對比較基礎的功能，但擁有較高的可擴充性，這使其可以更輕鬆地支援大量資料，如數百個 TBand 並行查詢（單個表 100,000 QPS）。

• 在編程方面，Tablestore提供統一的 HTTP Restful API，不支援傳統的 SQL 慣例。它非常靈活，使您可以僅為用於儲存和讀 寫輸送量的實際使用資源支付費用。

阿里雲Tablestore通過兩種方法確保資料的安全：

• 資料存放區的安全性，即資料可靠性。Tablestore可許諾資料可靠性高達 99.9999999%。當資料存放區到Tablestore底層時，將建立多個複本。當一份資料複本出現問題時（如資料丟失、資料崩潰等），將自動觸發修複程式以快速取代丟失的資料。這可確保Tablestore中不會遺失資料。

• 資料存取的安全性，即針對存取執行嚴格的身分識別驗證。每位用戶都需要建立 AccessKeyID 和 AccessKeySecret。AccessKeySecret 對用戶來說是保密的。用戶必須針對每個查詢要求提供正確的 AccessKeyID 作為簽章，Tablestore將驗證每個查詢要求的 AccessKeySecrect。只有通過了驗證，才能執行後續動作。

否。Tablestore支援半結構化表格，也就是說，在建立表格時，只有主鍵列（第 1 列至第 4 列）是必須要建立的，而屬性列不是必須要建立的。Tablestore中可以包含多個屬性列（屬性列個數沒有節流），每行資料都可以有不同數量的屬性列。當套用寫入資料時，Tablestore需要指定所有資料列（主鍵列和屬性列）的名稱和值。

當表格式資料大小達到設定值後，Tablestore將根據分區鍵列中的一系列值對錶格進行分區，以實現負載平衡。

建立表格時，預設情況下表格擁有一個分區 — 所有資料都位於表格的相同分區上。當表格擁有多個分區時，各個分區中的資料屬於分區鍵列中某個特定範圍的值。分區鍵列中的所有值根據列值的自然順序（即整數或字元字串（主鍵列中的資料類型）的自然順序）進行分割。

除了查詢效能，分區還將影響預留讀寫吞吐率。當表格中有多個分區時，預留讀寫輸送量將根據各個分區進行配比。

建立表格時，分區鍵的選擇非常重要，因為它將影響資料量過大時的查詢效能。為套用選擇分區鍵時，用戶應該遵循以下基本準則：

• 不要使用具有定值的或者值範圍小的屬性，例如用戶性別（男/女）。

• 避免按自然順序排序後擁有明顯的查詢熱點的屬性，如將 TimeStamp 用作分區鍵以查詢最後的資料場景。

• 使用按自然順序排序後擁有分散的查詢熱點的屬性，如 UserID。

阿里雲建議根據套用特點引入分區鍵前，對資料進行散列。例如，當寫入一行資料後，使用簡單的散列演算法為 UserID 生成一個散列值，然後將散列值與 UserID 拼接起來，並在表中將它們另存新檔分區鍵值。這種輕鬆的方法可以有效解決某些查詢熱點問題。但是請記住，由於分區鍵值是根據拼接的散列值和實際值得出的，因此套用將不能讀取帶有分區鍵的範圍 (getRange)。

每個Tablestore用戶最多可以建立十個實例，每個實例最多可擁有64個表格，即，每個Tablestore用戶在一個帳號下最多可建立 640 個表格。

傳統的 SQL 資料庫（如 MySQL）解決的是資料庫切分和表分區的海量資料存取，而Tablestore與此不同，它採用散發式方法並破解巨大的資料量和存取時延的瓶頸。用戶可以將結構化或半結構化資料儲存在一個稀疏表（稀疏表是一種資料結構，通常在遇到不可變資料的情況下用於代替線段樹）中，而不必擔心在資料量巨大時的查詢效能。

由於Tablestore具有散發式特徵，因此表格數量也會成為一種資源屬性。為了實現服務資源的可控性，一個帳號下的表格數量有最大值節流，但Tablestore的可擴充性可有效地解決表格數量的節流問題。

如果您仍然需要增加一個帳號下的表格的限額，您可以開啟一個工單或聯繫您的客戶經理。