12cR1.4.3.10での変更点

Oracle NoSQL Database 12cR1.4.3.10で次の変更が行われました。

トピック

• Oracle NoSQLのSQLの新機能

• Oracle NoSQLのSQLのその他の変更点

• その他の新機能

• バグとパフォーマンスの修正

• ストレージ・エンジンの変更点(JE 7.3)

• 非推奨になった機能

Oracle NoSQLのSQLの新機能

1. JSONデータ型とJSONデータの問合せ。

   JSONは、最上位レベルの表列のデータ型、ネストしたレコード・フィールドのデータ型、または配列またはマップの要素型として使用できます。JSONは抽象型です。JSON型のフィールドに格納される実際の値には、有効なJSONのアトミック値(整数、長整数、倍精度、文字列、ブール、またはJSONのnull値)、配列またはマップがあります。値が配列/マップである場合、配列/マップの要素型もJSONになります。これは、固定スキーマの対応する配列およびマップとは異なり、JSONの配列およびマップには異種要素を含めることができることを意味します。

   入力時に、JSONデータは文字列またはテキスト・ストリームとしてOracle NoSQLに渡されます。どちらの場合も、テキストは内部的に解析され、その構成要素はマップ、配列およびアトミック値インスタンスのツリーに変換されます。JSONツリーの直接構成は、マップ、配列およびアトミック値を構成および接続するAPIを介して行うこともできます。永続ストレージの場合、ツリーはバイナリ形式にシリアライズされます。

   JSONデータは、JSON型のフィールドで異なる表の行が様々な種類の値を持つことができるという意味でスキーマレスです。たとえば、infoがJSON型の最上位レベルの表列である場合、ある行ではinfoの値が整数であり、別の行では倍精度と文字列が混在して含まれる配列であり、3番目の行では他のマップ、配列およびアトミック値が混在して含まれるマップである場合があります。さらに、JSON列またはフィールドに格納されたデータは、引き続き有効なJSONインスタンスを生成する任意の方法で更新できます。その結果、(メイン・メモリー内の、またはディスク上のシリアライズされたバイト配列としての)各JSONツリーがその内容に関して自己記述されます。

   Oracle NoSQLのSQLは、両方のデータ・モデル(以前のリリースでサポートされていた厳密な型指定のデータとスキーマレスJSONデータ)でシームレスに動作できます。表では両方のモデルのデータを混在させることができ、DML式はすべて、どちらの種類のデータでも動作できます。[#25455]

   JSONデータの索引付けはまだサポートされていません。[#25455], [#25436], [#25437], [#25727], [#25197], [#25731], [#25681], [#25683], [#25688], [#25559], [#25740], [#25629], [#25669], [#25671]

2. Oracle NoSQLのSQLでの新しい種類の式。

   • NOT演算子。ブール値を否定します。[#25455]

   • EXISTS演算子。式が少なくとも1つの値を返すかどうかを確認します。[#25455]

   • IS OF TYPE式。値または値セットにデータ型が指定されているかどうかを確認します。[#25437]

   • CAST式。可能な場合、値または値セットを、指定したデータ型にキャストします。[#25436]

   • マップ・コンストラクタ。新しいマップ値を構築します。フィールド名とフィールド値の両方が他の式で計算される場合があります。フィールド値が異種である場合があります。[#25455], [#25629]

   • CASE式。if-then-elseセマンティクスを実装します。[#25197]

   • JSON null値およびtrue/falseリテラル。問合せ内で(大文字と小文字を区別する)キーワードnull、trueおよびfalseをリテラルとして使用できます。これらは、NoSQLのSQLで予約されている唯一のキーワードです。新しいJSON null値を処理するために、必要に応じてDML演算子および式が拡張されました。[#25455], [#25731], [#25683]

3. TIMESTAMPデータ型および値。タイムスタンプはある時点を表します。これには、日付と時刻が含まれます。日付部分には、年、月および日の3つの構成要素があります。時間部分には、4つの構成要素(時間、分、秒および秒の小数部)があります。秒の小数部を表すのに使用される桁数は、タイムスタンプの精度と呼ばれ、0 (小数秒なし)から9 (ナノ秒精度)までの数値があります。タイムスタンプ型のフィールドは、索引を付けてSQL問合せでアクセスできます。SQL比較演算子はタイムスタンプを比較できるように拡張されており、キャスト演算子は適切な形式の文字列をタイムスタンプ値にキャストできます。[#24775], [#25707]

Oracle NoSQLのSQLのその他の変更点

Oracle NoSQLのSQLのいくつかの既存式は、このリリースで変更されています。ほとんどの場合、その目的は、このような式を「JSONに対応」させることにあります。これらの変更の一部は下位互換性がないため、アプリケーションでは問合せを変更する必要がある場合があります。

1. SELECT句内の暗黙的配列構成。SELECTリスト内のいずれかの式で複数の値が返される場合、これらの値を含めるために配列が構成されます。[#25455], [#25629]

2. 構文とセマンティックの両方におけるパス式での複数の変更。

   • フィールド・ステップでは、アトミック・アイテムを入力として受け入れます。入力がアトミック・アイテムである場合、フィールド・ステップでは空の結果が返されます。以前はこの場合、エラーが発生していました。[#25455], [#25688]

   • マップおよびレコードのエントリをフィルタ処理するための新しい構文。[#25455], [#25575], [#25740], [#25724]

     以前は、マップと配列の両方の値をフィルタ処理するために、角カッコ([<cond>?])が使用されていました。さらに、マップ・エントリをフィルタ処理し、(値ではなく)修飾マップ・キーを返す方法もありませんでした。最後に、レコードのエントリをフィルタ処理する方法もありませんでした。このリリースでは、.keys(<cond>?)および.values(<cond>?)パス・ステップが導入されています。これらは両方とも、主にマップとレコードを処理することが想定されています。.keys(<cond>?)は、条件を満たすマップ/レコード・エントリ(存在する場合)を選択し、これらのエントリのキー(フィールド名)を返します。.values(<cond>?)は、条件を満たすマップ/レコード・エントリ(存在する場合)を選択し、これらのエントリのフィールド値を返します。入力が配列である場合、.keys(<cond>?)と.values(<cond>?)は、配列要素に再帰的に適用されます。入力がアトミック・アイテムである場合、結果は空になります。

     DDLパスの構文はパスのDML構文のサブセットであるため、この変更はパスを使用するDDL文にも影響を与えます。最も重要なのは、CREATE INDEX文では、新規構文を使用してマップに索引付けする必要がある点です。また、TableIterator APIを介して複数キー・マップ索引に直接アクセスするアプリケーションは、索引をプローブするために作成するIndexKeyインスタンスのフィールドに名前を付けるために新しいパス構文を使用するよう更新する必要があります(または、その位置に基づいてIndexKeyフィールドにアクセスすることもできます)。

   • 配列のフィルタ処理およびスライス。配列をフィルタ処理またはスライスするために引き続き角カッコを使用します。これらは、変数$elementPosの名前が$posに変更されていること以外は、配列に対して以前と同じように機能します。ただし、4.3では、入力が配列でない場合の動作は異なります。この場合、配列はその場で作成され、入力アイテムがその配列に挿入されます。フィルタ処理/スライス・ステップは、他の配列の場合と同じようにその配列に対して動作します。[#25455], [#25575], [#25740]

3. 値比較演算子による空のオペランドの処理方法の変更。以前は、オペランドが空の結果を返した場合、比較の結果も空になりました。4.3では、両方のオペランドが空のシーケンスを返す場合、オペランドは等しいとみなされます(したがって、演算子が=、<=、>=である場合はtrueが返されます)。オペランドの1つのみが空を返す場合、演算子が!=でないかぎり、比較の結果はfalseになります。[#25763]

4. 値比較演算子による互換性のない値の処理方法の変更。以前はこの場合、エラーが返されました。4.3では、比較の結果としてfalseが返されます。[#25455], [#25681]

5. シーケンス比較演算子がSQL NULLを処理する方法の変更。以前は、オペランド・シーケンスのいずれかにNULLが含まれていた場合、これらのNULLは無視されていました。4.3では、一致するアイテムのペアが見つからず、いずれかのシーケンスにNULLが含まれる場合、比較の結果は(falseではなく) NULLになります。[#25455]

6. 配列コンストラクタの変更。4.3では、問合せにより、異種アイテムを含む配列を作成できます。また、入力式からSQL NULLが返された場合も、NULLは無視されます(作成された配列には挿入されません)。以前は、異種アイテムとNULLの両方が原因でエラーが発生しました。[#25455], [#25730], [#25629]

その他の新機能

1. <kvroot>/log/<storename>.statsおよび<kvroot>/log/<storename>.perfファイルに公開された情報は、標準のjavax.management.Notificationメカニズムを介してNoSQL JMXエージェントからも入手できます。詳細は、oracle.kv.mgmt.jmx.StorageNodeMXBeanのjavadocを参照してください。[#24979]

2. makebootconfigコマンドを使用すると、デフォルトでセキュリティが有効になるようになりました。-store-securityフラグはオプションになり、値が指定されていない場合はenableになります。このフラグの値にnoneを指定することにより、引き続き非セキュア・ストアも構成できます。また、kvliteコマンドでは、デフォルトでセキュアなストアが作成されるようになりました。-secure-config disableを指定すると、非セキュア・ストアを作成できます。[# 25440]

バグとパフォーマンスの修正

1. MapValue型でキーとして使用される文字列は、大文字と小文字が区別されるようになりました。以前は大文字と小文字が区別されておらず、これはバグでした。MapValueキーで大文字と小文字が区別されないことを想定しているアプリケーションは影響を受けることがあります。レコード値のフィールド名は、ドキュメントに記載されているように、引き続き大文字と小文字が区別されません。[#25598]

2. JSONのマップとJSONタイプの配列を使用して作成された表が正しく機能するようになりました。以前は、これらのタイプの行が作成されてもデシリアライズおよび取得できませんでした。[#25559]

3. 不要になったMapValue.putNullメソッドが削除され、MapValue、ArrayValue、RecordValueおよびFieldDefに対するメソッドが追加されました。これにより、JSONマップおよび配列に挿入するためのJSON null値を作成できるようになりました。[#25671]

4. 主キー・フィールド以外のフィールドを持つ表が作成され、主キー・フィールドのみが含まれるよう展開されたときに、表への問合せが失敗し、データが返されないという問題が修正されました。[#25766]

5. 別のレプリケーション・ノードが使用できなくなったときに、問合せを処理するレプリケーション・ノードでNullPointerExceptionが発生するという問題が修正されました。[#25792]

6. 主キー・フィールドが最初のフィールドとして宣言されていない表でReturnRowを指定したときに、ArrayIndexOutOfBoundsExceptionになるという問題が修正されました。[#25819]

7. マップ索引を作成するため、4.3より前のDDL構文との互換性を実装しました。使用可能構文には次があります。

   • 現在の構文/新しい構文であるpath-to-map.keys()およびpath-to-map.values()。

   • KEYOF(path-to-map)

   • KEYS(path-to-map)

   • ELEMENTOF(path-to-map)、path-to-map[]

   また、null値をサポートする4.2以降の索引に対して動作する4.2より前のクライアントを処理するためのコードが追加されました。[#25864]

8. kvstore-ee.jarがkvclient.jarマニフェストに追加されたため、クラスパスを修正しなくてもEnterprise Editionが動作するようになりました。これは、kvstore-ee.jarが一切存在しないCommunity Editionでも機能します。

9. 索引が存在する場合にcreate fulltext index if not existsが例外をスローするバグが修正され、正常に完了するようになりましたが、これを実行する必要はありません。[#25664]

10. 主キー・フィールドが最初のフィールドとして宣言されていない表でReturnRowを指定したときに、ArrayIndexOutOfBoundsExceptionになるという問題が修正されました。[#25819]

11. t.array[false].fieldなどのalways falseフィルタ処理ステップが実際にはalways trueステップ(t.array[false].field)として評価される問合せのバグが修正されました。[#25708]

12. 表名または表別名が問合せの残りの部分で使用されていない場合にFROM句全体が削除される問合せのバグが修正されました。このバグがあると、問合せコンパイラがArrayIndexOutOfBoundsExceptionをスローしていました。[#25768]

13. 問合せが実行された表が子表で、表別名なしで使用されるとNPEの原因となる問合せのバグが修正されました。[#25645]

14. コンパイラが式から常に空の結果を返すと推定されるときにArrayIndexOutOfBoundsExceptionが発生するという問合せのバグが修正されました。たとえば、次のような問合せによってArrayIndexOutOfBoundsExceptionがスローされていました: select id[10:0] from foo f [#25673]

15. 問合せでの列参照を解決するときに、表名の大/小文字を区別しないことが考慮されない場合がある問合せのバグが修正されました。[#25747]

16. 配列またはマップ上の索引が同じ表に存在する場合に有効なALTER TABLE文に対してIllegalCommandExceptionが発生するというバグが修正されました。[#25782]

17. ソート方向がDESCである場合に、order-by内のNULLS LASTディレクティブが無視される問合せのバグが修正されました。かわりに、この場合はエラーがスローされる必要があります。[#25785]

18. タイムスタンプ、文字列またはコンポーネントからTimestampValueを作成するためにoracle.kv.table.FieldValueFactoryクラスに新しいメソッドが追加されしました。[#25654]

    public static TimestampValue createTimestamp(Timestamp v, int precision);
    public static TimestampValue createTimestamp(String s, int precision);
    public static TimestampValue createTimestamp(int year, int month, int day,
                                                 int hour, int minute,
                                                 int second, int nano,
                                                 int precision);

    タイムスタンプ値のコンポーネントを返すためにoracle.kv.table.TimestampValueインタフェースに新しいメソッドが追加されました。

    public int getYear();
    public int getMonth();
    public int getDay();
    public int getHour();
    public int getMinute();
    public int getSecond();
    public int getNano();

19. KV 3.0からKV 4.3へのアップグレード後、要素に関する最小/最大制約が課されたマップ/配列フィールドを含む表からのレコードの読取りが失敗するというバグが修正されました。[#25799]

20. ネストされたfixed_binary、列挙またはレコード・フィールドを含む新しいフィールドを追加する際に、表の展開が失敗するという問題が修正されました。[#25793]

21. 問合せシェルの出力のデフォルトがCOLUMNからJSONに変更されました。[#25700]

22. JSONでの数値型マッピングが整数、長整数および倍精度に制限されました。これにより、JSONのオプションとして浮動小数点がなくなります。[#25699]

23. 要求されたコマンドがストア内の一部のノードでサポートされていない機能を使用する場合、これらのノードは引き続きアップグレードする必要があるため、DDLコマンドの処理時に実行するエラー・チェックが改善され、より明確なフィードバックが提供されるようになりました。[#25712]

24. 1つ以上のゾーンの型を変更するトポロジをデプロイする前に、すべてのシャードに定数があり、変更対象の各ゾーン内のほとんどのノードがオンラインであることを確認するためのチェックが追加されました。この変更では、特定のレプリケーション・ノードの現在の可用性が不足している場合に、トポロジ変更によってコマンドが失敗することが変更前に検出され、レポートされるようになります。[#24503]

25. null値不可とマークされた主キー・フィールドのために問合せでシリアライズの問題が発生し、問合せが失敗するアップグレードの問題が修正されました。主キーは暗黙的に、null値不可でありデフォルト値を持てないため、null値不可であるかデフォルト値があると明示的にマークできなくなりました。[#25533]

26. レプリケーションの実行時にレプリケーション・ノードがネットワーク・リストアを実行する必要があるときに、場合によってはOutOfMemoryErrorがスローされる原因となるメモリー・リークが修正されました。[#25649]

27. plan change-parametersおよびchange-policyコマンドを実行する際に管理CLIが新しいSNパラメータを検証する機能が改善されました。この変更により、不正なパラメータにSNの再起動を阻止させることなく、無効なSNパラメータを指定するコマンドがパラメータを変更せずに失敗するようになります。[#25636]

28. ロード・ユーティリティがセキュアなストアのセキュリティ情報をリストアすることを妨げる問題が修正されました。[#24642]

29. 冗長なデバッグ・ロギング・エントリを削減することにより、過度のロギングが原因でマスター・リバランスが正常に機能しない問題が修正されました。[#25625]

30. Hiveおよびビッグ・データSQL問合せの処理で、ある問合せのSELECT句が、次の問合せでSELECT句が指定されていないと、この問合せの動作に影響するという問題が修正されました。[#25626]

ストレージ・エンジンの変更点(JE 7.3)

1. JEの下位レベルの操作スループット統計が簡略化されて改善されました。以前は、これらの統計はCRUD操作ではなくAPIコールを表しており、単一のAPIコールで複数のCRUD操作を実行した場合に混乱が生じていました。また、一部のCRUD操作(シャード内のRNに対するキー検索操作、レプリカRNに対するすべての操作)が欠落しており、管理用の.statファイルに操作統計が含まれていませんでした。JEスループット統計はこれまで、env/je.stat.csvファイルを介してのみ参照できました。

   これで、CRUD操作を表す次の統計が管理用の.statファイルおよびenv/je.stats.cvsに出力され、レプリカを含むすべてのRNに含まれるようになりました。新しい統計は、内部的な操作または内部的な作業単位であるとみなされます。このアプローチは、内部操作をパフォーマンス測定に関連付けるために使用されます。[#23792]

       priSearch
       priSearchFail
       secSearch
       secSearchFail
       priPosition
       secPosition
       priInsert
       priInsertFail
       secInsert
       priUpdate
       secUpdate
       priDelete
       priDeleteFail
       secDelete

2. データ破損は、新しい内部JEバックグラウンド・タスクによって可能なかぎり早く検出されるようになりました。これにより、ログを順次読み取り、チェックサムを検証することで、メディアやディスクの障害が原因で発生したデータ破損が検出されます。これは、JE DbVerifyLogユーティリティを実行することと同じですが、すべてのRNに対して自動的かつ定期的に実行されます。

   デフォルトでは、検証はオンになっており、1日1回、現地時刻の午前0時に実行されます。これは通常は必要ありませんが、JE EnvironmentConfig.ENV_RUN_VERIFIER、VERIFY_SCHEDULEおよびVERIFY_LOGパラメータ(je.env.runVerifier、je.env.verifyScheduleおよびje.env.verifyLog)を使用して検証を無効にしたり検証スケジュールを変更したりできます。

   破損が検出されると、RNは停止し、SNによって自動的に再起動されなくなります。SEVEREレベルの例外はRNのログに記録され、例外メッセージにはLOG_CHECKSUMトークンが含まれます。この状況では、管理者による手動操作が必要です。最初にメディアを交換したり、シャード内の別のノードからネットワークのリストアを強制的に実行したりせずにRNを再起動することはお薦めしません。

   検証を頻繁に実行する利点は、メディアやディスクの問題が、実行しない場合よりも早く検出できることです。これは、シャード内で他のRNが稼働している間にネットワークのリストアを実行し、別の障害を受ける可能性を最小限に抑えることができることを意味します。[#25221]

3. LN (ディスク上のレコード・データを表すBツリー・リーフ・ノード)に対する反復障害読取りが排除されました。以前は、LNのディスク上のサイズが4KBを超えた場合は、ディスクからLNをフェッチするために2つの読取りが必要でした。最初の読取りには常に、正確なエントリ・サイズを含むログ・エントリ・ヘッダーが含まれ、2番目の読取り(反復読取り)はエントリ全体を読み取る必要がありました。2番目の読取りには、エントリ全体が含まれますが、通常はファイル・システムによってキャッシュされます。

   現在、LNの最終ログ・サイズがBツリーに格納され、これを使用して、読取りバッファに必要な正確なサイズを確認できるため、必要なのは単一の読取りだけになりました。この変更の利点は、次のとおりです。

   1. IOの量が削減されます(ただし、反復読取りでは通常、ファイル・システムによってキャッシュされるデータが読み取られます)

   2. 関連する反復読取りがないため、IOアクティビティについて説明している統計が分析しやすくなります。

   IN (Bツリー内部ノード)は依然として、フェッチされるときに反復読取りが発生する場合があることに注意してください。これは、INについて最後に記録されたサイズがBツリーに格納されないためです。ただし、ほとんどのアプリケーションでは、すべてのINがキャッシュされるため、キャッシュのウォームアップ時間中を除き、INがディスクから読み取られることはまれです。nRepeatFaultReads統計(EnvironmentStats.getNRepeatFaultReads)は、反復読取りの回数を示します。[#25387]

4. ネットワーク・リストア(シャード内の1つのRNから別のRNへのデータ・コピー)は、様々な理由で引き起こされることがあります。たとえば、レプリカが長期間停止した後で再起動された場合などです。以前は、ネットワーク・リストアが中断されてからRNが再起動された場合、RNが部分的なデータ・セットを操作しようとして、予期しない結果になることがありました。現在は、部分的にリストアされたRNの使用は不可能になったため、ネットワーク・リストアは自動的に再開されます。ネットワーク・リストアが中断された場合、RNのenvディレクトリには、JEによって認識および管理される0x7fffffff.jdbという名前のマーカー・ファイルが含まれます。[#25369]

5. 書込み操作の要求タイムアウトが受け入れられなくなるバグが修正されました。特定の状況下では、要求が指定されたタイムアウトを超えることがありました。[#25692]

非推奨になった機能

1. 読取り操作をマスターではなくレプリカで処理することを求めるNONE_REQUIRED_NO_MASTER (oracle.kv.Consistency.NONE_REQUIRED_NO_MASTER)の整合性ポリシーは、このリリースでは非推奨となりました。アプリケーションでは、かわりにNONE_REQUIRED一貫性ポリシーまたはKVStoreConfig.setReadZonesを使用します。