Oracle NoSQL Database変更ログ

リリース12cR1.3.0.5 Enterprise Edition

このリリースのOracle NoSQL Databaseには、複数の新機能が追加されています。これには、ユーザー/パスワード認証、ネットワーク・セキュリティ、セカンダリ・ゾーン、および型指定データと表形式データ・モデル(これにより、表内のフィールド上で2次索引を定義する機能が追加されます)のサポートが含まれます。この表インタフェースにより、表、索引およびデータ型にアクセスするための新しいクライアントAPIとともに、これらの新しい構成メンバーを管理するためのCLIが追加されます。

アップグレード要件

既存のストアをリリース3.0にアップグレードするには、2.0リリースでストアを実行する必要があります。2.0より前のリリースで作成されたストアでリリース3.0を使用する場合には、3.0リリースにアップグレードする前にストアを2.0リリースにアップグレードしてください。ストアを3.0にアップグレードした後は、以前のリリースにダウングレードできません。

管理者ガイドの既存のOracle NoSQL Databaseデプロイの更新に関する項を参照してください。

リリース3.0はJava SE 7以降との互換性があり、Oracle JDK 7u51に対してテストおよび認証されています。最新の不具合修正およびパフォーマンス改善を利用するために、最新のJavaリリースにアップグレードすることをお薦めします。

Java 7より前のバージョンのJavaとともにこのリリースを使用しようとすると、次のようなエラー・メッセージが表示されます。

Exception in thread "main" java.lang.UnsupportedClassVersionError:
  oracle/kv/impl/util/KVStoreMain : Unsupported major.minor version 51.0


12cR1.3.0.5 Enterprise Editionでの変更点

