在 Oracle NoSQL Database Cloud Service 中設計表格

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

本文包含下列主題:

資料表欄位

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

應用程式可以選擇使用無綱要表格,其中資料列是由索引鍵欄位和單一 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 欄位中的資訊。因此,您可輕易變更可用的資訊類型。

範例 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 設為主索引鍵。然後,根據 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)

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

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

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

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

要遵循哪些最佳實務?

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

存留時間

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

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

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

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

表格狀態與生命週期

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

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

表格狀態 .png 的描述如下

table-state.png 圖解描述

表格狀態 描述
CREATING 正在建立表格。未準備好使用。
UPDATING

正在更新表格。表格在此狀態時無法進行進一步的表格修改。

當下列情況時,表格處於 UPDATING 狀態:

  • 正在變更表格限制
  • 表格綱要正在發展中
  • 新增或刪除表格索引

ACTIVE 表格可以在目前的狀態中使用。表格可能最近建立或修改過,但表格狀態現在已穩定。
DROPPING 表格正在刪除中,無法供任何用途存取。
DROPPED 表格已經刪除,讀取、寫入或查詢活動已不存在。

注意:刪除之後,即可再次建立相同名稱的表格。

表格階層

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

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

父項 - 子項表格的特性:

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