Search:

Search all manuals
Search this manual
Manual
Couchbase Server 1.8 マニュアル
Additional Resources
Community Wiki
Community Forums
Couchbase SDKs
Parent Section
11.4 ディスクストレージ(メモリを超えてデータセットを拡大する)
Chapter Sections
Chapters

11.4.2. ディスクよりも高速なメモリの影響

11.4.2.1. DGM実装の詳細

明らかに、ディスクへのデータの移行は一般にかなり低速になり、メモリ内にデータを設定するよりもはるかに低いスループットになります。入力データ用の空きスペースを用意するために、メモリからディスクに移動されるよりも早く、アプリケーションがデータを追加もしくは更新する場合、サーバの動作はクライアントがmemcachedに期待するものとは少し異なる場合があります。memcachedの場合には、アイテムがメモリから削除され、新たに更新されたアイテムが格納されています。しかし、Couchbaseの場合はアイテムをディスクに移行することを前提としています。

MemBaseは、情報を直ちに格納するのに十分なメモリがないと判断すると、サーバはTMP_OOM、一時的なメモリ不足のエラーを返します。これは要求された情報が保存できないことがあくまで一時的であり、恒久的ではなく、メモリ不足であることを示すために設計されています。クライアントがこのエラーを受信した場合、保存のプロセスをリトライしたり、失敗させたり、クライアントとアプリケーションの要求に任せることが出来ます。

11.4.2.1. DGM実装の詳細

メモリのデータを除去するプロセスは比較的簡単です。メモリが必要な場合、ハッシュテーブル内を見回し、削除可能なもの(すなわち、ディスクに永続しているもの)を探し、削除しようと試みます。また、mem_low_watより高い値の間、非アクティブなvBucketのデータ(複製など)を永続化後、直ちにデータをメモリから開放します。十分なメモリがある場合は、それらをロードしたままにしておきます。

このページの大部分はメモリ上に存在しない値に遭遇した際に何が起こるかについて記述しています。

11.4.2.1.1. 取得フロー

現在のフローでは、与えられた文書のIDに対してGETリクエストは、最初にハッシュテーブルから値を取得します。Couchbase Serverに保存されたアイテムのドキュメントIDは必ずハッシュテーブル内に存在し、関連するメタデータは全てハッシュテーブルから利用できます。"イジェクト"されたレコードの場合、値は失われ、実質的にNULLを指します。これは、大きいオブジェクトには有効ですが、小さなオブジェクトには特に効率的ではありません。これは、将来のバージョンで対処されています。

値をフェッチする場合、まずハッシュテーブルを見ます。それが見つからないということは、それが存在しないということです。結果は「MISS」です。

もしそれが存在し、メモリ上にあるなら、それを返します。結果は「HIT」です。

もしデータが存在し、メモリ上に存在しない場合、バックグラウンドのフェッチをスケジュールし、ディスパッチャーにDBからオブジェクトを取得させ、それをメモリ上に保持します。遅いストレージからアイテムが返されるまで、クライアントが待機するように、接続はブロッキング状態となります。

バックグラウンドのフェッチは非同期のジョブディスパッチャーによって、ある時点で実行されます。

図11.2 バックグラウンドフェッチのワークフロー

バックグラウンドフェッチのワークフロー

ジョブが実行されるとディスクからアイテムを読み出します。メモリ内のアイテムを参照し、メモリ上に存在しない場合のみ、ディスクから取得した値を返します。*

この処理が完了した後、データがディスクから再設定されたかどうかに関わらず、コネクションが再び呼び起こされ、初めからリクエストが処理されます。

リクエストの再処理が実行される前に再度データがイジェクトされることは(非常にまれですが)あり得ます。その場合、このプロセスがまた繰り返されます。クライアントは取得要求を送った後、サーバがこの処理を終了するまで、特にすることはありません。

注記

同一のドキュメントIDに対する別のバックグラウンドフェッチが先に完了した場合や、別のクライアントがその値を更新した場合、アイテムはバックグラウンドフェッチの後でもメモリに残る場合があります。どちらの場合でも、我々は、ディスクの値が古いとして、それを破棄します。

11.4.2.1.2. 並列同時読取りおよび書込み

複数クライアントによる同時読取りおよび書込みは、適切な条件の下で可能です。これらの条件が満たされると、読取りはデータベースへの読取り専用のリクエスト用の新しいディスパッチャによって実行され、それ以外は読み書き可能なディスパッチャが使用されます。

下層のストレージは起動時(特に、初期化スクリプトの実行後)に並列実行レベルを報告します。SQLiteの場合、ジャーナルモードがWALでかつread_uncommittedが有効になっている場合に並列読取りが許可されます。

将来のストレージメカニズムは異なる条件下での並列実行を許容するかもしれませんし、異なる並列実行レベルを報告するかもしれません。

たとえストレージがDBへの並列同時アクセスが可能と主張しても、concurrentDBエンジンの設定で無効にすることが出来ます。

並列実行レベルはep_store_max_concurrencyep_store_max_readersep_store_max_readwriteの統計で報告されます。読み取り専用ディスパッチャの統計は有効なときに表示されます。

11.4.2.1.3. 更新の流れ

新しいデータは古いデータより優先されます、すなわち更新が常に優先されます。同様に削除が常に優先されます。インクリメント、デクリメント、追加、などはすべてアトミックですが、それらは取得+保存の作業セットとしてとらえることが出来ます。