新機能

  1. 一連のデータ型およびこれらのデータ型を使用した表形式データ・モデルが含まれる新しいクライアント・インタフェースが追加されました。この表形式データ・モデルにより、表内のフィールドで定義されている2次索引がサポートされます。このモデルについては、Tableスタート・ガイドで説明されています。

    表および索引は、管理CLIを使用して定義され、プログラムAPIを介してアクセスされます。データCLIが拡張され、表および索引に対しても操作を実行できるようになりました。APIについてはOracle NoSQL Database javadocで説明されており、主にoracle.kv.tableパッケージ内にあります。

    NoSQL DBリリース2を使用して作成されたデータが、準拠するAvroスキーマを使用して作成されたものである場合、このデータをオーバーレイする表を定義できます。準拠するリリース2のデータで2次索引を作成するには、このオーバーレイが必要です。

    既存のキー/値インタフェースは引き続き使用可能です。


  2. レコードに対して2次索引を定義できるようになりました。表に関する前述の変更ログ・エントリを参照してください。特定のレコードの索引エントリには、対応するプライマリ・レコードとのトランザクション一貫性があります。索引の反復操作は、新しい表APIの一部です。索引スキャン操作を使用すると、RAW索引に対して3通りの方法(正順、逆順および順序付けなし)で反復できるようになります。索引に対して完全一致および範囲スキャンを定義できます。索引は、単一フィールドに対して定義することも、表内の複数のフィールドに対する複合索引として定義することもできます。

  3. ユーザー名/パスワード認証およびセキュアなネットワーク通信のサポートが追加されました。この機能を必要としない既存のアプリケーションはこの影響を受けません。ただし、必須の引数(-store-security)が新しく追加されている、makebootconfigに対する変更は除きます。新機能の使用を希望するユーザーは、次の変更領域に注意する必要があります。

    ユーザーは、セキュリティ・プロパティ・ファイルについてもよく理解している必要があります。これらのファイルは、セキュアなストアに対してKVStoreコマンドライン・ユーティリティ・プログラムを使用する際に必要であり、セキュアなストアに対してアプリケーションを実行する際にも役立つ場合があります。

    この機能は、『Oracle NoSQL Databaseセキュリティ・ガイド』や管理者ガイドおよび製品のJavadocでさらに詳しく説明されています。


  4. 管理CLIが、データ・センターに言及するのに新しい用語を使用するように変更されました。データ・センターはゾーンと呼ばれるようになりました。新しい用語は、これらのノード・グループが物理データ・センターと必ずしも一致するとは限らないことを明らかにすることを目的としています。ゾーンは、ネットワークの相互接続性が良好であり、他のゾーン内のノードとある程度物理的に分離されているノードの集合です。この物理的な分離とは、各ゾーンが異なる物理データ・センター・ビルに配置されていることを意味する場合がありますが、特定のデプロイメントに応じて異なるフロア、ルーム、ポッドまたはラックを表す場合もあります。

    "datacenter"という単語が含まれるコマンドは非推奨となり、"zone"という単語を使用したコマンドに置き換わりました。このリリースでは、以前のコマンドもそのまま機能します。新しいコマンドは、次のとおりです。

    ゾーンを指定するコマンド・フラグは、ゾーンIDの場合は-znに、ゾーン名の場合は-znnameに変更されました。以前の-dcおよび-dcnameフラグは非推奨となりましたが、このリリースではそのまま機能します。また、ゾーンIDはzn接頭辞を使用して指定できるようになりましたが、以前のdc接頭辞も現在サポートされています。

    管理GUIが、この新しい「ゾーン」という用語を使用するように変更されました。[#22878]


  5. 現在、ゾーンには2つのタイプがあります。プライマリ・ゾーンには、選択可能なノードが含まれます。これは、マスターまたはレプリカとして機能し、マスター選択に参加できます。以前のリリースで作成されたゾーン(またはデータセンター)はすべてプライマリ・ゾーンであり、新しいゾーンはデフォルトではプライマリ・ゾーンとして作成されます。セカンダリ・ゾーンには、新しいセカンダリ・ノード・タイプのノードが含まれます。これは、レプリカとしてのみ機能し、マスター選択には参加しません。セカンダリ・ゾーンを使用して、離れた場所で使用可能なデータのコピーを作成したり、データの余分なコピーを維持し、冗長性や読取り能力を向上させることができます。[#22483]

  6. show planコマンドで、移行の完了時間の見積りが示されるようになりました。次に例を示します。
    Plan Deploy Topo (12)
    State:                 RUNNING
    Attempt number:        1
    Started:               2014-01-14 17:35:09 UTC
    Ended:                 2014-01-14 17:35:27 UTC
    Total tasks:           27
     Successful:           12
     Incomplete:           15
    Incomplete tasks
       3 partition migrations queued
       1 partition migrations running
       11 partition migrations succeeded, avg migration time = 550164 ms.
    Estimated completion:  2014-01-14 19:57:37 UTC
    
    [#22183]

  7. このリリースで、新しい読取り一貫性オプションが追加されました。oracle.kv.Consistency.NONE_REQUIRED_NO_MASTERを使用して、目的の読取り操作が必ずマスターではなくレプリカによって処理されるよう指定できるようになりました。読取りの負荷が高いアプリケーション(分析など)の場合、マスターに対する負荷を軽減するために、読取り要求を分離し、これらがマスターではなくレプリカに対してのみ実行されるようにした方がよい場合があります。この種の読込みの分離を実現する上で望ましいメカニズムが、新しいセカンダリ・ゾーン機能です。この目的のためにはこの機能を採用することをお薦めします。ただし、セカンダリ・ゾーンの使用が望ましくない場合や現実的でない場合は、oracle.kv.Consistency.NONE_REQUIRED_NO_MASTERを使用すると、セカンダリ・ゾーンの場合に必要となる可能性があるリソースの追加なしで同様の効果を上げることができます。[#22338]

  8. 次のメソッドが追加されました。

    これらのメソッドを使用すると、指定したゾーン内にあるノードについてのみ読取り操作が実行されるよう要求できるようになります。


  9. show plansコマンドが変更され、プラン履歴の範囲を指定できるようになりました。show plansでは、引数なしで、最近作成された10のプランのみが表示されるようになりました。ただし、新しい引数を使用して、作成時間やプランID別に範囲を選択することもできます。すべてのオプションの一覧を確認するには、コマンドshow plans -helpを発行します。

  10. makebootconfigユーティリティに、新しい-runadminコマンドライン引数がオプションとして用意されました。これを使用すると、-adminの値が0に設定されている場合でもSNAでブートストラップ管理を強制的に起動できます。

    管理CLI内のplan deploy-adminのオプション-portが変更され、管理Webサービスの起動を制御できるようになりました。デプロイで-portが0に設定されている場合、管理のWebサービスは起動されません。

    ユーザーは、管理CLIのplan change-paramコマンドを介してデプロイメント後に管理のHTTPポートを変更し、管理によるWebサーバーの実行の有無に関する設定を変更することもできます。[#22344]


  11. plan change-paramコマンドが変更され、単一管理サービスのパラメータを変更できるようになりました。[#22244]

  12. NoSQLトポロジ情報は管理サービスとストレージ・ノードの両方に格納されますが、deploy-topologyやmigrate-snなどのトポロジ変更プランが完了前に取り消されると、この情報の一貫性がなくなる可能性があります。不整合は、ターゲット・トポロジの再デプロイによって修復できます。このリリースでは、トポロジの不整合を修復する別の方法としてplan repair-topologyコマンドも用意されています。verify configurationコマンドでは、repair-topologyの使用が役立つタイミングに関する推奨が生成されるようになりました。[#22753]

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

  1. makebootconfigコマンドで、既存の構成ファイルの上書きが拒否されたときにメッセージが出力されるようになりました。[#23012]

  2. plan remove-adminで、実行されていないストレージ・ノードによってホストされている管理を削除できるようになりました。[#23061]

  3. ストレージ・ノードのconfig.xmlファイル内の管理セクションが重複する原因となる場合があった不具合を修正しました。そのため、このような不規則な構成がある管理サービスに対してplan change-parametersコマンドを適用しても、予期せずこのコマンドの効果がない可能性があります。この不具合は、すでにデプロイされている管理をデプロイしようとしたときに発生する可能性がありますが、失敗したplan migrate-storagenodeコマンドを再実行したときに発生する可能性もあります。[#23152]

  4. 新しいレプリケーション・ノードの作成時にtopology redistributeコマンドでストレージ・ディレクトリの設定が無視される原因であった問題を修正しました。[#23161]

  5. 以前は、レプリケーション・ノードのメトリック収集期間(statsInterval)中にアクティビティがなかった場合、前の期間のメトリック値がJMXおよびSNMPによってレポートされていました。この動作は変更され、すべての間隔でメトリックが更新されるようになりました。[#22842][#22537]

  6. NoSQL DBによってマスター・アイデンティティが自動的に調整されるため、マスター・ノードがストア全体にわたって配分され、最適なパフォーマンスが得られます。マスターのバランス調整が複数のゾーンにわたって実行される妨げとなっていた問題を修正しました。[#22857]

  7. InputStream.skipに対するコールによってゼロ以外の値が返されるかぎり、入力ストリームを開始位置に配置するためにこのコールを必要に応じて繰り返すようLOB実装を変更しました。コールによってストリームが必要な開始位置に移動されない場合、IllegalArgumentExceptionがスローされます。

ユーティリティの変更点:

  1. 管理コマンドライン・インタフェース(CLI)とデータ・コマンドライン・インタフェースが単一プログラムにマージされました。マージされたCLIの使用方法には、最も古い使用方法との互換性がありますが、管理操作、データ操作あるいはその両方に対して有効化するための追加オプションが用意されています。この変更により、データ操作用としてkvstore.jarの使用が必要となりました。前のリリースでは、データCLIには、kvclient.jarに依存するkvcli.jarのみが必要でした。

  2. CLIが、表、索引、セキュリティ情報およびゾーンの管理に必要なコマンドにより拡張されました。

ドキュメントの変更:

  1. 表形式データ・モデルおよび2次索引の導入により、新しいTable APIスタート・ガイドが追加されました。

  2. 新しいセキュリティ機能の導入により、新しいセキュリティ・ガイドが追加されました。

パッケージの変更:

  1. Oracle NoSQLデータベースに同梱されているAvroおよびJacksonライブラリのバージョンが最新のAvro 1.7.6およびJackson 1.9.3にアップグレードされました。これらのバージョンは以前のAPIバージョンと互換性があります。

12cR1.2.1.57での変更点

新機能

  1. 新しいメソッドKVStore.appendLOB()では、既存のLOB (ラージ・オブジェクト)への追加が許可されるようになりました。この変更の一環として、メソッドPartialLOBException.isPartiallyDeleted()が非推奨となり、新しいメソッドPartialLOBException.getPartialState()が推奨となります。この新機能の詳細な説明は、これらの新しいメソッドに付属のJavadoc、およびインタフェースKVLargeObjectに関して更新されたドキュメントを参照してください。

    このリリースには、以前のリリースで作成されたLOBに対する下位互換性があります。ただ、これには1つの例外があり、これ以降のリリースで作成されるLOBのみが追加操作をサポートします。以前のリリースで作成されたLOBに対して追加操作を使用しようとすると、メソッドによりUnsupportedOperationExceptionがスローされます。

    このリリースで作成されたLOBは、以前のリリースを使用しているクライアントから読取りや削除を行うことはできません。通常、このような操作は失敗し、ConcurrentModificationExceptionがスローされます。新しいLOBを作成する前にすべてのクライアントをこのリリースに更新するようにしてください。[#22876]


  2. 管理サービスおよびレプリケーション・ノード・サービス用のGCログ・ファイルがデフォルトで生成され、KVROOT/<storename>/logディレクトリ(NoSQLに関するすべてのロギング情報用の標準の場所)に配置されるようになりました。このデフォルトの動作は、JDKリリース1.7以降のリリースを使用している場合のみ適用されます。これは、GCログのローテーションは最新のJDKでのみサポートされるためです。ロギングによるリソースのオーバーヘッドは最小限です。これらのログ・ファイルを即座に使用できるようにしておくことは、本番Javaアプリケーションのデプロイメントに関するベスト・プラクティスに準拠しています。これにより、必要な場合に、GC問題をより簡単に診断できるようになります。[#22858]

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

  1. 多数の変更が行われたストアの操作時における管理サービスのヒープ要件が削減されました。[#21143]

  2. プラン履歴レポートからのパーティション移行タスクに関する情報が省略される原因となった管理CLIのshow plan -id <id>コマンドの不具合を修正しました。現在、このコマンドには、パーティションの移行に関する情報が正しく含まれています。[#22611]

  3. マスターとレプリカ間のネットワーク接続に関連する内部タイムアウト値が削減され、ネットワーク・ハードウェアに障害が発生した場合にマスターをより速くフェイルオーバーできるようになりました。[#22861]

  4. 3968KBより大きいLOBで失敗したPut操作を再開しようとすると、状況によっては不正なConcurrentModificationExceptionが生じる可能性がありました。この不具合はこのリリースで修正されました。[#22876]

  5. プランを管理のメモリーに表示する方法が変更されました。以前は、現在アクティブなプランと履歴プランのメモリー内に表示可能なサイズに制限はありませんでした。この修正により、アクティブなプランのみがメモリー内に保持されるようになりました。[#22963]

  6. 管理におけるプラン管理のデッドロックが解消されました。[#22992]

  7. setterメソッドStoreIteratorConfigの引数チェックの不具合が修正されました。[#23010]

  8. makebootconfigコマンドで、既存の構成ファイルの上書きが拒否されたときにメッセージが出力されるようになりました。[#23012]

  9. レプリケーション・ノード構成が変更され、レプリケーション・ノードのキャッシュが必要な量より少ない場合、キャッシュの退去が行われ、CPU使用率が削減されるようになりました。[#23026]

  10. remove-adminコマンドでは、実行されていないストレージ・ノードによってホストされている管理を削除できるようになりました。[#23061]

  11. show plansコマンドでは、メモリーの消費が大きすぎるために管理CLIがクラッシュする場合がありました。これは修正されました。[#23105]


12cR1.2.1.54での変更点

新機能

  1. Oracle NoSQL Databaseのクライアント専用パッケージが提供されるようになりました。Oracle NoSQL Databaseクライアント・ソフトウェア・ライブラリのライセンスは、Apache 2.0ライセンス(Apache 2.0)に準じて提供されます。NoSQL DBクライアント・ソフトウェア・ライブラリのApacheライセンスおよびサード・パーティの通知については、この場所またはダウンロードしたソフトウェアで確認できます。

  2. KVStore.storeIterator()およびKVStore.storeKeysIterator()の新たなオーバーロードには、パラレル・スキャンが導入されています。その他のstoreIterator()メソッドでは、すべてのシャードとレプリケーション・ノードをシリアルにスキャンします。新しいパラレル・スキャン・メソッドでは、レプリケーション・ノードをパラレルにスキャンする際に使用するクライアント側のスレッド数を指定できます。[#22146]

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

  1. データ・コマンドライン・インタフェース(kvshell)のエラー・メッセージを改善しました。たとえば、putコマンドに無効な入力を指定すると、以前は次のようなエラー・メッセージが返されていました。
    kvshell-> put -key /test -value ./emp.insert -file -json Employee
      Could not create JSON from input:
      Unable to serialize JsonNode
    
    現在は、次のような有用な応答が生成されます。
    kvshell-> put -key /test -value ./emp.insert -file -json Employee
    Exception handling command put -key /test -value ./emp.insert -file -json Employee:
      Could not create JSON from input:
      Expected Avro type STRING but got JSON value: null in field Address of Employee
    
    [#22791]

  2. plan deploy-adminコマンドを使用した際のバグを修正しました。管理サービスの起動時にエラーが発生すると、プロセスが応答不能になる場合がありました。正しい動作では、プロセスは停止した後、所有するストレージ・ノードから再起動します。[#22908]


12cR1.2.1.24での変更点

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

  1. レプリケーション・ノードが停止する直前またはマスターからレプリカ状態に遷移している途中などの特定の状況において、未処理リクエストのクリーン・アップ時に問題が発生することがありました。ノードは自動的に再起動して操作が再試行されるため、この問題はアプリケーションに対して透過的でしたが、ノードのフェイルオーバーを不必要に発生させる可能性がありました。これは修正されました。
    java.lang.IllegalStateException: Transaction 30 detected open cursors while aborting
        at com.sleepycat.je.txn.Txn.abortInternal(Txn.java:1190)
        at com.sleepycat.je.txn.Txn.abort(Txn.java:1100)
        at com.sleepycat.je.txn.Txn.abort(Txn.java:1073)
        at com.sleepycat.je.Transaction.abort(Transaction.java:207)
        at oracle.kv.impl.util.TxnUtil.abort(TxnUtil.java:80)
        at oracle.kv.impl.api.RequestHandlerImpl.executeInternal(RequestHandlerImpl.java:469)
        at oracle.kv.impl.api.RequestHandlerImpl.access$300(RequestHandlerImpl.java:122)
        at oracle.kv.impl.api.RequestHandlerImpl$2.execute(RequestHandlerImpl.java:301)
        at oracle.kv.impl.api.RequestHandlerImpl$2.execute(RequestHandlerImpl.java:290)
        at
    oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:135>
    
    [#22152]

  2. NoSQL DBの以前のリリースでは、レプリケーション・ノードがマスターからレプリカ状態に遷移する場合、その遷移過程でデータベース環境をクローズして再オープンする必要がありました。現在の遷移は効率化されているため、多くの場合データベース環境に混乱が生じることはありません。遷移が必要とするリソースは少なくなり、ノードの可用性が向上しました。[#22627]

  3. plan deploy-topologyコマンドに保護手段が追加され、トポロジのバランス再調整とプランの再配分における信頼性が向上しました。レプリケーション・ノードを別のストレージ・ノードに移動する場合、操作を行う前に、操作対象のストレージ・ノードが起動され実行中であることをコマンドによってチェックするようになりました。[#22850]

  4. 特定の状況において、レプリケーション・ノードがシャードに参加するときに古くなったマスター・アイデンティティ情報を使用する可能性がありました。これによって、ターゲット・ノードが使用不可である場合に遅延が生じることがありました。これは修正されました。[#22851]

  5. 特定の状況において、操作が完了前にoracle.kv.impl.fault.TTLFaultExceptionで終了しました。現在、この例外はサーバーとクライアントのライブラリによって内部的に処理され、操作が再試行されます。障害状態が継続する場合、操作は最終的にoracle.kv.RequestTimeoutExceptionで失敗します。[#22860]

  6. 以前は、レプリケーション・ノードが起動してシャードに参加するためにシャード・データのコピーの転送を要する場合がありましたが、これは不必要でした。これは修正されました。[#22782]

  7. Oracle NoSQL DBデプロイメントに新しいストレージ・ノードが追加され、新しいトポロジがデプロイされる場合、ストアではパフォーマンスを最適化するためにマスター・ロールが再配分されます。フェイルオーバーやマスター変更などの他のイベントが発生するまで、ストアが新しいストレージ・ノードを通知しない場合があり、マスターのバランス調整に遅れが生じることがありました。これは修正されました。[#22888]

  8. ストアで使用するJE構成パラメータje.evictor.criticalPercentageの設定が修正されました。これは105に設定されていましたが、20に変更されました。この新しい設定値によって、データ・セットのサイズがメモリー設定の最適値を超える場合のキャッシュ管理動作が改善されます。[#22899]

ユーティリティとドキュメントの変更点

  1. CLIのpingコマンドの出力にタイムスタンプが追加されました。[#22859]


12cR1.2.1.19での変更点

ドキュメントの変更点

  1. このリリースには、新しいドキュメント『Oracle NoSQL Database可用性およびフェイルオーバー』が含まれます。ここでは、Oracle NoSQL Databaseを使用する際のデータの可用性に関する一般的な概念と問題を説明しています。このドキュメントの対象読者は、システム・アーキテクトと開発者です。ドキュメントの索引ページにある開発者向けの項に、新情報が記載されています。

  2. <KVHOME>/examples/avroにあるAvroバインディングを例にした、.avscファイルをクラスパスに追加する手順を明確化しました。.avscファイルが適切に使用可能になっていない場合のエラー・メッセージを改善しました。

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

  1. ロック・タイムアウトの内部パラメータを500ミリ秒から10秒に増やしました。NoSQL DBではデータ・アクセスにデッドロックが発生しないため、小さい値のタイムアウト値は必要ありません。これによって一時的なネットワーク障害の際に疑似エラーが発生することがありました。[#22583]

  2. 一時的なネットワーク障害が発生している場合、またはレプリケーション・ノードの移動に数秒以上かかる場合にplan deploy-topologyコマンドを使用してストアのトポロジを変更すると、次のエラーが発生することがあります。ストア状態の整合性が失われておらず、コマンドを手動で再試行できるとしても、コマンドは通信の不調からより速やかに回復できる必要があります。
    ... [admin1] Task 2/RelocateRN ended in state ERROR with
    java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
    up on sn1 and become consistent with the master of the shard before
    deleting the RepNode from its old home on sn4 2/RelocateRN failed.
    
    java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
    up on sn1 and become consistent with the master of the shard before
    deleting the RepNode from its old home
    

    コマンドの待機時間が調整され、再試行が適切に行われるようになり、レプリケーション・ノードの移動が完了したかどうかを確認できるようになりました。[#22596]


  3. データ・ファイルを持つディレクトリが削除された場合、またはデータ・ファイルが破損した後に修復された場合に、レプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22626]

  4. セグメント化されたネットワークのスプリット・ブレイン・シナリオにおいて、クライアントの書込みリクエストが権限のあるマスターに向かうという従来の正しい動作を補強するため、さらにテストを追加しました。[#22636]

  5. java -jar kvstore.jar pingコマンドを使用すると、ストア内で有効ではなくなったコンポーネントに関する疑似メッセージが生成される場合がありました。
    Failed to connect to service commandService
    
    Connection refused to host: 10.32.17.12; nested exception is:
      java.net.ConnectException: Connection refused
            SNA at hostname:localhost registry port: 6000 has no available
            Admins or RNs registered.
    
    これらのメッセージは特に、デプロイされた管理サービスをホストしていないストレージ・ノードのブートストラップ管理に対して発生します。ストアの整合性はとれているため、混乱をまねくエラー・メッセージは削除されました。[#22639]

  6. レプリケーション・ノードのマスター移動時に表示される小さなタイミング・ウィンドウを修正しました。アプリケーションの負荷が高い状態でマスターの移動が発生した場合、移動トランザクションのキャッチ・アップ・ポイントの後戻りがこのウィンドウによって誤って引き起こされる可能性がありました。その結果、シャード・マスターの移動にかかる時間が長すぎることや短すぎることがありました。移動時間が短すぎると、ターゲット・マスターの最適なキャッチ・アップが行われない可能性があります。シャードの第3のメンバーによってこれが検知されると、例外がスローされます。[#22658]

  7. ノードがマスターからレプリカに遷移する際に、レプリケーション・ノードの停止と再起動を優先的に行います。これにより、データベース環境の更新の際のGCコストが軽減されます。[#22658]

  8. 元のターゲットが使用可能でないことが検知された場合に、データ・リクエストがすぐに再試行または転送されるよう、NoSQLクライアント・ライブラリを変更しました。これによって、レプリケーション・ノードの障害により速やかに適応できるようになりました。[#22661]

  9. トポロジ変更の実行中に、NoSQLデプロイメントで一時的なエラーが表示される場合がありました。ストアの整合性はとれていましたが、このエラー・メッセージによって混乱が生じ、plan deploy-topologyコマンドが誤って失敗する可能性がありました。これは修正されました。
     ... INFO [rg1-rn1] Failed pushing entire topology push to rg1-rn3
    updating from topo seq#: 0 to 1001 Problem:Update to topology seq#
    1001 failed ... oracle.kv.impl.fault.OperationFaultException:
      Update to topology seq# 1001 failed
        at oracle.kv.impl.rep.admin.RepNodeAdminImpl$6.execute(RepNodeAdminImpl.java:261)
        at oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:169)
        at oracle.kv.impl.rep.admin.RepNodeAdminFaultHandler.execute(RepNodeAdminFaultHandler.java:117)
    
     ...INFO [rg1-rn3] Topology update skipped. Current seq #: 1001 Update seq #: 1001
    
    [#22678]

  10. メモリー不足エラーが発生したレプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22679]

  11. ストレージ・ノードがブートストラップのmemory_mbパラメータの値なしで構成されている場合に行われる、ストレージ・ノードの使用可能メモリーのデフォルトの計算を修正しました。以前は、MBではなく10進法のメガバイト単位を使用して計算していたため、レプリケーション・ノードの適正なヒープ・サイズを高く見積りすぎていました。このデフォルトの計算は、ストアがmemory_mbプロパティのブートストラップ値なしで構成されていて、memory_mbストレージ・ノード・パラメータが設定されたことがない場合にのみ使用されます。[#22687]

  12. ストレージ・ノードがホストするレプリケーション・ノードのレプリカ/マスター状態を、より速やかに更新します。この修正は、1より大きい容量値を持ち、複数のレプリケーション・ノードをホストできるストレージ・ノードが含まれるストアでplan deploy-topologyコマンドを実行する場合に適用されます。ストレージ・ノードに対するレプリケーション・ノードの状態の通知が遅れると、マスター職責の最適な配分が保てなくなります。[#22689]

  13. plan deploy-topologyコマンドを実行すると管理サービスが応答しなくなるバグを修正しました。この間、管理サービスのプロセスはアイドル状態になり、時折1~2秒のCPU時間を消費するだけで、管理CLIを使用して新しい接続を試みても応答しませんでした。この問題は、数百コンポーネントが含まれるような大規模なクラスタでのみ発生すると考えられます。[#22694]

  14. plan deploy-topologyでトポロジが変更されると、レプリケーション・ノードが別のストレージ・ノードに移動します。この際に一時的なネットワーク障害が発生した場合の回復方法が改善されました。移動に関連するシャードとストレージ・ノードが使用可能で変更を受け入れる準備ができていることを確認するための事前チェック追加されました。移動の途中でネットワーク障害が発生した場合に、再試行のためにシステム管理者が発行するコマンドが使いやすくなりました。[#22722]

  15. ストアにおいてトポロジの変更が実行されており、これに高負荷状態でのパーティション移行が必要とされている場合に、アプリケーション・リクエストの処理が失敗するバグを修正しました。[#22778]

  16. レプリケーション・ノードのガベージ・コレクションのデフォルト・パラメータを調整してさらに最適化しました。これにより、CPUの使用率が軽減される場合があります。[#22779]

  17. ダウンタイムまたはネットワークの通信障害によってレプリカのレプリケーション・ノードが大幅に古くなった場合に、これを最新にしてアプリケーションのリクエストを処理できるようにするまでにかかる時間を短縮しました。以前はキャッチ・アップ・ステージを開始する前にプロセスを終了して再起動していましたが、現在は再起動をスキップするようになりました。[#22783]

  18. リソースを使用できない場合などにレプリケーション・ノードの再起動が繰返し失敗し、ストレージ・ノードの内部キューがいっぱいになってしいまうバグを修正しました。この場合はストレージ・ノードでレプリケーション・ノードを自動的に再起動できなくなるため、リブートを行う必要があります。[#22786]

  19. リソースの不足などによるエラーの繰返しで停止したレプリケーション・ノードが、plan start-serviceコマンドで再度有効化されても再起動しないバグを修正しました。[#22828]

  20. 再起動中のレプリケーション・ノードで次のnullポインタ例外が発生するバグを修正しました。これは一時的に発生した問題です。
       INFO [sn1] rg2-rn2: ProcessMonitor: startProcess
       INFO [sn1] rg2-rn2: ProcessMonitor: stopProcess
       SEVERE [sn1] rg2-rn2: ProcessMonitor: Unexpected exception in
    MonitorThread:
            java.lang.NullPointerExceptionjava.lang.NullPointerException
    	at oracle.kv.impl.sna.ProcessMonitor$MonitorThread.run(ProcessMonitor.java:404)
    
    [#22830]

  21. クライアント・ライブラリのUnknownHostExceptionとConnectIOExceptionの解析を改善したことで、より速やかにネットワークの問題を検出し、使用できないレプリケーション・ノードのセットを更新できるようになりました。[#22841]


12cR1.2.1.8での変更点

新機能

  1. このリリースには、ストアをオフラインにせず、また進行中の操作に大きな影響を与えずにNoSQL DBソフトウェア(クライアントまたはサーバー)をアップグレードするためのサポートが含まれます。また、アップグレードは増分的に実行できるため、すべてのコンポーネントで同時にソフトウェアを更新する必要はありません。このサポートには、クライアントおよびサーバーのコード変更と、新しいコマンドライン・インタフェース(CLI)コマンドが含まれます。[#22421]

    新しいCLIコマンドは、アップグレード・プロセスをサポートする管理者ツールとなります。これらのコマンドを使用した汎用のアップグレード手順は次のとおりです。

    1. 管理サービス1を実行するストレージ・ノードに新しいソフトウェアをインストールします。
    2. 新しいクライアントをインストールしてストアに接続します。
    3. verify prerequisiteコマンドを使用し、ストア全体がアップグレード対象として適切なソフトウェア・バージョンであることを確認します(すべてがNoSQL DBバージョン2.0であれば前提条件として適格です)。
    4. show upgrade-orderコマンドを使用して、アップグレードするノードの順序付きリストを取得します。
    5. ストレージ・ノードに新しいソフトウェアをインストールします(個別に、または順序付きリストに基づいてグループで)。
    6. verify upgradeコマンドを使用して、進行状況を監視し、アップグレードが成功したことを確認します。

    1今後のリリースではこの手順が不要になる予定です。

    アップグレード手順を中断した場合は、必要に応じて手順4から6を繰り返してアップグレードを完了してください。

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

  1. アプリケーションによって意図的に構成される場合を除き、NoSQL DBはレプリケーション・ノード・プロセスごとに-XX:ParallelGCThread jvmフラグを指定して、プロセスが使用するガベージ・コレクタ・スレッドの数を示します。以前は、使用されるアルゴリズムによって最小値1のスレッドが生成されていました。テストを重ねた結果、最小値はmin(4, <ノード上のコア数>)にまで引き上げられました。[#22475]

APIの変更点

  1. 管理コマンドライン・インタフェース(CLI)に、次のコマンドが追加されます。[#22422]

    verify prerequisite [-silent] [-sn snX]*

    このコマンドは、ストアの一連のストレージ・ノードが現行バージョンへのアップグレードに必要な前提条件を満たしていることを確認し、前提条件を満たしていないコンポーネントや接続できないコンポーネントを表示します。また、インストールされているソフトウェアが現行バージョンより新しいマイナー・リリースであるという無効なダウングレード状況でないこともチェックしてレポートします。このコマンドで、現行バージョンとはコマンドライン・インタフェースを実行しているソフトウェアのバージョンのことです。ストレージ・ノードが指定されていない場合は、ストア内のすべてのノードがチェックされます。

    verify upgrade [-silent] [-sn snX]*

    このコマンドは、ストアの一連のストレージ・ノードが現行バージョンに正常にアップグレードされたことを確認し、まだアップグレードされていないコンポーネントや接続できないコンポーネントを表示します。このコマンドで、現行バージョンとはコマンドライン・インタフェースを実行しているソフトウェアのバージョンのことです。ストレージ・ノードが指定されていない場合は、ストア内のすべてのノードがチェックされます。

    show upgrade-order

    このコマンドは、ストアの可用性を維持するためにアップグレードする必要がある順序で、ストレージ・ノードのリストを表示します。このコマンドは、1つ以上のストレージ・ノードを1行に表示します。1行に複数のストレージ・ノードが表示される場合、スペースで区切られます。1行に複数のストレージ・ノードが表示されている場合、そのノードをまとめて安全にアップグレードできます。複数のノードをまとめてアップグレードする場合、すべてのノードのアップグレードが完了してからでなければ、リストの次のノードはアップグレードできません。

    verify [-silent]コマンドは非推奨となり、verify configuration [-silent]に置き換えられます。verify [-silent]コマンドは、このリリースでも引き続き動作します。

ユーティリティとドキュメントの変更点

  1. このリリースでは、ユーティリティ・クラス WriteOperations (examplesディレクトリにあります)によって提供されるサンプル・コードに、ラージ・オブジェクト(LOBKVLargeObjectを参照)に対する書込み操作を実行するメソッドが追加されました。このリリースで追加された新しいユーティリティ・メソッドは、 FaultExceptionが発生したときに、関連するLOB操作を正しく再試行します。このリリースより前には、WriteOperationsユーティリティはラージ・オブジェクトでないオブジェクトに対してしか再試行メソッドを提供していませんでした。[#21966]

  2. レプリケーション・ノードで使用されるJEロック表の数(JE構成パラメータのje.lock.nLockTablesを介して制御される)が、1から97に増やされました。この変更でロック競合が緩和され、きわめて高いレベルの同時更新を特徴とするアプリケーションのパフォーマンスが向上します。[#22373]

  3. 管理CLIで、複数のデータセンターを作成できるようになります。各データセンターがレプリカのクォーラムより少ない数を保持するようにデータセンター・レプリケーションの要素を選択すると、ストア・レイアウトを作成できるようになり、1つのデータベースで障害が発生してもストア内のどのシャードでも書込み可用性が損なわれません。現在のリリースでは、どのデータセンターのノードもマスター選択に関与でき、永続性の確認に貢献します。その結果、距離がかなり離れているデータセンターが関わる場合には、マスター・フェイルオーバーと永続性確認に時間が長くかかるようになります。今後のリリースでは、この部分の柔軟性が向上する予定です。[#20905]

11gR2.2.0.39での変更点

新機能

  1. Oracle Coherenceとの統合が実現し、Oracle CoherenceアプリケーションのキャッシュとしてOracle NoSQL Databaseを使用できるようになりました。また、アプリケーションはOracle NoSQL Databaseからキャッシュ・データに直接アクセスできます。この統合は、本製品のEnterprise Editionの機能であり、新しい独立のjarファイルとして実装されています。Oracle Coherence製品もインストールされている必要があります。この機能の詳細は、スタート・ガイドの他にjavadocも参照してください。[#22291]

  2. Enterprise Editionは、セマンティック・テクノロジをサポートするようになりました。具体的には、Resource Description Framework (RDF)、SPARQL問合せ言語、およびWeb Ontology Language (OWL)のサブセットがサポートされます。これらを総称して、Oracle NoSQL DatabaseのRDFグラフ機能と呼びます。RDFグラフ機能には、Oracle NoSQL Database Enterprise Editionでセマンティック・データを格納し問い合せるJavaベースのインタフェースがあります。この機能の詳細は、RDFグラフのマニュアルを参照してください。

バグ修正

  1. NoSQL DBのメモリー・リソースを設定するときに望ましいのは、makebootconfigユーティリティを実行するときSNごとにmemory_mbパラメータを指定し、理想的なレプリケーション・ノードのヒープおよびキャッシュ・サイズをシステムで計算させる方法です。ただし、レプリケーション・ノードのjavaMiscParamsパラメータとcacheSizeパラメータを使用して明示的にヒープおよびキャッシュ・サイズを設定すれば、標準のメモリー構成をオーバーライドすることもできます。以前のリリースでは、plan change-parametersコマンドを使用するときに明示的な値を設定すると正しく動作しましたが、change-policyコマンドを使用するときには正しく動作しませんでした。これが修正され、必要な場合には、javaMiscParamsとcacheSizeのパラメータがデフォルトのメモリー割当ての経験則をオーバーライドするようにchange-policyコマンドを使用できます。[#22097]

  2. ネットワークを利用できないノードで実行されるNoSQL DBのデプロイメントは、NoSQL DBのデモまたはチュートリアルを実行するとき発生するように、次のエラーを返すことがあります。
    java.net.InetAddress.getLocalHost() returned loopback address:<hostname> and
      no suitable address associated with network interfaces.
    
    これは修正されました。[#22252]

APIの変更点

  1. これ以前のリリースでは、書込み操作のときに基底となる永続ストアから例外が発生し、シャードのマスターでは書込みが完了したが、目的のレプリカ組合せでは所定の時間内に完了しなかったと示される場合、その例外は吸収され、クライアントには伝播されませんでした。もともと、この動作が望ましいとみなされていたのは、その例外がまれである(実装によって様々なチェックが先行して実行されるので)という理由に加えて、例外を吸収すると追加の例外やAPIレベルでの追加の通信を回避できるためAPIがシンプルになるという理由からです。検討と議論を重ねた結果、このような例外のために書込み操作が完了しなかったときにはクライアントに通知すべきであるという結論に至りました。その結果、書込み操作中にこのような条件が発生したときには、 RequestTimeoutExceptionがクライアントに伝播されるようになり、基底となる永続ストアからの当初の例外は原因としてラップされるようになります。この例外が発生したときに採用する戦略を含めた詳細は、RequestTimeoutExceptionJavadocを参照してください。

    これは修正されました。[#21210]


  2. 例外とエラー・メッセージでレコードの表示を制御する新しいパラメータが追加されました。hideUserDataをtrueに設定すると(これがデフォルトです)、サーバー側のログに出力される、またはCLIコマンドを通じて表示されるエラー・メッセージは、キー/値を"[hidden]"という文字列に置き換えます。エラーで実際のレコードの内容を見るには、パラメータをfalseに設定してください。[#22376]

ユーティリティとドキュメントの変更点

  1. 以前のリリースでは、NoSQL DBコンポーネントの起動中に<code<>plan deploy-topologyコマンドの結果として発生したエラーに関する情報は、NoSQL DBログ内部でしか表示されないことがあり、インストール時のトラブルシューティングを難しくしていました。このリリースでは、このような起動エラーを管理CLIのshow plan -id <id>コマンドで表示できるようになっています。[#22101]

  2. ストレージ・ノード・エージェントは、デフォルトでないMBeanServerインスタンスでMBeanを公開します。このリリースでは、デフォルトでないMBeanServerが標準JVMプラットフォームのMBeanと、Oracle NoSQL Databaseのみに関連するMBeanを公開するようになります。

  3. SNMPとJMX両方のインタフェースで、新しいtotalRequestsメトリックを使用できます。このメトリックは、サンプリング期間に発生するマルチ操作のシーケンスの数をカウントします。

  4. これ以前のリリースでは、製品のコンパイルとビルドは1.xバージョンのHadoop (CDH3)を想定して行われていました。そのため、以前のリリースを採用しているとき、2.xバージョンのHadoop (CDH4)に基づくクラスタに対してexamples.hadoop.CountMinorKeysサンプルを実行すると、そのサンプルによって開始されるMapReduceジョブがIncompatibleClassChangeErrorのために失敗していました。これは、Hadoop 1.xとHadoop 2.xの間でorg.apache.hadoop.mapreduce.JobContextに発生した非互換性が原因です。このエラーは、Hadoop 1.xとHadoop 2.xのどちらを基準にしてサンプルのコンパイルとビルドを行っても発生します。本製品のカスタマ・ベースで使用されているのはほとんどHadoop 2.xのみなので、このリリースではHadoop 1.xではなくHadoop 2.xをサポートしました。今後のリリースでは、Hadoopの両方のバージョン・パスが再度サポートされる可能性もありますが、その場合にはコードベースとそれに伴うリリース・アーチファクトのリファクタリングが必要となり、現在のビルド・プロセスについても大きな変更が必要になります。

    Hadoop 2.x (CDH4)のサポートを追加しました。[#22157]


  5. java -jar kvstore.jar makebootconfig -mountフラグが-storagedirに変更されました。plan change-mountpoints -path <storage directory>コマンドは非推奨となり、plan change-storagedir -storagedir <storage directory>が推奨されます。[#21880]

  6. ストレージ・ノード容量の概念について、管理者ガイドの記述を改めました。

  7. 管理者ガイドで、NoSQL DBデプロイの操作に必要なリソースの計算方法に関する項を改訂しました。


11gR2.2.0.26での変更点

新機能:

  1. このリリースでは、管理サービスのレプリカを削除する機能が追加されます。複数の管理をデプロイしている場合、次のコマンドを使用してその1つを削除できます。
    plan remove-admin -admin <adminId>
    

    1つの管理インスタンスのみが構成されている場合、その唯一の管理を削除することはできません。

    可用性と永続性の理由から、少なくとも3つの管理インスタンスを常に維持しておくことをお薦めします。そのため、削除の結果として3つを下回るような削除を行おうとした場合、-forceフラグを指定しないかぎりコマンドは失敗します。

    現在マスターである管理を削除しようとすると、マスター権限は別の管理に移動します。プランが中断され、後から新しいマスター管理で再実行できます。中断されたプランを再実行するには、次のコマンドを使用します。

    plan execute -id <planId>
    

  2. 管理CLIのverifyには、単一のストレージ・ノードにホストされているレプリケーション・ノードでメモリー設定がストレージ・ノードのメモリー容量に適合することを検証するチェックが追加されています。これは、システム管理者がデフォルトをオーバーライドして手動でレプリケーション・ノードのヒープサイズを設定している場合に起きうるエラーへの対策です。[#21727]

  3. 管理CLIのverifyコマンドは、検証の問題をすべて違反またはノートと分類します。違反の方が重大度が大きく、システム管理者はその問題に対処するためにシステムの調整方法を決定する必要があります。ノートは、これより重大度が低い警告です。[#21950]

バグ修正:

  1. レイテンシの統計について、いくつか修正を実施しました。修正が適用されるのは、管理コンソールにおけるサービス側統計、CLIのshow perfコマンド、.perfファイルと.csvファイル、そして.getStatsによって返されるクライアント側統計です。ただし、95%から99%の値に対する修正はクライアント側統計には適用されません。これらの値はクライアント側APIには出現しないからです。 [#21763]

  2. -servicerange引数によってポート範囲がmakebootconfigユーティリティに指定されている場合に、ポート範囲からポートを割り当てるように管理プロセスを変更しました。引数を指定しない場合、管理プロセスは使用可能な任意のポートを使用します。Oracle NoSQL Databaseで使用されるポートの構成の詳細は、管理者ガイドを参照してください。[#21962]

  3. ローカルに格納されるトポロジが欠落するというまれなケースに対処するように、レプリケーション・ノードが変更されました。トポロジが欠落すると、TopologyManagerでjava.lang.NullPointerExceptionがスローされ、レプリケーション・ノードは開始できなくなります。[#22015]

  4. ストレージ・ノードで複数のレプリケーション・ノードをホストしている場合に、レプリケーション・ノードのメモリー計算が堅牢になっています。以前のリリースでは、plan change-paramsコマンドを使用して、複数のレプリケーション・ノードをホストしているストレージ・ノードの容量パラメータを小さくすると、レプリケーション・ノード・ヒープが極端に小さくなり、起動時にレプリケーション・ノードがエラーになっていました。トポロジのバランスを再調整する際にこの問題は修正されますが、そのときまでレプリケーション・ノードは使用できなくなっていました。デフォルトのメモリー・サイズ計算で、ストレージ・ノード上にあるレプリケーション・ノードの数が考慮されるようになり、deploy-topologyコマンドによってレプリケーション・ノードが再割当てされるとき、レプリケーション・ノード・ヒープ・サイズが調整されます。[#21942]

  5. レプリケーション・ノードの起動時に、次の例のようにNullPointerExceptionの原因になるバグを修正しました。例外がレプリケーション・ノード・ログに記録され、レプリケーション・ノードは起動に失敗します。この問題が発生する条件としては、複数の異常なレプリケーション・ノードのシャットダウンに伴うシャード間でのパーティション移行などがあります。このバグが発生しても、現在のリリースにアップグレードすれば修正され、データが失われることはありません。
    Exception in thread "main" com.sleepycat.je.EnvironmentFailureException: (JE
    5.0.XX) ...  last LSN=.../... LOG_INTEGRITY: Log information is incorrect,
    problem is likely persistent. Environment is invalid and must be closed.
        at com.sleepycat.je.recovery.RecoveryManager.traceAndThrowException(RecoveryManager.java:2793)
        at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1097)
        at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:587)
        at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:198)
        at com.sleepycat.je.dbi.EnvironmentImpl.finishInit(EnvironmentImpl.java:610)
        at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:208)
        at com.sleepycat.je.Environment.makeEnvironmentImpl(Environment.java:246)
        at com.sleepycat.je.Environment.<init>(Environment.java:227)
        at com.sleepycat.je.Environment.<init>(Environment.java:170)
        ...
    Caused by: java.lang.NullPointerException
        at com.sleepycat.je.log.entry.LNLogEntry.postFetchInit(LNLogEntry.java:406)
        at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:133)
        at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:84)
        at com.sleepycat.je.recovery.RollbackTracker$RollbackPeriod.getChain(RollbackTracker.java:1004)
        at com.sleepycat.je.recovery.RollbackTracker$Scanner.rollback(RollbackTracker.java:477)
        at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1026)
        ... 10 more
    
    [#22052]

  6. RN上のストレージ・エンジン・キャッシュで過剰なメモリーが使用され、キャッシュの退去とI/O増加のためにパフォーマンスが低下するバグが修正されました。この問題が発生するのは、KVStore.storeIteratorまたはKVStore.storeKeysIteratorを使用するときのみでした。[#21973]

パフォーマンスその他の一般的な変更点:

  1. シャードにおけるレプリカは、JEプロパティRepParams.REPLAY_MAX_OPEN_DB_HANDLESを動的に構成するようになります。これは、レプリケーション中にデータベース・ハンドルの保持に使用されるキャッシュのサイズを制御するプロパティです。キャッシュ・サイズは、現在シャードによってホストされているパーティションの数に基づいて動的に決定されます。このキャッシュ・サイズ改善によって、多数のパーティションをホストするシャードの書込みパフォーマンスが向上する可能性があります。[#21967]

  2. クライアントおよびサーバーJARファイルの名前に、リリース・バージョン番号は含まれなくなります。ファイル名は、次のようになります。
    lib/kvstore.jar
    lib/kvclient.jar
    

    この変更により、JARファイルの名前がリリースごとに変わらなくなるため、新しいリリースへの切替えに要する作業負荷が減ります。インストール・ディレクトリの名前には、引き続きリリース・バージョン番号が含まれます。[#22034]


  3. SEVEREレベルのメッセージがログに記録されるようになり、ストレージ・エンジンの平均的なログ・クリーナ(ディスクの再利用)バックログが一定期間で増加すると、管理警告が生成されます。メッセージ・テキストの例は次のとおりです。
    121215 13:48:57:480 SEVERE [...] Average cleaner backlog has grown from 0.0 to
    6.4. If the cleaner continues to be unable to make progress, the JE cache size
    and/or number of cleaner threads are probably too small. If this is not
    corrected, eventually all available disk space will be used.
    
    キャッシュ・サイズを適切に設定してこのような問題を回避する方法の詳細は、管理者ガイドのノード当たりのキャッシュ・サイズの決定に関する項を参照してください。[#21111]

  4. ストレージ・エンジンのログ・クリーナは、アプリケーションが書込み操作を実行していない場合であっても、ログの後半部分を削除するようになります。以前のバージョンでは、前回のアプリケーション書込みより後ろの部分のログを削除することは禁止されていました。ログ・クリーナ・バックログが存在するとき(たとえば、データ・セット・サイズや書込み速度と比較してキャッシュの構成が小さすぎるときなど)には、クリーナが連続的に動作し、ファイルの削除もそれ以降に進むこともできなくなります。[#21069]

  5. NoSQL DB 2.0.23では、R1.2.23に対するパフォーマンス・リグレッションが発生していました。kvstoreクライアント・ライブラリとレプリケーション・ノードが、システムCPU時間を大量に消費していました。このリグレッションは修正されました。[#22096]


11gR2.2.0.23での変更点

新機能:

  1. このリリースでは、デプロイ後にストレージ・ノードをシステムに追加できるようになります。システムのバランスが再調整され、操作を停止せずにデータは新しいノードに再配分されます。詳細は、管理者ガイドの第6章「ストアの構成の決定」を参照してください。
  2. 新しいoracle.kv.lobパッケージにより、音声ファイルや動画ファイルなどのラージ・オブジェクト(LOB)を読み書きできるようになります。一般に、1MBを超えるオブジェクトはすべてLOBとして表すことができます。LOB APIでは、このようなオブジェクトの読取りと書込みにストリーミングAPIを提供することにより、値全体をマテリアライズせずに大きな値にアクセスできます。
  3. C APIが追加されました。実装にはJava JNIが使用されるため、クライアントでJava仮想マシンが稼働している必要があります。これは別途ダウンロードして利用できます。
  4. 新しいremove-storagenodeプランを追加しました。このコマンドは、NoSQL Databaseコンポーネントをホストしていないストレージ・ノードをシステムのトポロジから削除します。これが役に立つ2つの例を次に示します。
    ストレージ・ノードが誤って構成されており、デプロイできない場合。
    ストレージ・ノードが以前はNoSQL Databaseの一部だったが、migrate-storagenodeコマンドですべてのコンポーネントがそこから移行され、ストレージ・ノードの停止が必要になった場合。
    [#20530]
  5. ストレージ・ノードに関して、次のような追加の物理構成情報を指定する機能が追加されました。 この情報は、システムがリソース割当てと消費についてさらにインテリジェントな選択を行うために使用されます。パラメータの設定および使用方法については、管理者ドキュメントを参照してください。[#20951]
  6. Avroサポートを追加しました。キー/値ペアの値は、Avroバイナリ形式で格納できるようになります。Avroスキーマは、格納されるデータのタイプごとに定義されます。Avroスキーマは、データを効率的かつコンパクトにシリアライズし、データがスキーマに準拠していることを保証して、スキーマの経時変化にあわせて自動的なデータの発展を実行します。AvroデータをPOJO (Plain Old Java Object)、JSONオブジェクト、または汎用のMap的なデータ構造を表すことのできるバインディングが導入されています。詳細は、スタート・ガイド第7章「Avroスキーマ」第8章「Avroバインディング」を参照してください。oracle.kv.avroパッケージについては、Javadocで説明されています。Avro形式を使用することをお薦めします。今後のNoSQL DBは、追加の機能を導入するためにAvroを利用する予定です。[#21213]
  7. Hadoop KVInputFormatクラスのサポートを追加しました。新しいoracle.kv.hadoop.KVAvroInputFormatクラスは、AvroのIndexedRecordをコール元に返します。このクラスをOracle Loader for Hadoopと組み合せて使用すると、HDFSにデータを格納するMap-Reduceジョブを暫定的に使用することなく、OLHを使用してNoSQL Databaseから直接データを読み込むことができます。[#21157]
  8. Oracle Databaseの外部表を使用してOracle NoSQL Databaseのレコードをアクセスできる機能を追加しました。詳細は、 oracle.kv.exttabパッケージのJavadocと、 examples/externaltablesディレクトリにあるcookbookサンプルを参照してください。[#20981]

パフォーマンスその他の一般的な変更点:

  1. 次のメソッドが追加されます。 これにより、クライアントはクライアント要求時のソケット・タイムアウトを構成できるようになります。詳細はJavadocを参照してください。

    前述のAPIをクライアントで使用するには、このリリースに付属しているアップグレード・ドキュメントの説明に従って、R1のインストールでストレージ・ノード上のソフトウェアがアップグレードされていることを確認する必要があります。[#20997]

  2. NoSQL Databaseによって作成されたソケットに関連するバックログを制御する新しいサービス・パラメータが追加されました。これらは、レプリケーション・ノードとストレージ・ノードの監視、管理、レジストリ・ハンドラの各インタフェースで制御できます。パラメータは、rnRHSOBacklog (デフォルトは1024)、rnMonitorSOBacklog (デフォルトは0)、rnAdminSOBacklog (デフォルトは0)、rnAdminSOBacklog (デフォルトは0)、snAdminSOBacklog (デフォルトは0)、snMonitorSOBacklog (デフォルトは0)およびsnRegistrySOBacklog (デフォルトは1024)です。[#21322]
  3. 以前のバージョンでは、ターゲットのKeyオブジェクトより小さいメジャーまたはマイナー・パスを含む引数を指定してKey.isPrefixをコールすると、特定のケースでIndexOutOfBoundsExceptionが発生していました。これは修正されました。
  4. KeyRange()コンストラクタは、最初のKeyが最後のKeyがより小さいかどうかをチェックします。これは最初と最後の両方が指定されている場合であり、指定されていない場合にはIllegalArgumentExceptionがスローされます。KeyRangeにも、KeyRangeインスタンスのエンコードとデコードに使用するtoString()fromString()の2つのメソッドがあります。これはKeyの同じメソッドに似ています。[#21470]

ユーティリティの変更点:

  1. CLIには多くのコマンドが新しく追加されています。詳細は、管理者ガイド付録A「コマンドライン・インタフェース(CLI)のコマンド・リファレンス」を参照してください。
  2. 管理コンソールは管理専用になります。
  3. CLIの管理コマンドは、トポロジ表示に使用されるIDにコンポーネントIDが一致するように変更されました。以前のバージョンでは、データセンター、ストレージ・ノード、管理インスタンス、レプリケーション・ノードがそれぞれ名前のみで識別されていました。たとえば、ストレージ・ノード17をストレージ・ノード・プールに追加する構文、または指定したレプリケーション・ノードのパラメータを表示する構文は、次のとおりでした。
    joinPool myStorageNodePool 17
    show repnode-params 5,3
    
    データセンターは、#またはdc#と表せるようになります。
    管理インスタンスは、#またはadmin#と表せます。
    ストレージ・ノードは、#またはsn#と表せます。
    レプリケーション・ノードは、groupNum,nodeNumまたはrgX-rnYと表せるようになります。

    上に示したコマンドは現在も有効ですが、次のように表すこともできます。

    joinPool myStorageNodePool sn17
    show repnode-params rg5-rn3
    
    [#21099]

ドキュメント、インストール、統合:

  1. Key.createKeyメソッドのJavadocが更新され、パラメータとして渡されるListインスタンスはメソッドのコール後にKeyオブジェクトによって所有されるという警告が追記されました。予期しない結果を避けるために、これは変更しないでください。[#20530]


11gR2.1.2.123での変更点

バグ修正:

  1. 以前のバージョンでは、管理サービスを実行している以外のノードでレプリケーション・ノード・パラメータを変更しようとしてchange-repnode-paramsプランを実行すると、エラーになりました。この操作が正常に処理されるようになります。[#20901]

  2. 新しいストレージ・ノードをデプロイしようとしてdeploy-storage-nodeプランで問題が発生すると、問題のあるストレージ・ノードがストアに残っていました。そのため、ユーザーは問題のあるストレージ・ノードを手動で削除するか、問題を修正してプランを再試行する必要がありました。便宜上、deploy-storage-nodeプランは現在、エラー発生時にクリーン・アップされるようになり、問題のあるストレージ・ノードは残らなくなっています。[#20530]

パフォーマンスその他の一般的な変更点:

  1. コマンドライン・インタフェースで、snapshot createコマンドの速度が大幅に向上しました。以前のバージョンでは、大量のデータがあるストアで実行すると数分間かかっていました。これが秒単位に短縮されています。[#20772]

ユーティリティの変更点:

  1. kvliteを起動して制御コマンドを実行する2つのスクリプト、bin/run-kvlite.shおよびbin/kvctlは、java -jar lib/kvstore-M.N.P.jarコマンドに置き換えられます。これにより、Windowsを含むすべてのJavaプラットフォームの移植性が実現します。2つのスクリプトは非推奨となりましたが、少なくとも1リリース・サイクルの間はサポートされます。

    古いスクリプト・コマンドから新しい-jarコマンドへの変換は、次のとおりです。

    古いスクリプト・コマンド新しい-jarコマンド
    bin/run-kvlite.sh args... java -jar lib/kvstore-M.N.P.jar kvlite args...
    bin/kvctl command args... java -jar lib/kvstore-M.N.P.jar command args...

    新旧のコマンドには、注意が必要な相違点がいくつかあります。