Oracle NoSQL Databaseに関するよくある質問(FAQ)

詳細はこちらからご確認下さい。

はい、Oracle NoSQLはOpenJDKと認証されています。こちらのリリース・ノートをご覧ください。

ストア・デプロイメントは多くのコンポーネントで構成され、それぞれが独自のプロセスで実行され、互いに通信します。システム管理者は、各ストレージ・ノード(SN)のプロセスのタイプごとに、次のTCP/IPポートを定義する必要があります。

• 各SNのメイン・ポートは、ストレージ・ノード・エージェント(SNA)が持つレジストリ・ポートです。これは、java -jar kvstore.jar makebootconfigコマンドの"-port"引数によって指定されるポートです。これは、構成時にdeploy-sn計画でも使用されます。ドキュメントの例では、レジストリ・ポートとして5000を使用しています。また、java -jar kvstore.jar kvliteコマンドはデフォルト値としてポート5000を使用します。
• 各管理者プロセスは、HTTP連携をリスニングするポート（「管理者コンソールポート」）が必要です（4.3以前）。これは、java -jar kvstore.jar makebootconfigコマンドの"-admin"引数、および構成中のdeploy-admin計画（4.3以前）で指定されます。

  ドキュメントの例では5001を使用しています。

• 各SNには、そのSN内でホストされているレプリケーション・ノードおよび管理サービスが永続データのレプリケーションに使用するポートの範囲（「HA範囲」）を指定する必要があります。SNAはこのポートの割り当てを管理し、1つを管理サービスに確保し、残りをRNごとに1つずつ割り当てます。範囲のサイズは、このSNがホスティングするRNの最大数に1を加えた値に等しくなるように設定する必要があります。

レジストリ・ポートは次の状況で使用する必要があります。

• ストアの初期構成を含む、あらゆる管理コマンドライン・インターフェース(the java -jar kvstore.jar runadmin command)の使用。最終的には管理者プロセスと通信することになりますが、この状況で使用するのは管理コンソール・ポート（4.3以前）ではなくレジストリ・ポートであることにご注意ください。
• ストアに読み込み/書き込みを行うアプリケーション・コードのKVStoreConfigコンストラクタのhelperHostPort引数の一部として指定します。
• コマンドラインで"-port"とともに渡される値として、Load、Ping、KVLiteなどのユーティリティを呼び出します。
• JMXモニタリングが有効な場合、JMXサービスのポート番号として。

HelloBigDataWorldやSchemaExampleなどのプログラムの例も同様です。

管理Web UIのターゲットURLで管理コンソール・ポート(4.3以前)を使用する必要があります。

							 http://node1.example.com:5001/ 
						

通常、リーチしようとしているタイプのコンポーネントをホストしているあらゆるSNのポートを指定することができ、必要であれば、システムは自動的に透過的にリクエストをリダイレクトします。管理コンソールの Web UI (4.3 以前) と java -jar kvstore.jar runadmin コマンドの場合、これは、管理プロセスをホストするSNを指定しているかぎり機能します。

SNの構成中以外は、通常、HA範囲のポートを直接参照する必要はありませんが、Pingの結果 を検証したり、システムのログファイルを参照したりする際には、HA範囲を理解しておくと役立つ ことは間違いありません。

通常、セキュリティ・ポリシーやデータセンター・ポリシーの理由から、導入時にストアを限られたポートセットに制限する必要がある場合があります。ストレージ・ノードでは、これらのポートの使用を制限するために2つのポート範囲を指定できます。

• -harange <start、end>を使用してmakebootconfigで指定されるhaPortRangeパラメータ。これはレプリケーション係数が1以上の場合にレプリケーションに使用され、ストレージ・ノードに1を加えた容量を満たすだけのポートが必要です。
• makebootconfig で-servicerange <start,end> を使用して指定した servicePortRangeパラメータ。この範囲は、内部（管理）サーバー間の低帯域幅通信に使用され、ストレージ・ノード・エージェント・プロセス自体を含む、ストレージ・ノードがホストする各プロセスのサービス数に基づいています。このパラメータはオプションであり、指定されていない場合は匿名ポートが使用されます。

上記の範囲は包括的です。

haPortRangeのサイズは前述のとおりです。servicePortRangeのサイズ設定は次のとおりです。

• ストレージ・ノード・プロセス用の3つのポート
• 3 *レプリケーション・ノードの容量(各レプリケーション・ノードは3つのポートを使用)
• ストレージ・ノードが管理プロセスをホスティングしている場合は2

前述の情報を使用して、容量2を持ち、管理者をホストするストレージ・ノードには、サイズ3 + (2 * 3) + 2 = 11の範囲が必要です。ストレージ・ノードでは、この式に基づいて最小サイズが適用されます。範囲のサイズは少し大きくすることをお勧めします。

makebootconfigの-hostnameパラメータは、各ストレージ・ノードで使用されるネットワーク・インタフェースに影響します。makebootconfigにオプションの-hahostフラグを使用して、haHostnameストレージ・ノード・パラメータを設定できます。これは、トラフィックが最も多いサーバー/サーバー通信チャネルの追加のネットワーク・インタフェースを指定するために使用します。-hahostのデフォルト値は-hostnameと同じ値です。

レプリケーションノードはNoSQL DBストアのデータを管理し、メモリを大量に消費します。レプリケーション・ノードで使用されるJavaヒープおよびキャッシュ・サイズは、重要なパフォーマンス要因になる場合があります。デフォルトでは、レプリケーション・ノードのヒープおよびキャッシュは、ストレージ・ノードで使用可能なメモリー量に基づいてNoSQL DBによって計算されます。

