Oracle NoSQL Database Cloud Serviceリファレンス

サポートされているデータ型、DDL文、Oracle NoSQL Database Cloud Service Serviceのパラメータおよびメトリックについて学習します。

この記事には次のトピックが含まれます:

サポートされているデータ型

Oracle NoSQL Database Cloud Serviceは、多くの共通データ型をサポートしています。

データ・タイプ 説明

BINARY

0バイト以上のバイト・シーケンス。ストレージ・サイズは、バイト数とバイト配列のサイズのエンコーディング(配列のサイズに応じて変数)です。
FIXED_BINARY 固定サイズのバイト配列。このデータ型に対する追加のエンコーディング・オーバーヘッドはありません。

BOOLEAN

TRUEまたはFALSEの2つの値のいずれかを持つデータ型。ブールの記憶域サイズは1バイトです。

DOUBLE

索引キーに8バイトの記憶域を使用してエンコードされた長い浮動小数点数。主キーの場合、10バイトの記憶域が使用されます。

FLOAT

インデックスキー用に4バイトのストレージを使用してエンコードされた長い浮動小数点数。主キーの場合は、5バイトの記憶域が使用されます。

LONG

長い整数には、値に応じて1から8バイトの記憶域を使用する可変長エンコーディングがあります。主キーの場合、10バイトの記憶域が使用されます。

INTEGER

長い整数には、値に応じて1から4バイトの記憶域を使用する可変長エンコーディングがあります。主キーの場合は、5バイトの記憶域が使用されます。

STRING

ゼロ以上の一連のUnicode文字。String型はUTF-8としてエンコードされ、そのエンコーディングに格納されます。記憶域サイズは、UTF-8バイト数に長さを加えたもので、エンコーディングのバイト数に応じて1から4バイトです。インデックスキーに格納する場合、ストレージサイズは UTF-8バイト数と1つのNULL終了バイト数です。

NUMBER

任意精度符号付き小数。

順序付き比較に使用できるバイト配列形式でシリアライズされます。フォーマットには次の2つの部分があります。
  1. 符号と指数のプラス1桁。これは1 - 6バイトかかりますが、指数が非常に大きい場合を除き、通常は2です
  2. 2桁ごとに約1バイトの値の仮数

例:

12.345678 6バイトで直列化

1.234E+102は5バイトでシリアライズします

ノート:

スキーマで数値を使用する必要がある場合は、次に示す順序でデータ型を決定することをお薦めします: INTEGER、LONG、FLOAT、DOUBLE、NUMBER使用するストレージと処理能力の両方においてNUMBERはコストがかかるため、ユース・ケースで本当に必要でないかぎり、NUMBERを使用しないでください。
TIMESTAMP

精度付きの時点。精度はストレージのサイズおよび使用に影響します。タイムスタンプは、UTC (協定世界時)で格納されて管理されます。Timestampデータ型には、使用する精度に応じて3から9バイトの任意の場所が必要です。

次の内訳は、このデータ型で使用されるストレージを示しています。
  • bit[0~13]年- 14ビット
  • bit[14~17]月- 4ビット
  • bit[18~22]日- 5ビット
  • bit[23~27]時間- 5ビット[オプション]
  • bit[28~33]分- 6ビット[オプション]
  • bit[34~39]秒- 6ビット[オプション]
  • bit[40~71]小数秒[可変長のオプション]

UUID

ノート: UUIDデータ型はSTRINGデータ型のサブタイプと見なされます。記憶域のサイズは、索引キーとして16バイトです。主キーとして使用する場合、ストレージ・サイズは19バイトです。

ENUM

列挙は文字列の配列として表されます。ENUM値は記号識別子(トークン)であり、列挙内に並んだ位置を表す整数値として格納されます。

ARRAY

0つ以上の型指定されたアイテムの順序付きコレクション。JSONとして定義されていない配列にNULL値を含めることはできません。

JSONとして宣言された配列には、任意の有効なJSONを含めることができます。この中には、JSONに関連する特殊な値であるnullも含まれます。

MAP

すべてのキーが文字列で、すべてのアイテムが同じ型である、0つ以上のキーとアイテムのペアの順序なしコレクション。すべてのキーは一意である必要があります。キーとアイテムのペアはフィールドと呼ばれ、キーがフィールド名、それに関連付けられたアイテムがフィールド値です。各フィールド値は異なる型を持つことができますが、マップにNULLのフィールド値を含めることはできません。

RECORD

すべてのキーが文字列である、1つ以上のキーとアイテムのペアの固定コレクション。レコード内のすべてのキーは一意である必要があります。

JSON

任意の有効なJSONデータ。

表の状態およびライフ・サイクル

さまざまなテーブルの状態とその重要度(テーブルのライフ サイクル プロセス)について説明します。

それぞれの表は、表の作成から削除まで、一連の様々な状態を経過します。たとえば、DROPPING状態の表はACTIVE状態に移行できませんが、ACTIVE状態の表はUPDATING状態に変わることができます。表のライフ・サイクルをモニタリングすることにより、表の様々な状態をトラッキングできます。この項では、表の様々な状態について説明します。

