25.1.13での変更点

Oracle NoSQL Databaseリリース25.1.13 Enterprise Editionでは次の変更が行われました。

トピック

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

新機能

1. 同じ表階層内の表間の内部結合がサポートされるように、Oracle NoSQLのSQL言語が拡張されました。同じ階層内の2つ以上の表を問合せで結合できます。階層内の表の位置に制限はありません。自己結合(その表自体との結合)も可能です。ただし、分散結合(一致する行が別のシャードに配置されている可能性がある結合)を回避するために、次の制限が適用されます:

   結合述語には、結合される表のすべてのシャード・キー列間の等価述語を含める必要があります。具体的には、結合される表のペアで、一方の表の行がもう一方の表の行と一致するのは、2つの行のシャード・キー列の値が同じ場合のみです。これにより、2つの行が同じレプリケーション・ノードにあることが保証されます。

   この機能の例については、次を参照してください。結合問合せの例をいくつか示すために、(単純な)電子メール・アプリケーションをモデル化する次の表を使用します:

   create table users(uid integer, user_info json, primary key(uid))

   create table users.messages(msgid integer, msg_info json, primary key(msg_id))

   create table users.inbox(msgid integer, primary key(msgid))

   create table users.sent(msgid long, primary key(msgid))

   create table users.deleted(msgid long, primary key(msgid))

   users表には、各ユーザー・アカウントの情報が格納されます。users.messages表はusersの子表であり、各ユーザーから送受信された各メッセージを格納します。その他の3つの表もusersの子であり、各種のEメール・フォルダをモデル化しています。対応するフォルダに属するメッセージのメッセージ主キー(uidおよびmsgid)が格納されます。すべての表は、同じシャード・キー列(つまりuid列)を共有しています。ユーザー行の例と関連するメッセージ行を次に示します:

   {
     "uid" : 2,
     "user_info" : {
         "userName" : "mark",
         "emailAddr" : "[e-mail]",
         "firstName" : "Mark",
         "lastName" : "Doe"
         "organization" : "NoSQL"
     }
   }
   
   {
     "uid" : 2,
     "msgid" : 10,
     "msg_info" : {
         "sender" : "mark",
         "receivers" : [ "dave", "john", "george" ],
         "views" : [ "2024-07-01", "2024-07-02", "2024-07-05" ],
         "size" : 20,
         "date" : "2024-07-01",
         "thread_id" : 1
     }
   }

   次の問合せは、(a) NoSQLで作業しているユーザーに属し、(b)対応するユーザーの受信ボックス・フォルダにあるメッセージを選択します。結合述語"msg.uid = u.uid"および"msg.uid = inbox.uid"は、問合せが前述の制約を満たすようにします。

   SELECT msg.uid, msg.msgid, msg.msg_info
   FROM users u, users.inbox inbox, users.messages msg
   WHERE msg.uid = u.uid and msg.uid = inbox.uid and
         msg.msgid = inbox.msgid and
         u.user_info.organization = "NoSQL"

   次の問合せは、受信ボックス・フォルダ内のメッセージMごとに、同じユーザーおよびMと同じスレッドに属するメッセージの数を返します。

   SELECT msg1.uid, msg1.msgid, count(*)
   FROM users.messages msg1, users.messages msg2, users.inbox inbox
   WHERE msg2.uid = msg1.uid and
         msg1.uid = inbox.uid and
         msg2.msg_info.thread_id = msg1.msg_info.thread_id and
         msg1.msgid != msg2.msgid
   GROUP BY msg1.uid, msg1.msgid

   次の問合せでは、各ユーザーの受信ボックス・メッセージを表示日付に従ってグループ化し、日付ごとに表示されるメッセージ数を計算します。この問合せでは、users.messages表の別名に$を使用する必要があります。$を指定しない場合、FROM句のネスト解除した式はmsg.content.views[]になり、msg.contentは表名として解釈されます。

   SELECT $msg.uid, $view_date, count(*)
   FROM users.messages $msg, users.inbox $inbox, $msg.content.views[] as $view_date
   WHERE $msg.uid = $inbox.uid and $msg.msgid = $inbox.msgid
   GROUP BY $msg.uid, $view_date

   [KVSTORE-2193]