makebootconfigの-memory_mbフラグまたはmemory_mbストレージ・ノード・パラメータを使用して、ストレージ・ノードに使用可能なメモリーを指定することをお薦めします。memory_mbを定義しない場合、ノードで使用可能なメモリーがデフォルトで設定されます。NoSQL DBはそのストレージ・ノードがホストするレプリケーション・ノード・プロセスのヒープとしてmemory_mbの85%を使用します。ストレージ・ノードが複数のレプリケーション・ノードをホストしている場合、メモリはすべてのRNで均等に分割されます。ストレージ・ノードのレプリケーション・ノードの数が変更されると、RN単位のメモリーが動的に再計算されます。ヒープに使用される割合は、rnHeapPercentストレージ・ノード・パラメータにより管理されます。デフォルト値の85%を上書きすることができます。

各レプリケーション・ノードはキャッシュを使用し、そのキャッシュのサイズはレプリケーション・ノード・ヒープの70%にデフォルト設定されます。rnCachePercentレプリケーション・ノード・パラメータを設定することで、デフォルトの70%を上書きできます。

レプリケーション・ノードのヒープは、レプリケーション・ノードのjavaMiscParamsパラメータで-Xmxを設定することにより直接設定することもできます。同様に、レプリケーション・ノードのキャッシュは、cacheSize レプリケーション・ノード・パラメータで直接設定できます。これは可能ではあるものの、ストレージ・ノードのmemory_mb設定のご利用をお薦めします。

たとえば、memory_mbを3000に設定して、ストレージ・ノードが3000MBのメモリーを使用できるように指定するとします。そのストレージ・ノードが2つのレプリケーション・ノードをホストしている場合、各RNのヒープは(3000 * .85)/2 = 1275MBになります。各RNキャッシュは(1275 * .70) = 892MBになります。

NoSQL DBの管理プロセスは、信頼性を高めるためにレプリケーションされます。ノードに障害が発生しても管理機能を利用し続け、問題のモニター、トラブルシューティング、修復を継続できるようにすることが重要です。

各管理サービスは、deploy-admin計画によって作成され、NoSQL DBに追加されます。管理者はメタデータをレプリケーションされたストアに保存するため、管理ガイドの「レプリケーション係数を特定する」セクションで提供する情報は、配備すべき管理サービスの数にも当てはまります。耐久性と可用性のために、少なくとも3つの管理サービスを導入することを強くお勧めします。導入で管理サービスが1つないし2つのみで、1つのサービスがダウンした場合、多くの種類の管理コマンドが実行できなくなります。

少なくとも3つの管理サービスが実行されている場合は、最初にターゲット・ストレージ・ノードに4番目の管理サービスを導入してから、remove-admin計画を使用して元の3つのいずれかを削除することで、それらのいずれかをストレージ・ノード間で簡単に移動できます。

可用性およびパフォーマンス上の理由から、クラスタ内のノードごとにストレージ・ノード(SN)を1つ割り当てることを強くお薦めします。特定のノードに複数のレプリケーション・ノードをホストするI/OおよびCPUリソースがあると考えられる場合は、ストレージ・ノードの容量パラメータを1より大きい値に設定でき、このSNで複数のRNがホストされていることがわかります。このようにして、次のことが可能になります。

• シャード内の各レプリケーション・ノードが異なるストレージ・ノード上でホスティングされるようにすることで、シャードの障害に対する脆弱性を低減
• メモリーとその他のハードウェア・リソースをレプリケーション・ノード間で動的に分割
• ストアの書き込み操作をサービスするマスター・レプリケーション・ノードが、スタートアップ時とフェイルオーバー後の両方でストレージノードに均等に分散されるようにします。

同じノードで複数のSNがホストされている場合、そのノードに障害が発生すると複数のSNが失われ、データにアクセスできなくなる可能性があります。

ストレージ・ノードの容量パラメータは、いくつかの方法で設定できます。

• makebootconfigコマンドを使用する場合
• change-policyコマンドを使用
• plan change-params commmandを使用

初期のプロトタイピングや実験など、非常に限られた状況では、同じノード上に複数のSNを作成することが役立つことがあります。

単一マシンでは、ストレージ・ノードはそのルート・ディレクトリ(KVROOT)と構成ファイル名(デフォルトはconfig.xml)によって一意に識別されます。つまり、次の方法で複数のSNを作成できます。

SNごとに一意のKVROOTを作成します。通常、これらは異なるノード上にありますが、単一のノード上に配置することもできます。たとえば、すべてのSNをディレクトリ/var/kv/storesに配置する場合は、次のように複数のSNを作成して起動できます。

							mkdir /var/kv/stores/root1 mkdir /var/kv/stores/root2 mkdir /var/kv/stores/root3 java -jar kvstore.jar makebootconfig -root /var/kv/stores/root1 -host fooHost -port 5000 -admin 5001 -harange 5005,5010 -capacity 1 java -jar kvstore.jar makebootconfig -root /var/kv/stores/root2 -host fooHost -port 5020 -harange 5025,5030 -capacity 1 java -jar kvstore.jar makebootconfig -root /var/kv/stores/root3 -host fooHost -port 5040 -harange 5045,5050 -capacity 1 java -jar kvstore.jar start -root /var/kv/stores/root1 java -jar kvstore.jar start -root /var/kv/stores/root2 java -jar kvstore.jar start -root /var/kv/stores/root3 
						

テスト目的で同じNoSQL DB構成を繰り返し構築することが必要な場合があります。管理CLIコマンドは、複数の異なる方法でスクリプト化できます。

管理CLIの多くの用途は、前述のStorageNodeを最初に構成するためのjava -jar kvstore.jar makebootconfigなどの単純なコマンドです。これらは、ほかのUNIXコマンドと同様にスクリプト化できるので、ここではこれ以上説明しません。