表state.pngの説明が続きます
図表state.pngの説明

表の状態 説明

CREATING

表は作成処理中です。使用する準備ができていません。

UPDATING

表の更新が進行中です。表がこの状態にある間、さらに表に変更はできません。

次の場合、表はUPDATING状態になります:

  • 表の制限の変更中
  • 表スキーマの進化中
  • 表索引の追加または削除中

ACTIVE

表は現在の状態で使用できます。表は最近作成または変更された可能性がありますが、表の状態は現在安定しています。

DROPPING

表は削除中であり、どのような目的でもアクセスできません。

DROPPED
表はすでに削除され、読取り、書込みまたは問合せのアクティビティの対象としてもう存在していません。

ノート:

削除した後は、同じ名前の表をもう一度作成できます。

OCIコンソールでのSQL文エラーのデバッグ

OCIコンソールを使用してDDL文を使用して表を作成したり、DML文を使用してデータを挿入または更新したり、SELECT問合せを使用してデータをフェッチすると、次の一般的なシナリオのいずれかで文が不完全または障害であるというエラーが表示される場合があります。
  • SQL文の最後にセミコロンがある場合。
  • カンマの使用の誤り、文内の不要な文字の使用など、SQL文に構文エラーがある場合。
  • SQLキーワードまたはデータ型定義のSQL文にスペル・エラーがある場合。
  • 列をNOT NULLとして定義したが、DEFAULT値を割り当てていない場合。
  • 列をNOT NULLとして定義したが、DEFAULT値を割り当てていない場合。
OCIコンソールを使用してデータを作成または管理しているときに不完全または障害のあるエラーを処理する方法:
  • SQL文の最後にセミコロン(存在する場合)を削除します。
  • SQL文に不要な文字または誤った句読点があるかどうかを確認します。
  • SQL文のスペル・エラーを確認します。
  • すべての列定義が完了して正しいかどうかを確認します。
  • 表の主キーが定義されているかどうかを確認します。

前述の考えられる状況の一部を排除しても引き続きエラーが発生する場合は、クラウド・シェルを使用して問合せを実行し、次の例に示すように正確なエラーを取得できます。

例: クラウド・シェルからのSELECT文のエラー・メッセージの取得

summarizeコマンドは構文をチェックし、SQL文の簡単なサマリーを返します。
  1. OCIコンソールで、右上のメニューからクラウド・シェルを開きます。
  2. SQL SELECT文(たとえば、query1.sql)を変数(SQL_SELECTSTMT)にコピーします。
    次に例を示します:
    SQL_SELECTSTMT=$(cat ~/query1.sql | tr '\n' ' ')
  3. 次のociコマンドを起動して、SQL SELECT文の構文を確認します。

    ノート:

    このSELECT文にcompartment_idを指定する必要があります。 
    oci raw-request --http-method GET --target-uri 
https://nosql.${OCI_REGION}.oci.oraclecloud.com/20190828/query/summarize?compartmentId=$NOSQL_COMPID\
&statement="$SQL_SELECTSTMT" | jq '.data'

これにより、SQL文の正確なエラーが表示されます。

データ定義言語リファレンス

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文。
  • 全文索引
  • ユーザーとロールの管理
  • オンプレミス・リージョン

問合せ言語リファレンス

SQL文を使用したOracle NoSQL Database Cloud Serviceでのデータの更新および問合せ方法について学習します。

Oracle NoSQL Databaseでは、SQL問合せ言語を使用して、NoSQL表のデータの更新と問合せを行います。問合せ言語の構文を学習するには、Oracle NoSQL DatabaseのSQLリファレンスを参照してください。

標準的な問合せ

SELECT <expression>
FROM <table name>
[WHERE <expression>]
[GROUP BY <expression>]
[ORDER BY <expression> [<sort order>]]
[LIMIT <number>]
[OFFSET <number>]; 

For example:
SELECT * FROM Users;
SELECT id, firstname, lastname FROM Users WHERE firstname = "Taylor";
UPDATE <table_name> [AS <table_alias>]
    <update_clause>[, <update_clause>]*
WHERE <expr>[<returning_clause>];

For example:
UPDATE JSONPersons $j
  SET TTL 1 DAYS
  WHERE id = 6
  RETURNING remaining_days($j) AS Expires;

クラウドにおける問合せ言語の違い

クラウド・サービスの問合せサポートと、問合せ言語リファレンス・ガイドに記載されている内容では、次の点が異なります:

SELECT句で使用される式に関する制限

Oracle NoSQL Database Cloud Serviceでは、集計ファンクション間でのグループ化式または算術式がサポートされています。他の種類の式は、SELECT句では許可されていません。たとえば、CASE式は、SELECT句では使用できません。

各NoSQLデータベース・ドライバには、問合せ文を実行するためのAPIが用意されています。

問合せプラン参照

問合せ実行計画は、Oracle NoSQL Databaseが問合せを実行するために行う一連の操作です。

