在 Oracle NoSQL Database Cloud Service 中設計表格

瞭解如何在 Oracle NoSQL Database Cloud Service 中設計及設定表格。

本文包含下列主題：

資料表欄位

瞭解如何使用表格欄位設計和設定資料。

應用程式可以使用無綱要表格，其中每個資料列都由索引鍵欄位和單一 JSON 資料欄位組成。無綱要表格提供儲存於每個資料列中資料的彈性。實作無綱要資料模型的其中一個選項是 JSON 集合表格，專為將資料儲存和擷取為文件的應用程式所設計。在 JSON 集合表格中，您可以在建立表格時定義主索引鍵欄位，並在插入資料時提供其值與其他文件欄位。

或者，應用程式可以使用固定結構表，其中所有表格欄位都是以特定資料類型定義。固定綱要表格提供更佳的強制實行類型和儲存效率。雖然您可以修改其綱要，但對表格結構所做的變更會比無綱要表格更具限制性。

應用程式也可以使用混合資料模型，其中表格同時包含輸入的欄位和 JSON 資料欄位。

下列範例示範如何設計及設定所有三種方法的資料。

範例 1：設計無綱要表格

有多個選項可在您的表格中儲存瀏覽模式的相關資訊。其中一個選項是定義使用 Cookie ID 作為索引鍵的表格，並將受眾區隔資料保留為單一 JSON 欄位。

// schema less, data is stored in a JSON field
CREATE TABLE audience_info (
       cookie_id LONG,
       audience_data JSON,
       PRIMARY KEY(cookie_id))

在此情況下，audience_info 表格可以保存 JSON 物件，例如：

{
  "cookie_id": "",
  "audience_data": {
    "ipaddr" : "
10.0.00.xxx",
    "audience_segment: {
       "sports_lover" : "2018-11-30",
       "book_reader" :  "2018-12-01"
    }
  }
}

您的應用程式將會有此表格的索引鍵欄位和資料欄位。您可以靈活地將選擇的項目儲存為 audience_data 欄位中的資訊。因此，您可輕易變更可用的資訊類型。

您可以使用 JSON 收集表格將資料儲存為文件，如下所示：

CREATE TABLE audience_info ( cookie_id LONG
PRIMARY KEY(cookie_id)
) AS JSON COLLECTION

插入資料列時，您可以包含 audience_data 欄位以及任何必要的巢狀欄位。每一列代表單一文件，且可包含任意數目的 JSON 欄位。

範例 2：設計固定綱要表格

您可以使用更明確宣告的欄位來建立表格，以儲存瀏覽樣式的相關資訊：

// fixed schema, data is stored in typed fields.
CREATE TABLE audience_info(
       cookie_id LONG,
       ipaddr STRING,
       audience_segment RECORD(sports_lover TIMESTAMP(9),
                               book_reader TIMESTAMP(9)),
       PRIMARY KEY(cookie_id))

在此範例中，您的表格有一個關鍵碼欄位與兩個資料欄位。資料更精簡，而且您可以確保所有資料欄位都正確無誤。

範例 3：設計混合表格

您可以在表格中使用輸入的欄位和 JSON 資料欄位，以儲存瀏覽模式的相關資訊。

// mixed, data is stored in both typed and JSON fields.
CREATE TABLE audience_info (
       cookie_id LONG,
       ipaddr STRING,
       audience_segment JSON,
       PRIMARY KEY(cookie_id))

主索引鍵和分區索引鍵

在設計應用程式時，瞭解主索引鍵和分區索引鍵的用途。

主索引鍵和分區索引鍵是綱要中的重要元素，可協助您有效地存取和分送資料。只有在建立表格時，才會建立主索引鍵和分區索引鍵。它們在表格的存留位置中，因此無法變更或刪除。

主索引鍵

建立表格時，您必須指定一或多個主索引鍵資料欄。主索引鍵可唯一識別表格中的每個資料列。針對簡單的 CRUD 作業，Oracle NoSQL Database Cloud Service 會使用主索引鍵擷取要讀取或修改的特定資料列。例如，假設表格具有下列欄位：

• productName

• productType

• productLine

從經驗中，您知道產品名稱很重要，而且每一列都是唯一的，因此您可以將 productName 設為主索引鍵。然後，根據 productName 擷取感興趣的資料列。在此情況下，請使用類似這樣的陳述式來定義表格。

/* Create a new table called users. */
CREATE TABLE if not exists myProducts
(
  productName STRING,
  productType STRING,
  productLine INTEGER,
  PRIMARY KEY (productName)
)"

分區金鑰

分區索引鍵的主要目的是將資料分散到 Oracle NoSQL Database Cloud Service 叢集以提升效率，以及將共用分區索引鍵的記錄定位在本機，以便於參考與存取。共用分區金鑰的記錄會儲存在相同的實體位置，並能夠以原子方式有效率的方式存取。

您的主要和分區關鍵設計對於擴展和實現佈建的輸送量有影響。例如，當記錄共用分區索引鍵時，您可以在單元作業中刪除多個表格資料列，或是在單一單元作業中擷取表格中資料列的子集。除了啟用擴展性之外，設計良好的分區索引鍵還可以透過減少週期將資料放入單一分區，或從單一分區取得資料來改善效能。

例如，假設您指定三個主索引鍵欄位：

PRIMARY KEY (productName, productType, productLine)