java -jar kvstore.jar runadminで利用可能なインタラクティブなコマンドのうち、計画の作成と実行に役立つコマンドは、2つの方法でスクリプト化することができます。実行する一連のコマンドを含むファイルを作成し、java -jar kvstore.jar runadmin load -file <script>を使用してバッチで実行できます。

たとえば、deploy.kvsという名前のスクリプト・ファイルには、次のようなコマンドを含めることができます。

							 configure -name mystore plan deploy-zone -name boston -rf 3 plan deploy-sn -dcname boston -host localhost -port 5000 -wait plan deploy-admin -sn sn1 -port 5001 -wait (port argument is applicable prior to 4.3. only) 
						

このスクリプトを実行するには、コマンドを発行します。

							 java -jar kvstore.jar runadmin -host localhost -port 5000 load -file deploy.kvs 
						

コマンドをスクリプト化するもう1つの方法は、個々のCLIコマンドを個別のシェルコマンド・ラインとして実行することです。このコマンド・ラインの最後の引数は、単一のCLIコマンドと見なされます。

この使用モードでは、UNIXシェルなどのより効率的なスクリプト言語の機能を使用でき、インタラクティブなjava -jar kvstore.jar runadmin環境では使用できない他のコマンドとNoSQL DBコマンドを統合する柔軟性が高まります。

上の例と同じ一連のコマンドをシェルスクリプトにすると、このようになります：

							 #!/bin/sh HOST=localhost PORT=5000 HTTPPORT=5001 KVADMIN="java -jar lib/kvstore.jar runadmin -host $HOST -port $PORT" # Each CLI command that follows "$KVADMIN" is executed in a new invocation of runAdmin $KVADMIN configure -name mystore $KVADMIN plan deploy-datacenter -name boston -rf 3 -wait $KVADMIN plan deploy-sn -dcname boston -host localhost -port $PORT -wait $KVADMIN plan deploy-admin -sn sn1 -port $HTTPPORT -wait 
						

Oracle NoSQL Database Migratorの使用

Oracle NoSQL Database Migratorは、Oracle NoSQL表をデータ・ソースから別のデータ・ソースへの移行を可能にするツールです。このツールは、Oracle NoSQL Database Cloud ServiceおよびOracle NoSQL DatabaseのオンプレミスおよびAWS S3の表で操作できます。移行ツールは、いくつかの異なるデータ形式と物理メディアタイプをサポートしています。サポートされているデータ形式は、JSON、Parquet、MongoDB形式のJSONおよびDynamoDB形式のJSONです。サポートされている物理メディア・タイプは、ファイル、OCI Object Storage、Oracle NoSQL Databaseオンプレミス、Oracle NoSQL Database Cloud ServiceおよびAWS S3です。

NoSQL DatabaseはOracle Databaseの外部表関数によるレコードの取得をサポートしています。これにより、Oracle Databaseから一部のクエリを実行し、NoSQL Databaseからレコードを取得することができます。詳細は、オラクルの外部表についての解説書によるOracle NoSQL Databaseへのアクセスをご参照ください。

アプリケーション開発プロセスで重要なのは、データをモデリングする作業です。

データの適切なモデリングは、アプリケーションのパフォーマンス、拡張性、アプリケーションの正確性、そして最後に、豊富なユーザー・エクスペリエンスをサポートするアプリケーションの機能に不可欠です。

Oracle NoSQL Database は、アプリケーション・データのモデリングに関して、データ・モデラーに幅広い柔軟性をもたらします。各レベルの柔軟性に関連するトレードオフを理解することは、データ・モデリングに関する賢明な意思決定に非常に役立ちます。

詳細はこちらからご確認下さい。

KVLocalは、大規模なデータセットからのライブ・データを処理および表示するために、豊富なデータ・アプリケーションで使用できる組み込みのOracle NoSQL Databaseです。KVLocalはレプリケーションされない単一ノード・ストアを提供します。

アプリケーションJVMの独立した子プロセスとして実行され、最小限の管理しか必要となりません。KVLocalは堅牢なデータベースで、障害を効率的に処理します。APIを使用してKVLocalを起動および停止できます。

KVLocalは、アプリケーションのクラスパスにkvstore.jarを含め、JVMを起動し、データベースを初期化するAPIを呼び出すことで、Oracle NoSQL Databaseの単一インスタンスを実行する機能を提供します。

Oracle NoSQL Database は以下のインデックスタイプをサポートしています。
- シンプル・インデックス:配列や マップにインデックスを作成しないインデックスをシンプル・インデックスと呼びます。
- マルチキー・インデックス: 複マルチキー・インデックスは、テーブルの各行で1つ以上の配列やマップのすべての要素/エントリをインデックス作成するために使用されます。表の各行にマップします。
- JSONデータ・インデックスインデックスが、jsonデータに含まれる少なくとも 1 つのフィールドにインデックスを作成する場合、そのインデックスはjsonインデックスです。
- データ・インデックス: ジオメトリ・オブジェクトへのパスを含むインデックス。また、ジオメトリ・インデックスとも呼ばれます。
- 関数のインデックス1つ以上のSQL組み込み関数の値にインデックスを作成することができます。Oracle NoSQL Databaseは、Elastic Searchとの統合により、もサポートしています。
 -  全文検索：:全文検索は、クエリを満たす自然言語ドキュメントを特定し、オプションでクエリとの関連性でソートする機能を提供します。オンプレミス・バージョンでのみ使用可能です。

