database - SSD 向けの低レイテンシー Key-Value ストア

Question

私たちは、次のプロパティを持つ SSD に基づくキー値ソリューションに取り組んでいます。

• スループット: 10000 TPS; 50/50 のプット/ゲット。
• レイテンシ: 平均 1 ミリ秒、99.9 パーセンタイル 10 ミリ秒
• データ量: ~10 億の値、それぞれ ~150 バイト。64 ビット キー。ランダム アクセス、データの 20% が RAM に適合

さまざまな Linux IO スケジューラ、ext3/xfs ファイル システムを使用して、KyotoCabinet、LevelDB、および RethinkDB をコモディティ SSD で試しました。Rebenchを使用して多くのテストを行いました。そして、すべての場合で次のことがわかりました。

• 読み取り専用のスループット/レイテンシーは非常に優れています
• 全体を通して書き込み/更新のみは中程度ですが、レイテンシの高い外れ値が多数あります
• 読み取り/書き込みワークロードが混在していると、ブロック デバイスに (ファイル システムをバイパスして) 直接アクセスする場合でも、スループット/レイテンシーに壊滅的な振動が発生します。

以下の図は、KyotoCabinet のこのような動作を示しています (横軸は時間で、読み取り専用、混合、更新のみの 3 つの期間が明確に表示されます)。

問題は、SSD を使用して記述された SLA の低レイテンシーを達成することは可能ですか? また、推奨されるキーと値のストアはどれですか?

Answer 1

高度なバリアント書き込みレイテンシは、SSD (特にコンシューマー モデル) の一般的な属性です。このAnandTechレビューには、その理由のかなり良い説明があります。

要約すると、ウェアレベリングのオーバーヘッドが増加するにつれて、SSD の書き込みパフォーマンスが時間の経過とともに悪化するということです。ドライブの空きページ数が減少すると、NAND コントローラーはページの最適化を開始する必要があり、これがレイテンシーの原因となります。また、NAND は、LBA からブロックへのマップを構築して、さまざまな NAND ブロックにまたがるデータのランダムな分布を追跡する必要があります。このマップが大きくなるにつれて、マップ上の操作 (挿入、削除) が遅くなります。

低レベルのハードウェアの問題をソフトウェア アプローチで解決することはできません。エンタープライズ レベルの SSD に移行するか、レイテンシ要件を緩和する必要があります。

Answer 2

Aerospikeは新しいキー/値 (行) ストアであり、読み取り/書き込みの待ち時間が 1 ミリ秒未満で、TPS が非常に高い (数百万に達する) ため、SSD から完全に実行できます。

SSD には優れたランダム読み取りアクセスがありますが、書き込みの分散を減らす鍵はシーケンシャル IO を使用することです (これは通常のハードディスクと同様です)。また、SSD への書き込みが多い場合に発生する可能性のあるウェア レベリングとフェードを大幅に削減します。

独自のキー値システムを構築している場合は、ログ構造のアプローチ (Aerospike など) を使用して、書き込みが一括で行われ、大きなチャンクで追加/書き込みされるようにします。バックグラウンド プロセスが古い/削除されたデータをディスクからクリーンアップし、ファイルを最適化する間、インメモリ インデックスは値の正しいデータの場所を維持できます。

Answer 3

これは一種の頭脳明晰なアイデアですが、うまくいくかもしれません。SSDが128GBだとしましょう。

1. SSD に 128GB のスワップ パーティションを作成します。
2. それをスワップとして使用するようにマシンを構成します
3. マシンで memcached をセットアップし、128 GB のメモリ制限を設定します
4. 基準

カーネルはページインとページアウトを十分に高速に実行できますか? 知る方法はありません。それは、カーネルよりもハードウェアに依存します。

Poul-Henning Kamp は、Varnish でこれと非常によく似た処理を行います。これは、Varnish に実行させるのではなく、カーネルに Varnish の情報 (仮想メモリと物理メモリ) を追跡させることによって行われます。 https://www.varnish-cache.org/trac/wiki/ArchitectNotes