由於您知道應用程式經常使用 productName 和 productType 資料欄進行查詢，因此將這些欄位指定為分區索引鍵是適當的。分區索引鍵指定可確保這兩個資料欄的所有資料列都儲存在相同的分區中。如果這兩個欄位不是分區索引鍵，則最常查詢的資料欄可以儲存在任何分區中。然後，要找出這兩個欄位的所有資料列，就需要掃描所有資料儲存體，而不是掃描一個分區。

分區索引鍵可指定相同分區的儲存，以便有效率地查詢索引鍵值。不過，由於您想要將資料分散到分區以獲得最佳效能，因此必須避免分區索引鍵只有少數唯一值。

注意：如果您未在建立表格時指定分區索引鍵，Oracle NoSQL Database Cloud Service 會使用分區組織的主索引鍵。

選擇分區索引鍵時要考量的重要因素

• 基數：低基數欄位 (例如使用者原產國) 會將一些分區上的記錄群組在一起。接著，這些分區需要頻繁的資料重新平衡，以增加熱分區問題的可能性。相反地，每個分區索引鍵都應該要有高基數，分區索引鍵可以在資料集中表示偶數片段的記錄。例如，customerID、userID 或 productID 等身分識別號碼是分區索引鍵的良好候選項目。

• 單元性：只有共用分區索引鍵的物件才能參與交易。如果您需要跨越多筆記錄的 ACID 異動，請選擇可讓您符合該要求的分區關鍵碼。

要遵循哪些最佳實務？

• 分區索引鍵的統一分配：分區索引鍵統一分配時，單一分區就不會限制系統的容量。

• 查詢隔離：查詢的目標應為特定分區，以最大化效率和效能。如果查詢未隔離到單一分區，查詢會套用至效率較低的所有分區，並增加查詢延遲。

請參閱建立表格，瞭解如何使用 TableRequest 物件指派主要和分區索引鍵。

存留時間

瞭解如何使用「存留時間 (TTL)」功能為表格和資料列指定到期時間。

許多應用程式會處理使用壽命有限的資料。「存留時間 (TTL)」是一種機制，可讓您在表格資料列上設定時間範圍，讓資料列自動失效且不再可供使用。資料可保留在 Oracle NoSQL Database Cloud Service 中的時間長度。達到到期時間的資料無法再擷取，也不會出現在任何儲存體統計資料中。

依預設，您建立的每個表格的 TTL 值都為零，表示沒有到期時間。當您建立表格時，可以使用數字指定 TTL，後面接著 HOURS 或 DAYS，即可宣告 TTL 值。表格資料列會繼承它們所在之表格的 TTL 值，除非您明確設定表格資料列的 TTL 值。設定資料列的 TTL 值會覆寫表格的 TTL 值。如果您在資料列具有 TTL 值之後變更表格的 TTL 值，則資料列的 TTL 值會持續存在。

在資料列到達到期時間之前，您可以隨時更新表格資料列的 TTL 值。已過期的資料無法再存取。因此，使用 TTL 值比手動刪除資料列更有效率，因為避免寫入資料庫日誌項目以進行資料刪除。到期資料會在到期日後從磁碟清除。

表格狀態與生命週期

瞭解不同的表格狀態及其重要性 (表格週期處理作業)。

每個表格都會傳遞一系列不同的狀態，從建立表格到刪除 (刪除)。例如，處於 DROPPING 狀態的表格無法繼續進行 ACTIVE 狀態，而處於 ACTIVE 狀態的表格可以變更為 UPDATING 狀態。您可以透過監督表格週期，追蹤不同的表格狀態。本節說明各種表格狀態。

table-state.png 圖解描述

表格狀態	描述
CREATING	正在建立表格。未準備好使用。
UPDATING	正在更新表格。表格在此狀態時無法進行進一步的表格修改。 當下列情況時，表格處於 UPDATING 狀態： 正在變更表格限制 表格綱要正在發展中 新增或刪除表格索引
ACTIVE	表格可以在目前的狀態中使用。表格可能最近建立或修改過，但表格狀態現在已穩定。
DROPPING	表格正在刪除中，無法供任何用途存取。
DROPPED	表格已經刪除，讀取、寫入或查詢活動已不存在。 注意：刪除之後，即可再次建立相同名稱的表格。

表格階層

Oracle NoSQL Database 可讓表格存在於父項 - 子項關係中。這稱為表格階層。

create table 敘述句允許將表格建立為另一個表格的子項，然後該表格會成為新表格的父項。這是透過使用子項表格的複合項目名稱 (name_path) 來完成。複合名稱是由數字 N (N > 1) 所組成的 ID，並以點分隔。最後一個 ID 是子項表格的本機名稱，前 N-1 個 ID 指向父項的名稱。

父項 - 子項表格的特性：

• 子項表格會繼承其父項表格的主索引鍵資料欄。

• 階層中的所有表格都有相同的分區索引鍵資料欄，在根表格的 create table 敘述句中指定。

• 父項表格無法在其子項被刪除之前刪除。

• 父項 - 子項表格中不會強制實行參照完整性限制條件。

當需要某種形式的資料標準化時，您應該考慮使用子項表格。在建立 1 到 N 關係的模型時，子項表格也可以是不錯的選擇，也會在以父項 - 子項階層撰寫多筆記錄時，提供 ACID 交易語意。

相關主題

• 雲端概念
• 使用 API 建立表格
• 使用主控台建立表格