Oracle NoSQL Databaseアプリケーションは、Oracle NoSQL Databaseデータストアに対してネットワークリクエストを実行することで、データの読み取りと書き込みを行います。組織は、NoSQLデータを維持するために、複数のKVStoresを設定する必要がある場合があります。これらのKVStoreクラスタは、地理的に分散している場合もあります。Oracle NoSQL Databaseのマルチリージョン・アーキテクチャでは、複数のKVStoreクラスタに表を作成し、これらのクラスタ全体で一貫したデータを保持できます。

複数のリージョンにわたり同様のデータを収集し、メンテナンスしたいとします。複数のリージョンにまたがる表を作成し、すべての参加リージョンからの入力で自身を更新するメカニズムが必要です。これらを実現するには、複数リージョン表を使用します。複数リージョン表またはMR表は、異なるリージョンまたはインストールに格納および管理されるグローバル論理表です。これは、複数のリージョンに存在する、どこからでも読み書きが可能な表です。

Oracle NoSQLでは、最新の書込みがサポートされています。競合の検出と解決の問題に対処する革新的な方法は、競合が発生しないようにすることです。

Oracle NoSQL Database は、マルチリージョン表で使用するための新しいCRDTタイプ(競合のないレプリケーション・データ型) を導入しました。CRDTは、共通のプロパティを持つレプリケーション・データ型のファミリーで、そのデータ型に対して行われる操作は、すべてのレプリカ間で常に正しく一貫性のある共通の状態に収束します。

マルチリージョン表を作成し、JSON列のフィールドをMR_COUNTERデータ型として宣言できます。

Oracle NoSQL Database では、行の
関数がサポートされます — modification_time関数を使用すると、行
の最新の変更時間(UTC)を表示できます — shard関数を使用すると、データの特定の行が格納されているシャードIDを取得できます
— partition関数を使用すると、パーティションIDを表示できますデータの特定の行が格納される場所。
— row_storage_size関数を使用すると、指定されたデータ行で使用される永続ストレージ・サイズ(バイト単位)を表示できます
— index_storage_size関数を使用すると、指定されたデータ行の索引で使用される永続ストレージ・サイズ(バイト単位)を表示できます

すべてのNoSQLデータベースには、密接に関連するデータの豊富な構造である基本的な記憶域単位があります。キー/値ストアの場合は値、ドキュメント・ストアの場合はドキュメント、列ファミリの場合は列ファミリーです。デザイン用語では、このデータ・グループをアグリゲーターと呼びます。

Oracle NoSQL Databaseでは、複合データ型(配列、マップなど)がサポートされています。親行ごとに、一致する子行は配列またはマップ内の親行自体に格納できると考えられます。ただし、これを行うと親行が非常に大きくなり、パフォーマンスが低下する可能性があります。これは特に、NoSQLデータベース・ストアのアペンド・オンリーのアーキテクチャに当てはまり、行が更新されるたびに行全体の新しいバージョンが作成されることを意味します(詳細についてはこちら)

Oracle NoSQL Databaseにある階層表は、

— 書込みが多いワークロードの場合、非常に効率的です。
— また、より柔軟で、緻密な認可が可能です。認証は、リソースにアクセスするためにユーザーに付与される権限です。緻密な認証では、リソースに対してユーザーに付与されるアクセス権は、実行時に条件によって異なる場合があります。階層構造では、親テーブルに与えられるアクセス権と子テーブルに与えられるアクセス権が異なる場合があります。

Oracle NoSQLデータベースでは、同じ階層の表を結合する方法が2つあります。

KVStore.multiDelete()メソッドは、サブツリー全体を削除できますが、一度に1つの(完全指定の)メジャー・キーでのみ削除できます。

より大きなサブツリーを削除するには、メジャー・キー階層内の上位にあるstoreKeysIteratorを使用して、削除する各メジャー・キーを見つけ、それぞれに対してmultiDelete() を呼び出します。

storeKeysIteratorの終了が許可されている場合、各メジャー・キー内のマイナー・キーを含む、希望するサブツリー範囲のあらゆるキーを反復します。したがって、イテレータから最初の結果キーだけを取り出し、 multiDelete()を呼び出すために主要なキー部分を抽出し、単一のイテレータをすべて繰り返すのではなく、イテレータを破棄して新しいイテレータでやり直すことがコツです。

これを次のサンプル・コードに示します。

キー partialKey = ...; //メジャーキープレフィックス/* *イテレータごとに複数のキーを取らないため、*バッチサイズが大きくなると無駄になります。*/最後のint batchSize = 1; for (;;) { Iterator<Key> i = kv.storeKeysIterator (Direction.UNORDERED、 batchSize、 partialKey、 null、 Depth.DESCENDANTS_ONLY); if (!i.hasNext()) { break; }キー子孫= Key.createKey(i.next().getMajorPath()); kv.multiDelete(子孫、 null、 Depth.PARENT_AND_DESCENDANTS); }

表のINTEGER、LONGまたはNUMBER列は、アイデンティティ列として定義できます。システムでは、シーケンス・ジェネレータを使用してアイデンティティ列の値を自動的に生成できます。詳細については、「シーケンス・ジェネレータ」をご確認ください。

汎用一意識別子(UUID)は、コンピューター・システム内の情報を識別するために使用される128ビット番号です。Oracle NoSQLでは、UUID値はUUIDデータ型で表されます。このUUIDカラムはGENERATED BY DEFAULTとして定義することができます。UUIDカラムに値を指定しなかった場合、システムは自動的にUUIDカラムの値を生成します。

クライアントAPIで定義されたほとんどの例外は、実行時例外です。チェック例外を使用しない設計ポリシーまたは理由はありますか。

チェックされた例外は、ある意味で異なるタイプの戻り値であるため、常に即時のコール元で処理する必要がある場合にのみ適切です。これらは「偶発」と呼ばれます。たとえば、oracle.kv.OperationExecutionExceptionには、マルチ操作要求での操作の戻り値に関する情報が含まれます。偶発的事態による例外は、呼び出し元が戻り値を処理するのと同様に、呼び出し元が明示的に例外を処理するように要求するために、チェックされた例外です。

