Oracle NoSQL Database Cloud Serviceリファレンス
サポートされているデータ型、DDL文、Oracle NoSQL Database Cloud Serviceサービスのパラメータおよびメトリックについて学習します。
この記事には次のトピックが含まれます:
サポートされているデータ型
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データ。 |
表の状態およびライフ・サイクル
様々な表の状態とその重要度(表のライフ・サイクル・プロセス)について学習します。
それぞれの表は、表の作成から削除まで、一連の様々な状態を経過します。たとえば、DROPPING
状態の表はACTIVE
状態に移行できませんが、ACTIVE
状態の表はUPDATING
状態に変わることができます。表のライフ・サイクルをモニタリングすることにより、表の様々な状態をトラッキングできます。この項では、表の様々な状態について説明します。
表の状態 | 説明 |
---|---|
|
表は作成処理中です。使用する準備ができていません。 |
|
表の更新が進行中です。表がこの状態にある間、さらに表に変更を加えることはできません。 次の場合、表は
|
|
表は現在の状態で使用できます。表は最近作成または変更された可能性がありますが、表の状態は現在安定しています。 |
|
表は削除中であり、どのような目的でもアクセスできません。 |
|
表はすでに削除され、読取り、書込みまたは問合せのアクティビティの対象としてもう存在していません。
ノート
削除した後は、同じ名前の表をもう一度作成できます。 |
データ定義言語リファレンス
Oracle NoSQL Database Cloud ServiceでDDLを使用する方法について学習します。
Oracle NoSQL Database Cloud Service DDLを使用すると、表と索引を作成、変更および削除できます。
DDL言語の構文の詳細は、表データ定義言語ガイドを参照してください。このガイドでは、オンプレミスOracle NoSQL Database製品でサポートされているDDL言語について説明されています。Oracle NoSQL Database Cloud Serviceでは、この機能のサブセットがサポートされています。その違いについては、クラウドにおけるDDLの違いの項を参照してください。
また、各NoSQL<language>ドライバには、DDL文を実行するためのAPIが用意されています。アプリケーションを記述するには、APIを使用したOracle NoSQL Database Cloud Serviceでの表および索引の作成を参照してください。
一般的なDDL文
一般的なDDL文の例のいくつかを次に示します:
表の作成CREATE TABLE [IF NOT EXISTS] (
field-definition, field-definition-2 ...,
PRIMARY KEY (field-name, field-name-2...),
) [USING TTL ttl]
例:CREATE TABLE IF NOT EXISTS audience_info (
cookie_id LONG,
ipaddr STRING,
audience_segment JSON,
PRIMARY KEY(cookie_id))
表の変更ALTER TABLE table-name (ADD field-definition)
ALTER TABLE table-name (DROP field-name)
ALTER TABLE table-name USING TTL ttl
例:
ALTER TABLE audience_info USING TTL 7 days
索引の作成CREATE INDEX [IF NOT EXISTS] index-name ON table-name (path_list)
例:
CREATE INDEX segmentIdx ON audience_info
(audience_segment.sports_lover AS STRING)
表の削除DROP TABLE [IF EXISTS] table-name
例: DROP TABLE audience_info
完全なリストについては、リファレンス・ガイドを参照してください:
クラウドにおけるDDLの違い
クラウド・サービスのDDL言語とリファレンス・ガイドに記載されているDDL言語の違いは、次のとおりです:
表名
- 256文字以内に制限され、英数字およびアンダースコアのみ使用できます
- 文字で始める必要があります
- 特殊文字は使用できません
- 子表はサポートされていません
サポートされていない概念
DESCRIBE
およびSHOW TABLE
文。- 全文索引
- ユーザーおよびロールの管理
- オンプレミス・リージョン
問合せ計画参照
問合せ実行計画は、Oracle NoSQL Databaseが問合せを実行するために実行する一連の操作です。
問合せ実行計画は、プラン・イテレータのツリーです。各種イテレータは、問合せに表示される可能性のある異なる種類の式を評価します。一般に、索引の選択および関連する索引述語のタイプは、問合せのパフォーマンスに大きな影響を与える可能性があります。そのため、ユーザーは多くの場合、問合せで使用されている索引と、その問合せにプッシュ・ダウンされた述語を確認します。この情報に基づいて、索引ヒントを使用して別の索引の使用を強制できます。この情報は、問合せ実行計画に含まれています。すべてのOracle NoSQLドライバは、問合せの実行計画を表示するAPIを提供します。
問合せで使用される最も一般的で重要なイテレータの一部を次に示します。
- 問合せで使用される索引をスキャンしています(プライマリ索引である可能性があります)。
- 索引にプッシュされたフィルタ述語の適用
- 必要に応じて、修飾索引エントリが指す行を取得します。索引がカバーされている場合、TABLEイテレータの結果セットは索引エントリのセットであり、それ以外の場合は表の行のセットです。
索引は、その索引のエントリのみを使用して問合せを評価できる場合、問合せに関するカバー索引と呼ばれます。つまり、関連付けられた行を取得する必要はありません。
SELECTイテレータ: SELECT式を実行します。
"iterator kind" : "SELECT",
"FROM" :
{
},
"FROM variable" : "...",
"SELECT expressions" :
[
{
}
]
SELECTイテレータには、"FROM"、"WHERE"、"FROM変数"、"SELECT式などのフィールドがあります。"FROM"および"FROM変数"はSELECT式のFROM句を表し、WHEREはフィルタ句を表し、"SELECT式"はSELECT句を表します。
- RECEIVEイテレータ自体と、イテレータ・ツリーの上にあるすべてのイテレータがドライバで実行されます。
- RECEIVEイテレータの下にあるすべてのイテレータは、レプリケーション・ノード(RN)で実行されます。これらのイテレータは、RECEIVEイテレータの一意の子をルートとするサブツリーを形成します。
一般に、RECEIVEイテレータは問合せコーディネータとして機能します。サブプランが実行のために適切なRNに送信され、結果が収集されます。ソートや重複除去などの追加操作を実行し、さらに処理するために結果を祖先イテレータ(存在する場合)に伝播します。
分布の種類:
分散型は、Oracle NoSQLデータベース(ストア)に参加しているRN間で実行するために問合せを分散する方法を指定します。分散型は、RECEIVEイテレータのプロパティです。
- SINGLE_PARTITION: SINGLE_PARTITION問合せは、WHERE句で完全なシャード・キーを指定します。その結果、完全な結果セットが単一のパーティションに含まれ、RECEIVEイテレータは、そのパーティションを格納する単一のRNにそのサブプランを送信します。SINGLE_PARTITION問合せでは、主キー索引またはセカンダリ索引を使用できます。
- ALL_PARTITIONS: 問合せでは、ここで主キー索引を使用しますが、完全なシャード・キーは指定しません。その結果、ストアにMパーティションがある場合、RECEIVEイテレータは、サブプランのMコピーを送信して、各Mパーティションのいずれかに対して実行されます。
- ALL_SHARDS: 問合せではここでセカンダリ索引が使用され、完全なシャード・キーは指定されません。その結果、ストアにN個のシャードがある場合、RECEIVEイテレータはサブプランのN個のコピーを送信し、それぞれN個のシャードのいずれかに対して実行されます。
問合せ実行計画の構造:
問合せの実行はバッチで実行されます。問合せサブプランが実行のためにパーティションまたはシャードに送信されると、バッチ制限に達するまでそこで実行されます。バッチ制限は、問合せによってローカルに消費される読取りユニット数です。デフォルトは2000読取りユニット(約2MBのデータ)で、問合せレベルのオプションでのみ減らすことができます。
バッチ制限に達すると、生成されたローカル結果は、それ以上のローカル結果が使用可能かどうかを示すブール・フラグとともに、さらに処理するためにRECEIVEイテレータに戻されます。フラグがtrueの場合、応答には履歴書情報が含まれます。RECEIVEイテレータが問合せを同じパーティション/シャードに再送信することを決定した場合、リクエストにこの再開情報が含まれるため、問合せの実行は前のバッチで停止したポイントで再開されます。これは、バッチの終了後にRNで問合せ状態が維持されないためです。同じパーティション/シャードに対する次のバッチは、前のバッチと同じRNまたは同じパーティション/シャードを格納する別のRNで実行できます。