キーバリュー データ ストア (KVS) は、NoSQL データベースの世界で急速に成長しているセグメントであり、最近人気が高まっています。なぜなら、彼らは最も単純なデータモデル（任意）を持っているからです。
キーのバイト文字列と対応する値のバイト文字列を組み合わせると、非常に単純なストレージを必要とするアプリケーションにすぐに組み込むことができます。これらの API は同様に単純になる傾向があり、非常に原始的な操作のみを提供し、オーバーヘッドが非常に少ない状態でそれらを提供します。
現在、memcache や redis など、クライアント サーバー指向の KVS が多数存在しますが、このテストでは組み込み KVS、つまり、DB サーバー プロセスとの通信を必要とせず、完全にアプリケーション プロセス内で実行される KVS のみを使用します。このタイプの KVS は新しいものではなく、ストレージ ソフトウェアの中でも最も古いファミリーの 1980 つであることに注意してください。たとえば、BerkeleyDB は、XNUMX 年代から Unix で使用されてきたストレージ ライブラリの子孫です。また、これらの KVS はローカル (ネットワーク以外) での使用に限定されません。BerkeleyDB、LMDB、TokuDB は完全にトランザクション対応であり、MySQL や OpenLDAP などのサーバーの基盤となるストレージ エンジンとして長年使用されてきました。実際、SQL、NoSQL など、他のすべての上位レベルのデータ ストア内では、埋め込み KVS が実際の作業を行っていることがわかります。
現在、KVS を使用する注目度の高いアプリケーションが数多くあります。たとえば、ビットコインのような暗号通貨は、すべてのトランザクションの完全なログであるブロックチェーンを保存するために KVS を使用します。 KVS の使用につながるプロジェクト要件には、非常に高いトランザクション レート (大規模な e コマース サイトなど)、非常に低いレイテンシー (高頻度のトレーダーなど)、非常に小さい設置面積 (携帯電話やその他の制約のある環境など)、またはすべての組み合わせが含まれる場合があります。三つ。
ここで実行されているテストは、もともとLevelDBの作者によってGoogleで書かれたベンチマークコードを基にしており、その後Symas Corpによって他の複数のDBエンジンに移植されました[ 2 ]。テストシナリオは、FacebookのRocksDBチーム[ 3 ]が実行したベンチマークと、Symas Corpが実行した、より多くのDBエンジンとユースケースをカバーする拡張版のテストに基づいています。
テストには 2 つのフェーズがあります。レコードが順次ロードされる一括ロード フェーズと、レコードにランダムな順序でアクセスする読み取り/書き込みフェーズです。
ここでテストした DB エンジンはすべて、ソートされた順序でキーを格納する埋め込みキー/値ストアであるため、キーの順序付けられた走査をサポートします。そのため、それらはすべて、検索ツリー データ構造のバリアントを使用します。各 DB エンジンのスペースと I/O 効率を示すために、テスト データ セットはテスト サーバー上の RAM の約 5 倍の大きさになるように選択されています。
基礎となる概念は関連していますが、DB エンジンはすべて、その実装に対して非常に多様なアプローチを採用しています。そのほとんどは、特定のワークロードに必要な物理 I/O 操作の数を最小限に抑えるために、独自のデータ キャッシュを管理しようとします。すべてのアプローチには、スペースと時間のトレードオフが伴います。特定の量のスペースを使用すると、特定の状況では一定の時間を節約できる可能性がありますが、その節約分は必ず別の側面で返還されます。
RocksDB は、シンプルさとパフォーマンスをトレードオフにしています。最高のパフォーマンスを実現するには、40 を超えるパラメーターを最適に設定する必要がある、最も複雑なチューニングが必要です。構成の複雑さの点では、TokuDB と BerkeleyDB が続きます。 LevelDB と LMDB は構成の簡素化を目指しており、LMDB はチューニングをまったく必要としません。
RocksDB、LevelDB、TokuDB は書き込みパフォーマンスに重点を置いています。ログ ストラクチャード マージ (LSM) ツリーとフラクタル ツリー (FT) デザインは、それぞれ、ディスクにコミットする前にメモリ内の書き込みを集約するユーザー設定の書き込みバッファーに大きく依存しており、最終的な書き込みをシーケンシャルに、つまり最高レベルで書き込むことができます。基盤となるメディアの速度。その代償として、書き込みの理想的な順序は読み取りには理想的ではなく、読み取りパフォーマンスが大幅に低下します。 BerkeleyDB と LMDB は、より伝統的な B+tree 設計であり、書き込みパフォーマンスよりも読み取りパフォーマンスに重点を置いています。
WiredTiger は、LSM エンジンと B+tree エンジンの両方をライブラリで提供し、すべてのベースをカバーしようとしています。この柔軟性には、適度なレベルの構成の複雑さも必要です。
RocksDB と LevelDB は、最大の書き込みパフォーマンスを目指しながら機能を取り除きます。 BerkeleyDB、LMDB、TokuDB、WiredTiger は信頼性に重点を置き、完全な ACID トランザクションを提供します。したがって、後の 4 つのエンジンは SQL サーバー、LDAP サーバー、その他のトランザクション指向アプリケーションでの使用に容易に適合しますが、前の 2 つはそのような用途にはあまり適していません。
LMDB を除くすべてのエンジンは、明示的に管理される独自の書き込みバッファとデータ キャッシュを使用します。 LMDB はオペレーティング システムのページ キャッシュのみを使用します。そのため、LMDB 以外のすべてのエンジンでは、これらのバッファを管理し、これらのバッファ間でデータを複数回コピーするため、CPU オーバーヘッドが大きくなります。たとえば、以前にキャッシュされていなかったディスクからレコードを取得する場合、BerkeleyDB は少なくとも 1 回のメモリ間のコピーを実行します。まず、データが OS によってページ キャッシュに読み取られ、次に BerkeleyDB のページ キャッシュにコピーされます。最後に、データは BerkeleyDB キャッシュからユーザー指定のバッファーにコピーされます。 LMDB はゼロコピーです。データはストレージ デバイスから OS ページ キャッシュに直接送られ、このデータはユーザーに直接戻されます。ディスク上のデータはユーザーに返される前に複数のフォーマット変換を受けるため、TokuDB のようなエンジンはさらに多くのコピーを実行します。これらの複数のステージはそれぞれメモリを消費するため、メモリ コピー アーキテクチャは、同時に RAM に収まるレコードの数、つまりフルスピードで動作できるワーキング セットのサイズに直接影響します。 LMDB は独自のコピーを作成しないため、任意のサイズの RAM で最大のデータ セットを処理できます。
DB エンジンの中には、書き込み操作により最適化されるように設計されたものと、読み取りにより最適化されるものがあります。バルクロードフェーズは、最良の場合の書き込み速度を示します。ランダム読み取り/書き込みフェーズは、最悪の場合の書き込み速度を示します。この場合、単一のスレッドがランダムに選択されたレコードへの書き込みを実行し、XX スレッドが他のランダムに選択されたレコードへの同時読み取りを実行します。また、高負荷環境で各エンジンが読み取りをどのように処理するかについても示します。
Symas テストで示されたように、各 DB エンジンの相対的なパフォーマンスは、使用されているレコードのサイズに大きく依存します。ここで選択されるレコード サイズは、大きいレコード (従来の Btree ベースのエンジンが優れている) と小さいレコード (LSM ベースの設計が優れている) の間の大まかな妥協点です。
Amazon