その他の例外は「フォルト」と呼ばれ、通常、呼び出し元が直接処理できない問題の結果であり、通常は異常なイベントによって引き起こされます。これらは操作の再試行を引き起こす場合がありますが、多くの場合、（直接の呼び出し元ではなく）上位のレベルで処理されます。これらは即時呼び出し元によって処理されないため、実行時例外です。これにより、クライアント・アプリケーションのすべてのメソッドが、これらのメソッドには関係ない例外のthrows宣言で煩雑になることを回避します。

現在、NoSQL DBの偶発(チェック)例外はOperationExecutionExceptionのみであり、その他の例外はフォルト(実行時)例外です。各例外は、oracle.kv.FaultExceptionまたはoracle.kv.ContingencyExceptionを拡張して、この特性を明確にします。

偶発的事態とフォルトによる例外に関する一般的な情報については、 こちらで説明されています。

最近（ここ数年）、ほとんどのプログラマーは実行時例外を好んでおり、最近設計されたプログラミング言語の大半にはチェック例外の機能がないことにご注意ください。つまり、現在のトレンドは実行時例外処理です。もちろん、すべてのプログラマーやプログラミング言語設計者がこの点に賛成しているわけではありません。NoSQL DB は、適宜、偶発的な例外を追加するオプションを留保します。

このトピックには、オラクルからのサポート・ノートがあります。こちらをご覧ください：http://support.oracle.com/rs?type=doc&id=2227233.1

- CEディストリビューションの場合は、プロキシを手動で起動するときにuser.securityファイルを指定します。例: java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port> -store <storename> -username admin -security <path>/user.security

- EEディストリビューションはwalletを使用するため、クラスパスにoraclepki.jarを設定することに加えて、プロキシを手動で起動する際にuser.securityファイルを指定します。例: java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port> -store <storename> -username admin -security <path>/user.security

Oracle NoSQL Databaseサーバーは、Java SE 11と互換性があります。クライアントもサーバーも、少なくともJava SE 11を必要としますが、最近のJava SEバージョンでも動作する必要があります。特に、クライアントとサーバーは、長期サポート(LTS)リリースであるOracle Java SE 21.0.2とOpenJDK 21.0.2に対してテストされ、認証されています。最新のバグ修正とパフォーマンス向上を活用するために、Java SE 21へのアップグレードを推奨します。

こちらのリリース・ノートをご覧ください。

Oracle NoSQL Databaseリリース1と2には、Java SE 6以降のJavaランタイムが必要です。リリース3にはJava SE 7以上が必要です。Oracle NoSQL Datatabaseリリース4には、Java SE 8以上が必要です。次のようなエラー・メッセージが表示された場合は、以前のバージョンのJavaで実行しようとしている可能性があります。

スレッド「main」での例外java.lang.UnsupportedClassVersionError： .classファイルに不正なバージョン番号があります。

または

スレッド「main」での例外java.lang.UnsupportedClassVersionError: oracle/kv/impl/util/KVStoreMain : サポートされていないメジャー.マイナーバージョン 51.0

管理コマンドの進行状況を追跡する方法はいくつかあります。

• show plan -id <id>は、コマンドの最新のステータスを表示します。

• show topologyコマンドは、ストアの現在のレイアウトと、現時点で存在するNoSQL DBサービスを表示します。

• 管理コンソールの「トポロジ」タブ(4.3以前)は、NoSQL DBサービスが作成され、オンラインになったときにリフレッシュされます。

• 検証コマンドは、「トポロジ」タブ(4.3より前)または計画の実行中の管理CLIを介して同時に発行できます。検証では、サービスの起動時にサービス・ステータス情報が提供されます。

• ストア全体のログは、管理コンソールの「ログ」タブ(4.3より前)またはCLIのlogtailコマンドを介して追跡できます。

管理計画のエラー情報は、計画の実行および終了時に取得可能です。計画の実行が失敗するたびに、計画履歴にエラーが報告されます。計画履歴は、コマンドライン・インタフェースKVAdmin（"java -jar kvstore.jar runadmin "または単に「CLI」としても知られる）show plan -id <id>コマンド、または管理コンソール（4.3以前）の計画と構成タブでご確認いただきます。-verboseフラグを使用すると、詳細が追加されます。

その他の問題は非同期的に発生する可能性があります。管理コンソールの「ログ」タブ(4.3より前)またはCLIのshow eventsコマンドを使用して、予期しない障害、サービスの停止時間およびパフォーマンス問題の概要をご確認いただけます。イベントにはタイムスタンプが付属しており、説明には問題を診断するための十分な情報が含まれている場合があります。場合によっては、より多くのコンテキストが必要になり、管理者はその時間に何が起こったかを確認求める場合があります。

ストア全体のログは、すべてのサービスからのロギング出力を統合します。このファイルを参照すると、管理者は、問題のある期間中のアクティビティをより詳細に把握できます。管理コンソールの「ログ」タブ(4.3以前)またはCLIのlogtailコマンドを使用するか、<KVHOME>/<storename>/logディレクトリの<storename>_N.logファイルを直接表示することで表示できます。管理コンソールの「ログ」タブを使用して、ストア全体のログ・ファイルをダウンロードすることもできます。

KVROOT/<store_name>?logディレクトリの.logファイルには、各NoSQL DBコンポーネントからのトレース・メッセージが含まれます。各行の先頭には、メッセージの日付、重大度、およびメッセージを発行したコンポーネントの名前が付きます。例:

10-01-11 08:39:43:548 UTC INFO [admin1]店舗の管理を初期化しています: kvstore

行フォーマットはMM-dd-yy HH:mm:ss:SSS <java.util.logging.Level> [コンポーネント名]メッセージです。特定の時間にイベントについてより多くのコンテキストを検索する場合は、タイムスタンプとコンポーネント名を使用してログのセクションを絞り込んで使用してください。重大な例外は、SEVEREログ・レベルとともに記録され、管理コンソールおよびCLI (java -jar kvstore.jar runadmin) show events コマンドで使用できます。

管理サービスは、サーバー側のスループットおよびレイテンシ統計をレプリケーション・ノードごとに収集します。これらの統計は、管理コンソールの「トポロジ」タブ(4.3より前)、コマンドライン・インタフェース(CLI) show perfコマンド、およびマスター管理サービスのKVROOTログ・ディレクトリで使用可能な<storename>.perfファイルで確認できます。.perfファイルは、管理コンソールを使用して検索およびダウンロードできます。

スループットとレイテンシは、statsIntervalレプリケーション・ノード・パラメータ（デフォルトは60秒）によって決定される時間間隔で計算されます。.perfファイルの各行は、1つのレプリケーション・ノードの1つの統計間隔のものです。また、各行は1つのオプタイプ・カテゴリーに適用されます。

単一および複数という2つのオプトタイプは、様々なデータ操作のパフォーマンス特性を理解するために使用されます。クライアントAPIデータ操作の中には、1つのデータ・レコードに関連するものと、1つ以上のレコードに関連するものがあります。たとえば、KVStore.get() メソッドは1つのデータ・レコードをフェッチしますが、KVStore.multiGet() は1つ以上のレコードをフェッチします。すべての単一レコード操作は集計され、opype Singleとして記録されますが、すべての複数レコード操作はopype Multiとしてレポートされます。

NoSQL 2.0.25では、待機時間情報はリクエストごとに計算されます。複数操作では、レコードごとのオーバーヘッドを多数のレコードにわたって償却できるため、単一レコード操作よりも大幅に効率化できます。その違いの明確化を支援するために、オプトタイプごとに統計をとっています。

たとえば、アプリケーションが1つの間隔でKVStore.get()、KVStore.put()、KVStore.putIfVersion()、およびKVStore.multiGet()操作を発行した場合、すべてのmultiGetは1つのMulti統計行として記録され、他のすべての操作は1つのSingle統計行としてまとめて記録されます。

各カラムには、次の列があります。

リソース: レプリケーション・ノードの名前時間: MM/HH/YY hh:mm:ss OpTypeとして書式設定された統計間隔の開始: 単一または複数

インターバル・パフォーマンス統計:

合計操作数: 統計間隔PerSec中に実行されたそのオプトタイプのデータ・レコード数: その間隔の1秒当たりのデータ・レコード数合計要求: 単一オプトタイプの場合、操作数およびリクエスト数は間隔ごとに同じです。複数オプトタイプでは、各リクエストが複数のレコードを返す可能性があるため、操作数はリクエスト数以上になる場合があります。最小: RNプロセス・ライフタイムのミリ単位での最小リクエスト・レイテンシ、最大: RNプロセス・ライフタイムのミリ単位での最大リクエスト・レイテンシ: 平均リクエスト・レイテンシ、95:RNプロセス・ライフタイムのミリ単位での95パーセンタイルの運用のレイテンシ99:RNプロセス・ライフタイムのミリ単位での99パーセンタイルの運用のレイテンシ

累積パフォーマンス統計：

合計操作数: レプリケーション・ノード・プロセスの存続期間中に実行されたそのオプトタイプの操作の数。累積値は、レプリケーション・ノードが再起動するたびにリセットされます。PerSec: RNプロセス存続期間の1秒当たりの操作数要求合計: 単一オプトタイプの場合、操作数とリクエスト数は同じです。複数オプトタイプでは、各リクエストが複数のレコードを返す可能性があるため、操作数はリクエスト数以上になる場合があります。最小: RNプロセス寿命の最小レイテンシ(ミリ秒単位) 最大の最小レイテンシ（ミリ秒）: RNプロセス存続期間平均の最大レイテンシ（ミリ秒）: RNプロセス存続期間95の平均レイテンシ（ミリ秒）：RNプロセス存続期間99の95パーセンタイルでの操作のレイテンシ、つまりRNプロセス存続期間99パーセンタイルの場合：RNプロセス存続期間に対する99パーセンタイルでの運用のレイテンシ。

NoSQL DBサービスには、管理、ストレージ・ノードおよびレプリケーション・ノードの3つのタイプがあります。各サービスには、管理コンソールの「トポロジ」タブ(4.3以前)、CLIのshow topologyコマンド(java -jar kvstore.jar runadmin)、またはjava -jar kvstore.jar pingを介して表示されるステータスがあります。

ステータス値は次のとおりです。

健全なサービスはSTARTINGで開始します。RUNNINGに移行する前に、短期間WAITING_FOR_DEPLOYに移行することがあります。ERROR_RESTARTINGとERROR_NO_RESTARTは調査すべき問題があったことを示します。UNREACHABLEサービスは一時的にその状態になっているだけの場合がありますが、その状態が続く場合は、サービスが本当にERROR_RESTARTINGまたはERROR_NO_RESTART状態になっている可能性があります。

トポロジー・タブには異常なサービス・ステータスのみが表示されることに注意してください。健全に稼動しているコンポーネントのサービス・ステータスは空白のままです。

管理計画は、非同期に実行されるリモート・サービスを呼び出すことができます。各計画ステップ（タスク）は、task_timeoutパラメータ（デフォルトは5分）によって構成可能な最大時間実行することができます。タスクは、成功またはエラーの結果が判断された場合、またはタイムアウト期間を超えた場合に終了します。

