表の設計
Oracle NoSQL Database Cloud Serviceで表を設計および構成する方法について学習します。
表
表は行のコレクションで、各行にデータ・レコードが保持されます。各表の行は、表の作成時に定義されたキー・フィールドとデータ・フィールドで構成されます。また、表にはストレージが指定されており、定義された最大読取りおよび書込みスループットをサポートできます。最大サイズも設定されています。
Oracle NoSQL Database Cloud Serviceで表を設計する前に、次の概念について学習します:
-
表フィールド: 表は、表に使用されるデータ型と主キーを定義するDDL (データ定義言語)を使用して作成します。Oracle NoSQL Database Cloud Serviceでは、いくつかの数値型、文字列、バイナリ、タイムスタンプ、マップ、配列、レコード、および有効なJSONデータを保持できる特殊なJSON型を含む、複数のデータ型をサポートしています。アプリケーションでは、データ・モデルに基づいて表フィールドのデータ型を選択できます。Oracle NoSQL Database Cloud Serviceでサポートされているデータ型の完全なリストは、サポートされているデータ型を参照してください。
表フィールドについてさらに学習するには、表フィールドを参照してください。
-
主キーとシャード・キー: すべての表には、主キーとして指定された1つ以上のフィールドが必要です。この指定は表の作成時に行われ、表の作成後は変更できません。主キーは、表のすべての行を一意に識別します。最も単純なケースでは、調査または変更するために、主キーを使用して特定の行を取得します。
シャード・キーは、シャード・ストレージの観点から意味のある主キー・フィールドを識別します。つまり、すべてのシャード・キーに対して同じ値を含む行は、必ず同じシャードに格納されます。このシャード・ストレージは、結果のアトミック性を保証する一部の操作で重要になります。
さらに学習するには、主キーとシャード・キーを参照してください。
-
索引: 索引は、表の行を取得するための代替手段を表します。通常、表の行は主キーを使用して取得します。索引を作成することにより、主キーに含まれないフィールドに基づいて行をより効率的に取得できます。索引を使用すると問合せ能力は高くなりますが、ストレージ・リソースとスループット・リソースの両方が消費されます。
索引の作成方法について学習するには、表および索引の作成を参照してください。
-
容量: 表を作成するときに、その表に使用可能なスループットとストレージ・リソースも指定します。表に対する読取りおよび書込み操作は、定義した読取りおよび書込みスループット容量によって制限されます。表で使用できる領域は、ストレージ容量によって制限されます。
表に指定する必要がある容量を見積る方法の詳細は、容量の見積りを参照してください。
表の容量を処理する方法について学習するには、容量の処理を参照してください。
-
存続時間(TTL): 存続時間によって、表の行を自動的に期限切れにできます。TTLは、表のデータが存続できる時間で表されます。有効期限のタイムアウト値に達したデータは取得できなくなり、どの読取り操作にも表示されません。
さらに学習するには、存続時間を参照してください。
- アイデンティティ列: アイデンティティ列は、Oracle NoSQL Database Cloud Serviceによって自動的に割り当てられる値を取得する特殊なタイプの列です。これらの値は順序ジェネレータから生成されます。アイデンティティ列は、NoSQL Database Cloud Serviceコンソールからはサポートされません。アイデンティティ列の詳細は、Oracle NoSQL DatabaseのSQLリファレンスのアイデンティティ列を参照してください。Oracle NoSQL Database Cloud Serviceアプリケーションからアイデンティティ列にアクセスする方法を学習するには、NoSQLデータベース表Javaドライバのスタート・ガイドのIDENTITY値のプログラムによる挿入を参照してください。
-
表のライフ・サイクル: 表が作成、変更または削除されるとき、表のライフ・サイクルは様々な状態を遷移します。
表のライフ・サイクルについて学習するには、表の状態およびライフ・サイクルを参照してください。
サポートされているデータ型
Oracle NoSQL Database Cloud Serviceは、多くの共通データ型をサポートしています。
データ型 | 説明 |
---|---|
|
0バイト以上のバイト・シーケンス。 |
FIXED_BINARY |
固定サイズのバイト配列。 |
|
使用可能な2つの値( |
|
64ビット(8バイト)の長精度浮動小数点数。 |
|
32ビット(4バイト)の長精度浮動小数点数 |
|
64ビット( 8バイト)の長整数。 |
|
32ビット(4バイト)の長整数。 |
|
一連のUnicode文字。 |
|
任意精度符号付き10進数。 |
|
精度付きの時点。精度はストレージのサイズおよび使用に影響します。タイムスタンプは、UTC (協定世界時)で格納されて管理されます。 |
|
文字列の配列として表される列挙。 |
|
0個以上の型指定されたアイテムの順序付きコレクション。JSONとして定義されていない配列に JSONとして宣言された配列には、任意の有効なJSONを含めることができます。この中には、JSONに関連する特殊な値であるnullも含まれます。 |
|
すべてのキーが文字列で、すべてのアイテムが同じ型である、ゼロまたはそれ以上のキーとアイテムのペアの順序なしコレクション。すべてのキーは一意である必要があります。キーとアイテムのペアはフィールドと呼ばれ、キーがフィールド名、それに関連付けられたアイテムがフィールド値です。各フィールド値は異なる型を持つことができますが、マップにNULLのフィールド値を含めることはできません。 |
|
すべてのキーが文字列である、1つ以上のキーとアイテムのペアの固定コレクション。レコード内のすべてのキーは一意である必要があります。 |
|
任意の有効なJSONデータ。 |
表フィールド
表フィールドを使用してデータを設計および構成する方法について学習します。
アプリケーションでは、行がキー・フィールドと単一のJSONデータ・フィールドで構成されるスキーマレス表を使用するように選択できます。スキーマレス表は、何を行に格納できるかという点で柔軟性があります。
また、アプリケーションでは、すべての表フィールドが特定の型として定義された固定スキーマ表を使用するように選択することもできます。
強制的に適用されることと、ストレージの効率という観点から、型指定されたデータからなる固定スキーマ表がより安全です。固定スキーマ表のスキーマは変更できますが、その表の構造は簡単には変更できません。スキーマレス表は柔軟性があり、表構造を簡単に変更できます。
最後に、アプリケーションでは、表に型指定されたデータとJSONデータ・フィールドを含めることができるハイブリッド・データ・モデルのアプローチを使用することもできます。
次の各例では、3つすべてのアプローチを使用してデータを設計および構成する方法を示します。
例1: スキーマレス表の設計
パターンの参照に関する情報を表に格納する場合、複数のオプションがあります。オプションの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"
}
}
}
アプリケーションは、この表に対して1つのキー・フィールドと1つのデータ・フィールドを持つことになります。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));
この例では、表は1つのキー・フィールドと2つのデータ・フィールドを持ちます。データはよりコンパクトになり、すべてのデータ・フィールドが正確であることを保証できます。
例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));
主キーとシャード・キー
アプリケーション設計中の主キーとシャード・キーの目的について学習します。
主キーおよびシャード・キーは、スキーマの重要な要素で、効率的なデータへのアクセスおよびデータの分散に役立ちます。主キーとシャード・キーを作成するのは、表を作成するときのみです。表の存続期間中はそのまま残り、変更や削除はできません。
主キー
表を作成するときには、1つ以上の主キー列を指定する必要があります。主キーは、表のすべての行を一意に識別します。単純な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クラスタ全体にデータを分散し、参照やアクセスが簡単になるようにシャード・キーをローカルで共有するレコードを配置することです。シャード・キーを共有するレコードは同じ物理的ロケーションに格納され、アトミックかつ効率的にアクセスできます。
主キーとシャード・キーの設計は、プロビジョニングされたスループットのスケーリングと実現に影響を与えます。たとえば、レコード間でシャード・キーを共有している場合、1回のアトミック操作で複数の表の行を削除したり、1回のアトミック操作で表の行のサブセットを取得することができます。適切に設計されたシャード・キーは、スケーラビリティを実現できるだけでなく、データの適用に必要なサイクル数を減らすことでパフォーマンスを改善したり、単一のシャードからデータを取得することができます。
たとえば、次の3つの主キー・フィールドを指定したとします:
PRIMARY KEY (productName, productType, productLine)
アプリケーションでproductName
列とproductType
列を使用した問合せが頻繁に行われることがわかっているため、これらのフィールドはシャード・キーとして指定することが適切です。シャード・キーの指定によって、この2つの列に対するすべての行は必ず同じシャードに格納されます。この2つのフィールドをシャード・キーにしないで、問合せ頻度が最も高い列を任意のシャードに格納することもできます。この場合、両方のフィールドのすべての行を検索するのに、1つのシャードではなくすべてのデータ・ストレージをスキャンする必要があります。
表の作成時にシャード・キーを指定しない場合、Oracle NoSQL Database Cloud Serviceではシャード編成に主キーが使用されます。
シャード・キーの選択時に考慮する重要な要因
-
カーディナリティ: カーディナリティが低いフィールド(ユーザーの国など)では、レコードが数個のシャード上にまとめられます。これらのシャードには頻繁にデータ・リバランスを行う必要があるため、ホット・シャードの問題が発生する可能性が高くなります。一方、各シャード・キーのカーディナリティが高い場合、シャード・キーはデータ・セット内のレコードの均一なスライスを表すことができます。たとえば、
customerID
、userID
、productID
などのID番号は、シャード・キーの候補として適しています。 -
アトミック性: シャード・キーを共有するオブジェクトのみがトランザクションに参加できます。複数のレコードにわたるACIDトランザクションが必要な場合は、その要件を満たすことができるシャード・キーを選択します。
ベスト・プラクティスは何か
-
シャード・キーの均一分散: シャード・キーが均等に分散されている場合、1つのシャードによってシステムの容量が制限されることはありません。
-
問合せの分離: 効率とパフォーマンスを最大限にするために、問合せのターゲットを特定のシャードに限定する必要があります。問合せが単一のシャードに分離されていない場合、問合せはすべてのシャードに適用されるため、効率が低下し、問合せレイテンシも増加します。
TableRequest
オブジェクトを使用して主キーとシャード・キーを割り当てる方法について学習するには、表および索引の作成を参照してください。
存続時間
存続時間(TTL)機能を使用して表および行の有効期限を指定する方法について学習します。
多くのアプリケーションでは、限定的な存続期間が設定されたデータが処理されます。存続時間(TTL)は、表の行に対する時間枠を設定できるメカニズムであり、その時間を経過すると行は自動的に期限切れになり、使用できなくなります。これは、データがOracle NoSQL Database Cloud Service内に存在できる期間です。有効期限に達したデータは取得できなくなり、どのストレージ統計にも表示されません。
デフォルトでは、作成するすべての表に、有効期限がないことを示す0のTTL値が設定されます。TTL値を宣言するには、表を作成するときに、数値でTTLを指定し、その後にHOURS
またはDAYS
を指定します。表の行に明示的にTTL値を設定しないかぎり、表の行はその表のTTL値を継承します。行のTTL値を設定すると、表のTTL値がオーバーライドされます。行のTTL値がすでにある場合に表のTTL値を変更すると、行のTTL値が残ります。
表の行のTTL値は、行が有効期限に達するまでいつでも更新できます。期限切れのデータにはアクセスできなくなります。したがって、TTL値を使用すると、データ削除のためにデータベース・ログ・エントリを書き込むオーバーヘッドを回避できるため、手動で行を削除するよりも効率的です。期限切れのデータは、有効期限後にディスクからパージされます。
表の状態およびライフ・サイクル
様々な表の状態とその重要度(表のライフ・サイクル・プロセス)について学習します。
それぞれの表は、表の作成から削除まで、一連の様々な状態を経過します。たとえば、DROPPING
状態の表はACTIVE
状態に移行できませんが、ACTIVE
状態の表はUPDATING
状態に変わることができます。表のライフ・サイクルをモニタリングすることにより、表の様々な状態をトラッキングできます。この項では、表の様々な状態について説明します。
表の状態 | 説明 |
---|---|
|
表は作成処理中です。使用する準備ができていません。 |
|
表の更新が進行中です。表がこの状態にある間、さらに表に変更を加えることはできません。 次の場合、表は
|
|
表は現在の状態で使用できます。表は最近作成または変更された可能性がありますが、表の状態は現在安定しています。 |
|
表は削除中であり、どのような目的でもアクセスできません。 |
|
表はすでに削除され、読取り、書込みまたは問合せのアクティビティの対象としてもう存在していません。
ノート
削除した後は、同じ名前の表をもう一度作成できます。 |