問合せ実行計画は、プラン・イテレータのツリーです。各種の反復子は、問合せに出現する様々な種類の式を評価します。通常、インデックスの選択や関連するインデックス条件の種類は、クエリーのパフォーマンスに大きく影響する可能性があります。そのためユーザーは、多くの場合、問合せで使用されている索引と、問合せにプッシュ・ダウンされている条件を確認する必要があります。この情報によっては、索引ヒントを介して異なる索引を強制的に使用する必要があります。この情報は、問合せ実行計画に含まれています。すべてのOracle NoSQLドライバに、問合せの実行計画を表示するAPIが用意されています。

問合せにおいて使用される最も一般的で重要なイテレータの一部を次に示します。

TABLE反復子: 表反復子では、次のことが実行されます。
  • クエリーで使用されるインデックスのスキャン。
  • 索引にプッシュされます。
  • 必要に応じて、条件を満たす索引エントリが指す行を取得します。インデックスがカバーである場合、TABLEイテレータの結果セットはインデックス・エントリのセットであり、それ以外の場合、それはテーブル行のセットです。

ノート:

インデックスは、そのインデックスのエントリのみを使用してクエリーを評価できる場合、つまり、関連付けられた行を取得する必要がない場合、クエリーに関するカバーインデックスと呼ばれます。

SELECTイテレータ: SELECT式を実行します。

すべての問合せにはSELECT句が含まれています。そのため、すべての問合せ計画にはSELECTイテレータがあります。SELECTイテレータの構造は次のとおりです。

"iterator kind" : "SELECT",
"FROM" :
  {
  },
"FROM variable" : "...",
"SELECT expressions" : 
[
  {
  }
]

SELECTイテレータには、FROM、WHERE、FROM変数、SELECT式などのフィールドがあります。"FROM"および"FROM変数"はSELECT式のFROM句を表し、WHEREはfilter句を表し、"SELECT式"はSELECT句を表します。

RECEIVEイテレータ:問合せ計画を2つの部分に分ける特別な内部イテレータです。
  1. RECEIVEイテレータ自体と、イテレータ・ツリー内でその上にあるすべてのイテレータがドライバで実行されます。
  2. RECEIVEイテレータの下にあるすべてのイテレータは、レプリケーション・ノード(RN)で実行されます。これらのイテレータは、RECEIVEイテレータの一意の子をルートとするサブツリーを形成します。

通常、RECEIVEイテレータは問合せコーディネータとして機能します。実行のためにサブプランを適切なRNに送信し、結果を収集します。ソートや重複削除などのその他の操作を実行し、その結果をその祖先イテレータ(存在する場合)に伝播して、さらに処理できます。

分散の種類:

分散の種別は、Oracle NoSQLデータベース(ストア)に関与するRN間で問合せを分散して実行する方法を指定します。distribution kindは、RECEIVEイテレータのプロパティです。

分散の種類の選択肢を次に示します。
  • SINGLE_PARTITION: SINGLE_PARTITION問合せでは、そのWHERE句で完全なシャード・キーを指定します。その結果、1つのパーティションにその完全な結果セットが含まれ、RECEIVEイテレータによって、そのパーティションが格納されている単一のRNにそのサブプランが送信されます。SINGLE_PARTITION問合せでは、主キー索引または2次索引のいずれかを使用できます。
  • ALL_PARTITIONS: 問合せでは、ここで主キー索引を使用し、完全なシャード・キーを指定しません。結果として、ストアにM個のパーティションがある場合、RECEIVEイテレータはそのサブプランのM個のコピーを送信して、それぞれがM個のパーティションのいずれかで実行されるようにします。
  • ALL_SHARDS: ここでは問合せで2次索引が使用され、完全なシャード・キーは指定されません。結果として、ストアにN個のシャードがある場合、RECEIVEイテレータはそのサブプランのN個のコピーを送信して、それぞれがN個のシャードのいずれかで実行されるようにします。

問合せ実行計画の構造:

問合せ実行は、複数のバッチに分けて行われます。問合せサブプランは、実行のためにパーティションまたはシャードに送信されると、バッチ制限に到達するまでそこで実行されます。バッチ制限は、問合せによってローカルに消費される読取りユニットの数です。デフォルトは読取りユニット2000個(約2MBのデータ)であり、それは、問合せレベルのオプションによってのみ減らすことができます。

バッチ制限に到達すると、生成されたローカル結果は、他にローカル結果が存在するかどうかを示すブール・フラグとともに、さらに処理するためにRECEIVEイテレータに送信されます。このフラグがtrueの場合、この応答には再開情報が含まれています。問合せを同じパーティションまたはシャードに再送信することをRECEIVEイテレータが決定した場合は、そのリクエストにこの再開情報が含まれます。それにより、問合せ実行は、前回のバッチでの停止箇所から再開されます。これは、バッチの完了後にそのRNで問合せ状態が保持されていないためです。同じパーティションまたはシャードに対する次回のバッチは、前回のバッチと同じRNで実行することも、同じパーティションまたはシャードが格納されている別のRNで実行することもできます。