在 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
-
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 值,以數字指定 TTL,後面接著 HOURS
或 DAYS
。表格資料列會繼承它們所在表格的 TTL 值,除非您明確設定表格資料列的 TTL 值。設定資料列的 TTL 值會覆寫表格的 TTL 值。如果您在資料列具有 TTL 值之後變更表格的 TTL 值,資料列的 TTL 值會持續存在。
您可以在資料列到達到期時間之前,隨時更新表格資料列的 TTL 值。無法再存取過期的資料。因此,使用 TTL 值比手動刪除列更有效率,因為可避免寫入資料庫日誌項目以進行資料刪除的負荷。到期資料會在到期日之後從磁碟清除。
表格狀態與生命週期
瞭解不同的表格狀態及其重要性 (表格週期處理作業)。
每個表格都會經歷一系列不同的狀態,從建立表格到刪除 (刪除)。例如,處於 DROPPING
狀態的表格無法進入 ACTIVE
狀態,而處於 ACTIVE
狀態的表格可以變更為 UPDATING
狀態。您可以透過監督表格週期來追蹤不同的表格狀態。本節說明各種表格狀態。
表格狀態 | 描述 |
---|---|
|
正在建立表格。它還無法使用。 |
|
正在更新表格。表格處於此狀態時,無法進行進一步的表格修改。 表格處於
|
|
表格可用於目前的狀態。表格可能最近建立或修改過,但是表格狀態現在穩定。 |
|
表格正在刪除中,無法供任何用途存取。 |
|
表格已被刪除,且已不存在於讀取、寫入或查詢活動。
附註: 刪除之後,可以再次建立相同名稱的表格。 |
表格階層
Oracle NoSQL Database 可讓表格存在於父項與子項關係中。這稱為表格階層。
建立表格敘述句可讓表格建立成為另一個表格的子項,然後成為新表格的父項。這是使用子項表格的複合項目名稱 (name_path) 來完成。複合項目名稱包含數字 N (N > 1) 的識別碼 (以點分隔)。最後一個 ID 是子項表格的本機名稱,第一個 N-1 ID 指向父項的名稱。
- 子項表格會繼承其父項表格的主索引鍵資料欄。
- 階層中的所有表格都有相同的分區索引鍵資料欄,這是在根表格的建立表格敘述句中指定。
- 父項表格的子項刪除之前無法刪除。
- 父項 - 子項表格不會強制實行參照完整性限制條件。
當需要某種形式的資料標準化時,您應該考慮使用子項表格。在父項 - 子項階層中寫入多筆記錄時,子項表格也可以是建立 1 到 N 關係模型時的良好選擇,同時也提供 ACID 交易語意。