非同期リモート・サービスは、タスクが結果を決定する前に、管理コンソールに直接レポートされ、エラー・ダイアログに表示されるエラーが発生する可能性があります。そのため、AdminサービスがプランをまだRUNNINGでアクティブであるとみなしている間に、ユーザーがエラーを認識する可能性があります。計画では最終的にエラーが表示され、ERROR状態に遷移します。

ストレージ・ノード(SN)レジストリ・ポートに無効な値を指定した場合、ストレージ・ノード・エージェントは適切に起動しません。jps -mコマンドでSNAを表示できず、java -jar kvstore.jar pingコマンドに応答しません。SNのルート・ディレクトリにあるsnaboot_0.logファイルには、エラー情報が表示されます。たとえば、レジストリ・ポートがすでに使用されている場合、ログには次が表示されます。

10-03-11 22:47:59:525 EDT SEVERE [snaService] SNAの起動に失敗しました：ポートはすでに使用中です：ネストされた例外は次のとおりです: java.net.BindException：権限が拒否されました

KVROOTディレクトリを削除し、makebootconfigインストール・ステップを繰り返す必要があります

HAポート範囲に無効な値を指定した場合(FAQで前述)、レプリケーション・ノード(RN)またはセカンダリ管理プロセス(Admin)をこのSNに導入できません。この問題は、その障害のあるSNに保存または管理レプリカを最初に導入しようとしたときに検出されます。このストレージ・ノードでRNが立ち上がらないことを示すこれらの表示が表示されます。

• 管理コンソール（4.3以前）では、このRNがERROR_RESTARTING状態であることを警告するエラー・ダイアログが表示されます。「トポロジ」タブにもこの状態が赤で表示され、再試行回数の後、RNがERROR_NO_RESTARTにあることが示されます。

• 計画はERROR状態になり、管理コンソール(4.3以前)の計画と構成タブで計画をクリックするか、java -jar kvstore.jar runadmin "show plan <planId>"コマンドで利用可能なその詳細な履歴は、次のようなエラーメッセージを表示します。

  試行1状態: エラー開始時間: 10-03-11 22:06:12終了時間: 10-03-11 22:08:12 sn3/farley:5200 [RUNNING]のrg1-rn3のDeployOneRepNodeが失敗しました。....rg1-rn3のRepNodeServiceへの接続に失敗しました。詳細は、ホスト・ファレーのログ/KVRT3/<storename>/log/rg1-rn3*.logをご確認ください。

• 管理コンソール(4.3以前)またはCLIからアクセスできるクリティカル・イベント・メカニズムには、計画履歴から同じエラー情報を含むアラートが表示されます。

• 指定された.logファイルまたは管理コンソールの「ログ」タブに表示されるストア全体のログ(4.3以前)を調べると、次のような特定のエラー・メッセージが表示されます。

  java.lang.IllegalArgumentExceptionを終了する[rg1-rn3]プロセス：ポート番号は 「周知の」 ポートの範囲外でなければならないため、ポート番号1は無効です。

構成の誤りは、これらの手順で対処できます。ステップには、NoSQL DBストレージ・ノードをホストする物理ノードで実行する必要なものがあれば、管理コンソールまたは管理CLIにアクセスできる任意のノードで実行でききるものもあります。

1. 管理コンソールまたは管理CLIを使用して、構成の誤りが発生したdeploy-storeまたはdeploy-admin計画を取り消します。
2. SNノードで、正しく構成されていない既存のStorageNodeAgentImplプロセスとそのすべてのManagedProcessesを強制終了します。パラメータ"-root <KVROOT>"を持つため、他のプロセスと区別できます。
3. SNノードで、KVROOTディレクトリからすべてのファイルを削除します。
4. SNノードで、java -jar kvstore.jar makebootconfigコマンドを使用して、KVROOTディレクトリにストレージ・ノードのブートストラップ設定ファイルを再作成します。
5. SNノードで、java -jar kvstore.jar startを使用してストレージ・ノードを再起動します。
6. 管理コンソールまたは管理CLIを使用して、デプロイ-SNプランを使用してストレージ・ノードを再導入します。

これで、以前にエラーが発生した同じポイントに戻り、最初の試行と同じパラメータを使用するdeploy-store計画またはdeploy-admin計画を作成して実行できます。

構成中、ユーザーににjava.net.NoRouteToHostExceptionが表示されることがあります。(Oracle NoSQL DatabaseのpingコマンドではなくUnixまたはWindows CLIのpingコマンドを使用して)Piingできる、またsshでターゲット・マシンにアクセスできる場合でも、Oracle NoSQL Database の構成に失敗することがあります。一般的な例外は次のようになります。

[nosql@nosql0 kv-1.2.123]$ java -jar ./lib/kvstore-1.2.123.jar ping -port 5000
-host nosql1.example.com
Exception in thread "main" java.rmi.ConnectIOException: Exception creating
connection to: nosql1.example.com; nested exception is:
java.net.NoRouteToHostException: No route to host
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:632)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
at sun.rmi.registry.RegistryImpl_Stub.list(Unknown Source)
at oracle.kv.util.Ping.getTopology(Ping.java:332)
at oracle.kv.util.Ping.main(Ping.java:104)
at oracle.kv.impl.util.KVStoreMain$8.run(KVStoreMain.java:218)
at oracle.kv.impl.util.KVStoreMain.main(KVStoreMain.java:319)
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:327)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:193)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at java.net.Socket.connect(Socket.java:495)
at java.net.Socket.(Socket.java:392)
at java.net.Socket.(Socket.java:206)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket
(RMIDirectSocketFactory.java:40)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket
(RMIMasterSocketFactory.java:146)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 8 more
[nosql@nosql0 kv-1.2.123]$