2. JSONマージ・パッチ仕様(https://datatracker.ietf.org/doc/html/rfc7386で説明されています)を使用したJSONフィールドの更新をサポートするように、SQL UPDATE文が拡張されました。たとえば、"info"が"Foo"という表内のjson型の列であるとすると、次の問合せでは、id = 0の行のinfo列が更新されます。"address"フィールド内の"state"フィールドの値を"OR"に設定します。また、"firstName"フィールドの値を$name外部変数の値に設定します。ターゲット・フィールド("address"、"state"および"firstName")のいずれかがinfoに存在しない場合は、挿入されます。

   update Foo f
   json merge f.info with patch { "address" : { "state" : "OR" }, "firstName" : $name }
   where id = 0

   次の問合せでは、id = 2の行のアドレスから"city"フィールドを削除します("city"フィールドが存在する場合)。

   update Foo f
   json merge f.info.address with patch { "city" : null }
   where id = 2

   [KVSTORE-1015]

3. 問合せ述語にシャード・キーが含まれている場合に、複数のレコードを更新するためのサポートが追加されました。

   次に例を示します。

   create table users(groupId string,
                      uid integer,
                      name string,
                      level integer,
                      primary key(shard(groupId), uid))

   insert into users values("g01", 1, "alex", 0)
   insert into users values("g01", 2, "jack", 0)
   insert into users values("g02", 1, "flex", 0)

   update users set level = level + 1 where groupId = "g01"
   {"NumRowsUpdated":2}

   select * from users;
   {"groupId":"g01","uid":1,"name":"alex","level":1}
   {"groupId":"g01","uid":2,"name":"jack","level":1}
   {"groupId":"g02","uid":1,"name":"flex","level":0}

4. マスター・ノードでのトランザクションのグループ・コミット

   SyncPolicy.SYNCを使用するマスター・ノードのトランザクションは、各トランザクションを個別にfsyncするのではなく、グループとしてfsyncするように構成できるようになりました。これにより、fsyncの数が減少し、パフォーマンスが大幅に向上します。定足数のノードがfsyncされ、トランザクションが確認されると、トランザクションは永続的とみなされます。

   この機能を使用するトランザクションは、構成された数のトランザクションがバッファリングされたか、構成された時間間隔が過ぎた後にfsyncされます。構成は次のとおりです:

   • ReplicationConfig.MASTER_GROUP_COMMIT_INTERVAL (je.rep.masterGroupCommitInterval)
   • ReplicationConfig.MASTER_MAX_GROUP_COMMIT (je.rep.masterMaxGroupCommit)

   この機能はデフォルトで無効です。

   [KVSTORE-2502]

5. DbVerifyは、新しく作成した環境で実行したときに失敗しなくなりました

   KV環境で実行するときにMetadataTableが見つからない場合、DbVerifyは失敗します。これは、KVでの致命的な破損を示しているためです。ただし、KV環境が新しく作成された場合、MetadataTableはまだ作成されておらず、これは許容できる状態であるため、この障害は新しく作成された環境では報告されなくなりました。

   [KVSTORE-2522]

6. EnvironmentFailureExceptionエラー・メッセージに、エラーの処理方法に関する推奨事項が含まれるようになりました。

   推奨事項は次のとおりです:

   • RESTART_PROCESS - プロセスを再起動します。
   • REOPEN_ENVIRONMENT - 環境をクローズして再オープンします。
   • HUMAN_INTERVENTION - プロセスをクローズし、人間の介入を待機します。

   推奨事項は、EnvironmentFailureException.getSuggestion()をコールしてプログラムで取得することもできます。

   [KVSTORE-2279]

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

1. まれに、ネットワーク・パーティションでの拡張度操作によって、データが2つのレプリケーション・グループで一時的にホストされることがあるという問題を修正しました。これはスプリットブレインの問題であり、データが失われる可能性があります。この問題の兆候は、次のような2つのメッセージが次々と表示されることです:

   2025-02-28 15:39:22.527 UTC INFO [rg1-rn1] Migration source detected failure of SourceRecord[PARTITION-493, rg1, rg2-rn1], target returned PENDING, removing completed record
   2025-02-28 15:40:32.142 UTC SEVERE [rg1-rn1] uncaught exception in thread
   java.lang.IllegalStateException: [PARTITION-493]  shard=rg1 is associated with the same shard in both the current(seq #: 1,301) and local topologies but is associated with a different shard rg2 in the new topology(seq#: 1,302).

   新しいトポロジがブロードキャストされると、問題が最終的に自動的にリカバリされる可能性があります。

   [KVSTORE-2276][KVSTORE-2640]

2. エラスティック操作がない場合に書込み操作が失敗するバグを修正しました。

   [KVSTORE-2610]

3. ソースのKVStoreがオーバーロードされている場合に、ストリーミング中にサブスクリプション・ストリームがそれ自体の再認証に失敗するというバグを修正しました。

   [KVSTORE-2571]

4. エラスティック操作でputやdeleteなどの書込み操作が適用されないバグを修正しました。

   [KVSTORE-2373]

5. パスワード・ストアのファイル形式の実装を変更し、スペースまたはその他の空白文字で開始または終了する別名またはシークレット値の格納が拒否されるようにしました。以前は、これらの空白文字は格納される値から削除されていました。つまり、これらの空白文字を含む別名またはシークレットは正しく機能しませんでした。Oracle Walletに格納される別名およびシークレットでは、先頭および末尾の空白が引き続き許可されます。

   [KVSTORE-2437]

6. runadminで1つのサブコマンドとしてpingコマンドを使用すると、pingの出力に関係なく終了コードとしてゼロが返されるという問題を修正しました。たとえば、kvstore内のシャードの1つに定足数がない場合、次のコマンドでは終了コードとしてゼロが返されます:

   java -jar KVHOME/kvstore.jar runadmin -host <hostname> -port <portname> ping

   このコマンドは、スタンドアロンのpingユーティリティ・コマンドと同様に、正しいエラー・コード3を返すようになりました。

   [KVSTORE-2163]

7. 管理CLIコマンドtopology change-repfactor、topology rebalanceおよびtopology redistributeが変更され、新しく追加されたSNストレージ・ディレクトリ・サイズが使用中の既存のサイズより小さいかどうかが確認されるようになりました。この場合、トポロジは新しいSNを使用できません。topologyコマンドに、ユーザーに警告するために、問題に関する情報が含まれるようになりました。

   警告メッセージの例:

   Note: Some new SN storage directory sizes are smaller than the smallest
   existing storage directory size, which may prevent new SNs from being
   used in the new topology. The smallest existing SN storage directory
   size is 2147483648, but the following smaller new SN storage directory
   sizes were specified: {sn4={/usr/kvroot4=1073741824},
   sn5={/usr/kvroot5=1073741824}}

   [KVSTORE-2036]

8. SNでストレージ・ディレクトリ・サイズ・パラメータを設定するときに、同じデバイス上のすべてのストレージ・ディレクトリに対して指定されたサイズの合計が、デバイスの合計ストレージ・サイズを超えるサイズにならないことを検証するようになりました。この修正の前、makebootconfigおよびplan change-storagedirでは、各ストレージ・ディレクトリのサイズを確認しましたが、同じデバイス上のすべてのディレクトリの合計は確認していませんでした。

   [KVSTORE-1684]

9. プール名またはゾーン名を指定するときに空の文字列または空白の文字列を使用できなくなるように、管理CLIのpool createコマンドの問題を修正しました。かわりに警告が返されるようになりました。

   [KVSTORE-1694]

10. JVM引数がサポートされていないため、レプリカ・ノード・プロセスの起動時にJVMで障害が発生する問題を修正しました。この修正は、プロセスを開始する前に、特定のJavaバージョンの既知の廃止された引数を識別し、それらを除外することです。

    [KVSTORE-2509]