問題タブ [extensible-storage-engine]

ESENT に保存された大量のデータ (100 GB 以上) を扱うアプリケーションがあります。テーブルのスキーマは次のとおりです。12 バイトのJET_bitColumnFixedキーとJET_coltypLongBinary値で、通常のサイズは約 2 KiB です。ページサイズは 32 KiB に設定されています。外部の long 値のデフォルトの 1024 バイト サイズのしきい値は変更しないので、これらの値はほとんどが外部に格納されていると思います。

操作がバッチで行われ、キーが事前にわかっているため、コールド キャッシュのシークと取得のパフォーマンスを改善することに関心があります。私の知る限り、JetPrereadKeys () API はそのような場合のパフォーマンスを向上させるように設計されていますが、結局のところ、この呼び出しの有無にかかわらず、実際の動作に変化は見られません。

詳細は次のとおりです。

• 私の場合、JetPrereadKeys() は常に、API を呼び出したときに送信したキーの数に等しい適切な数の事前読み取りキーを報告します。ドキュメントに記載されているように、送信されたキーは適切にソートされます。

• 同期アプローチと非同期アプローチの両方を試しました。非同期アプローチは、現在のスレッドでデータのシークと取得を続けながら、事前読み取り呼び出しをスレッド プールに送信します。

• JET_paramEnableViewCacheパラメーターとJET_paramEnableFileCacheパラメーターのすべての使用可能な組み合わせを試して、MMAP または専用ページ キャッシュを使用する ESENT の使用可能な両方のキャッシュ モードを試しました。

• 小さな例外を除いて、事前読み取りの有無にかかわらず、ログに記録された I/O 操作に違いは見られません。つまり、この操作によって、必要な B ツリーの内部ノードが (できれば非同期で) フェッチされることを期待しています。しかし、唯一確認できるのは、JetPrereadKeys() 自体のスタックから時折発生する同期的な小さな読み取りです。必要な情報をすべてプリフェッチできるとは思えないという意味で、読み取りのサイズは小さいです。

• Windows Search サービスをデバッグすると、JetPrereadKeys() へのさまざまな呼び出しを中断できます。したがって、おそらく何らかの理由で、この API が呼び出されている実際の例が少なくとも 1 つあります。

• データベース ページ キャッシュが空であることを確認するために、すべての実験はマシンの再起動後に実行されました。

質問:

1. 説明されているケースでの JetPrereadKeys() の予想される動作は何ですか?

2. この API を使用すると、別の I/O パターンとパフォーマンスの向上が期待できますか? データの同期または非同期の事前読み取りを期待する必要がありますか?

3. 今後のバッチについて ESENT を何らかの形でほのめかすことで、I/O パフォーマンスを改善しようとする別のアプローチはありますか?

この Windows アプリケーションでは、Extensible Storage Engine (ESENT) を使用しています。ESENT への読み取りと書き込みをしばらく行った後、次のエラーが発生します。

私は ESENT に詳しくないので、MSDN でこのエラーの適切な説明を見つけることができないようです。どういう意味ですか？特定の時間に使用できるテーブル カーソルの数を確認する方法はありますか?