通常これは、iptablesが1台以上のマシンで実行されていることが原因です。iptables設定を確認するには、iptables -L -nを実行します。これにより、次のような出力が作り出されます。

[root@nosql1 init.d]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED, ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@nosql1 init.d]#

この問題を回避するには、Oracle NoSQL Database用に構成したポートを介した通信を許可するルールを作成する必要があります。iptablesが原因かどうかをテストするためのシンプルな回避策として、iptablesを一時的にシャットダウンすることができます（ただし、これによりファイアウォールルールが無効になり、セキュリティ上の問題が発生する可能性があることに注意してください）。

これは Johan Louwers により記述されました。

show plan -id <id>コマンドは、計画ステータスおよび発生した可能性のあるエラーを表示します。この例外がエラー・セクションにリストされている場合は、コマンドの実行中に管理サービスがNoSQL DBコンポーネントのいずれかに到達できなかったことを意味します。

最初のステップでは、show plan -id <id>コマンドから表示されるエラー情報をチェックして、起動に失敗したコンポーネントによって表示されるエラーを確認します。この問題は、レプリケーション・ノードが起動できなかったために発生することがほとんどです。一般的な問題には、レプリケーション・ノード・プロセス、不適切なカスタムJVM構成、またはすでに使用されていたポートのメモリー不足があります。

この最初のステップで問題が表示されない場合は、次のステップでストアの全体的なステータスを確認します。方法の1つとして、show topologyコマンドを使用し、その後にverifyコマンドを使用します。show topologyコマンドはストアのレイアウトを表示し、verifyは各コンポーネントのステータスを確認します。到達できないコンポーネントには、ステータスUNREACHABLEが表示されます。

次のステップでは、NoSQLログ・ファイルで、アクセスできないコンポーネントに関する詳細なエラー情報を確認します。最初に、管理サービスをホスティングしているノード(KVROOT/<storename>/logs/<storename>*.logの下)にある、ストア全体の集計ログを調べます。ストア内のすべての異なるコンポーネントからの情報が表示されます。

ストレージ・ノードsn3のレプリケーション・ノードrg1-rn3が応答していないとします。lt;storename>.log から、これらのコンポーネントによって作成されたエントリを探します。各ログエントリの先頭には、ログメッセージを発行したコンポーネントの名前が付きます。集約されたストア全体のログには情報が多すぎる場合や、コンポーネントからの情報が管理者に送信されず、集約されたログに含まれないことがあります。その場合、レプリケーション・ノードまたはストレージ・ノードのログを直接確認すると、<KVROOT>/<storename>/logsディレクトリにあるホストで確認できます。

最初の導入中に問題が発生した場合は、ストレージ・ノードのログを確認して、そのノードのストレージ・ノード・エージェントが正しく作成されたこと、およびインストールの指示に従ってプロセスが予期したとおりに起動したことを確認することが特に役立つことがあります。

デフォルトでは、NoSQL DBはレプリケーション・ノード・プロセスをJVMオプション「-XX:+UseLargePages」で起動し、このプロセスのラージページOSオプションを有効にしています。一部のJVMは大きなページをサポートしていないため、この警告が表示されます。注意報は勧告であり、ストアは運用されます。

まず、管理ガイドの8章の説明に従ってJMXエージェントを有効にしていることを確認します。

ストレージ・ノードのJMXエージェントは、ストレージ・ノード・エージェントのメイン・レジストリ・ポート番号でMBeansを使用可能な状態にします。このポート番号は、ストレージ・ノードが管理する他のすべてのRMIサービスにも使用されます。consoleでMBeansを見るには、SNAのレジストリがリッスンしているホストとポートにjconsoleを連携させる必要があります。たとえば、次のようにjconsoleを起動できます。

jconsole node1.example.com:5000

または、引数を指定せずにjconsoleを起動し、「新規接続」ダイアログで「リモート・プロセス」を選択し、アドレス・ボックスに「node1.example.com:5000」と入力します。

これらの例外は、セキュリティが実現された配置の構成に問題があることを示しています。plan deploy-snコマンドにshow planコマンドを使用すると、これらのエラーが表示されます。次のような例外があります。

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException：証明書署名の検証に失敗しました。

これは、ターゲットストレージノードがセキュリティを有効にするように構成されておらず、SSLを実行していないことを示します。次のような例外があります。

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: 証明書署名の検証に失敗しました。

これは、互換性のないSSL証明書を示します。

セキュリティを実現するには、ストレージ・ノードを最初に構成するときにmakebootconfigユーティリティに-store-security enableまたは-store-security configureフラグを使用するか、「security-config add-security」コマンドを使用してセキュリティーをセキュアでないインストールに追加する必要があります。詳細は、セキュリティ・ガイドをご確認ください。

既存のストアの構成パラメータがKVLocalConfig のパラメータと異なる場合、KVLocal.start() は「パラメータが一貫していません」という例外をスローします。KVLocalConfig パラメータを更新してディレクトリに記録されているものと一致させるか、startExistingStore() API を呼び出します。

サービスの停止がユーザーによってリクエストされたかどうかによって異なります。

RepNodeサービスはクラッシュすると自動的に再起動されます。しかし、短時間に何度もクラッシュすると自動的に再起動ができなくなります。その場合は、問題を診断し、サービスを手動で再起動してください。

ユーザがKVLocal.stop()APIを呼び出したり、アプリケーションを終了したりしてRepNodeサービスが停止した場合、KVLocal.start()APIを呼び出してRepNodeサービスを手動で再開する必要があります。

KVLocalは、Java Direct Driver APIをサポートしています。