An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDBは、Dormando(Memcachediner)とDanny Koppingがこのプロジェクトに貢献したこと、そして彼らのサポートと忍耐に感謝したいと考えています。 寝る ダニー・コッピング ScyllaDB - 規模で予測可能なパフォーマンスのデータベース - のエンジニアは、Memcachediner dormandoと協力してベンダー中立の方法で両方のテクノロジーを互いに比較しました。 結果は、そのことを明らかにしている: Memcached と ScyllaDB の両方で、ディスクとネットワーク帯域幅を最大化し、同様の条件下で強調され、同様のパフォーマンスを維持しました。 ScyllaDB は、ネットワークパスポートを完全に飽和させるためにデータモデリングの変更を必要としたが、Memcached はディスクの I/O を飽和させるために追加の IO トレードを必要とした。 ScyllaDB は、ディスクへの Memcached パイプライン リクエストと比較して、より良い遅延を示したが、Memcached 遅延は個々のリクエストに優れていた。 このドキュメントは、これらのテストの動機を説明し、テストされたシナリオと結果の概要を提供し、ScyllaDBとMemcachedの間で決断を下す可能性のあるすべての人に勧告を提供します。 There is also テストと結果をより広く見て、テストを自分で実行するために使用できる特定の構成へのリンクを提供します。 このプロジェクトの詳細な Gitbook は、 ボーナス: dormando と私は最近、パフォーマンスと低遅延エンジニアリングに関する高度な技術会議であるP99 CONFでこのプロジェクトについて議論しました。 要望を見る 睡眠と私は最近、このプロジェクトについて話し合った , パフォーマンスと低遅延エンジニアリングに関する高度な技術会議。 Bonus: P99 CONF Watch on demand 要望を見る なぜ我々はこれを行ったのか。 まず最初に、ScyllaDB は多くの時間とエンジニアリングリソースを投資し、データベースを最適化し、リアルタイムのデータ密集型アプリケーションに予測可能な低遅延を提供しました。 何もない建築、 そして (Linux ページキャッシュを完全に回避) は、そのような最適化のいくつかの顕著な例です。 Shard-per-Core シングル UserSpace I/O スケジュール 内部キャッシュの実装 第二に、パフォーマンスは時間の経過とともに一致する。インメモリーキャッシュは(長い間)インフラストラクチャの最も高速なコンポーネントの1つと見なされてきました。 If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? 第3話:以前話したこと 最近、特定のチームがどのように成功したかを調べました。 . データベースの前にキャッシュを置かない7つの理由 キャッシュをScyllaDBに置き換える 四つ目は、昨年のP99 CONFで、ダニー・コッピングは私たちに明るいスピーチをしました。 彼は、Memcached ExtstoreがGrafana Labsがコストを削減しながらキャッシュフットプリントを42倍に拡大するのにどのように役立ったかを説明した。 できるなら私を隠して 最後に、パフォーマンス・ベンチマークが受ける(正当な)批判にもかかわらず、彼らは依然としてイノベーションを推進する上で重要な役割を果たしています。 さて、比較についてです。 セットアップ 裁判所 テストは、以下の AWS インスタンスタイプを使用して実施されました。 ローダー: c7i.16xlarge (64 vCPU、128GB RAM) Memcached: i4i.4xlarge (16 vCPU, 128GB RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPU、128GB RAM、3.75TB NVMe) すべての機関が提供できる 25Gbpsのネットワーク帯域幅. 特に、約束されたネットワーク容量を最大化するテスト中に、我々は気づいたことに留意してください。 . up to throttling 帯域幅をインスタンスのベースライン容量まで縮小する 最適化と設定 潜在的な障害を克服するために、以下の最適化と設定が適用されました: AWS 側:すべてのインスタンスは、AWS Docs に従ってクラスター配置戦略を使用しました:“この戦略により、ワークロードは、ハイパフォーマンスコンピューティング (HPC) アプリケーションの典型的な緊密に接続されたノード-ノード通信に必要な低遅延ネットワークパフォーマンスを達成できます。 Memcached: Version 1.6.25, compiled with Extstore enabled. Except where denoted, run with 14 threads, pinned to specific CPUs. The remaining 2 vCPUs were assigned to CPU 0 (core & HT sibling) to handle Network IRQs, as specified by sq_split mode in seastar perftune.py. CAS operations were disabled to save space on per-item overhead. The full command line arguments were:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB: i4i.4xlarge で ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) によって構成されたデフォルト設定。 ストレス Memcached loaders では、私たちは使用しました。 , part of memcached's official test suite. The applicable stressing profiles are in the GitHub リポジトリ マクシュレーダー ファイヤー・メンデス / Shredders ScyllaDB では、私たちが使用した , as shipped with ScyllaDB, and specified comparable workloads as those used for Memcached. ScyllaDB と同様に配信され、Memcached で使用された同様に比較可能なワークロードを指定しました。 カサンドラストレス テストと結果 以下は、我々が実施したテストとその結果の概要です. 詳細な説明と分析を希望する場合は、 . このプロジェクトの拡張編集 RAM キャッシュ効率 より多くのアイテムがRAMに適合できるほど、キャッシュヒットを得るチャンスが良くなります。より多くのキャッシュヒットは、ディスクへのアクセスよりも大幅に速くなります。 このプロジェクトは、各データストアにどのくらいのアイテムを保存できるかを測定することによって始まりました。私たちのテストを通じて、キーはMemcachedのための4〜12バイト(key0 .. keyN)とScyllaDBのための12バイトの間でした。 メモ Memcached は追放が始まるまで約 101 万件のアイテムを格納しました. それはメモリ効率です. Memcached の 114G の割り当てられたメモリから、これはキーサイズや他のフラッグを考慮せずに、約 101G の値です: ScyllaDB これは、そのプロトコルが書き込みの一部として保存されるためにより多くのデータを必要とすることを考慮して驚くことではありません(例えば、時代以来の書き込みタイムスタンプ、行ライバリティなど) ScyllaDBはまた、Bloom Filters (およびオプションインデックス) が後にディスク検索のためにメモリに保存される必要がありますことを意味します。 Takeaways Memcached は ScyllaDB より約 65% 多くのメモリアイテムを格納しました。 ScyllaDB 行には、広い列の方向性をサポートするために、項目ごとにより高いオーバーヘッドがあります。 ScyllaDB では、ブルーム フィルター、インデックス キャッシング、その他のコンポーネントも、効率的なディスク検索をサポートするためにメモリーに保存され、もう一つのレイヤーのオーバーヘッドに貢献します。 Read-only In-Memory Workload THE (たとえ非現実的な)キャッシュのワークロードは、すべてのデータがRAMに適合するので、読み込みにはディスクアクセスを必要とし、削除や欠落は発生しません。ScyllaDBとMemcachedの両方がLRU(最も最近使用された)ロジックを使用してメモリを解放します:システムが圧力の下で実行されるとき、アイテムはLRUの尾から削除されます。 理想 画像から削除とキャッシュの欠落を取り除くことは、両方のデータストアのパフォーマンス基準を測定して設定するのに役立ちます. It places the focus on what matters most for these types of workloads: read throughput and request latency. このテストでは、最初に前回のテストで使用した同じパイロードサイズで両店舗を温め、その後、それぞれの範囲に対して30分間読み込みを開始しました。 Memcached Memcached は 1 秒あたり 3 億 Gets を達成し、AWS NIC 帯域幅 (25 Gbps) を最大化しました! Memcachedは安定した3M rpsを維持し、NICパネストレートを最大限に高めました。 THE PARSED p99.999 の回答が 1ms 以下で完了したことを示します。 結果 タグ: cmd_get 合計オプス: 5503513496 レート: 3060908/s 時間 時間 時間 時間 1～10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10-99us 343504394 6.238% 100−999us 5163057634 93.762% 1～2ms 11500 0.00021% ScyllaDB ScyllaDB でより多くの行を読み取るには、プロトコル特性(特にパイプラインニングなし)によりクライアントリクエストのためのより良いデータモデルを設計する必要がありました。クラスタリング キーを使用すると、CyllaDB のキャッシュを完全に最大化することができ、キャッシュされた行数を大幅に改善しました。 その結果、キャッシュ内のレコード数は、以前表示されたキー値数と比較して大幅に改善されました。 dormando が正しく指摘したように (thanks!), この構成は以前の Memcached セットアップと大きく異なります. While the Memcached workload always hits an individual key-value pair, a single request in ScyllaDB results in several rows being returned. Notable, the same results could be achieved using Memcached by feeding the entire payload as the value under a single key, with the results scaling accordingly. この構成は、Memcached を使用して、単一のキーの下の値として全体のパイロードを供給することによって、いくつかの行が返されます。 これらの変更の理由を説明しました。 そこでは、CQLプロトコルの特徴(たとえば、per-item overhead [compared to memcached] and no support for pipelining) をカバーし、シングルキー キャッチよりも ScyllaDB で幅広いパーティションをより効率的に行うことができました。 詳細な書き込みにて これらの調整により、当社のロードヤーは30分以上にわたり、1秒あたり187Kの読み込みオプションを実行しました。 memcached と同様に、ScyllaDB は NIC パネストレートを最大化し、メモリ内データのみで約 3M 行/秒を提供しました。 ScyllaDB は、サーバー側の遅延情報を明らかにし、ネットワークなしで遅延を分析するのに役立ちます。 クライアント側のセンチルは、驚くことなく、0.9msのP99を読み取ったサーバー側の遅延よりも高い。 Takeaways Memcached と ScyllaDB 両方とも、ネットワークを完全に飽和させたため、Memcached は 1 秒あたり最大のネットワーク パッケージを飽和させるのを防ぎ、ScyllaDB は広い列の方向に切り替わった。 ScyllaDBのキャッシュは、以前のシンプルなキー値指向に比べて、より多くのアイテムを格納できる広い列のスケジュールに従って大幅な利点を示しました。 プロトコルレベルでは、Memcachedのプロトコルはシンプルで軽量ですが、ScyllaDBのCQLはより豊富な機能を提供しますが、より重い可能性があります。 画像にディスクを追加する フラッシュストレージのパフォーマンスを測定することは、独自の課題を生み出し、特定のワークロードを現実的に完全に特徴づけることはほぼ不可能です。 ディスク関連のテストでは、最も悲観的な状況を測定することにしました:ブロックストレージからのデータ(ほとんど)を提供する両方のソリューションを比較し、次のことを知って: これを行う現実的なワークロードの確率は、どこかでゼロに近い。 ユーザーは、前回の楽観的なキャッシュワークロードと悲観的なディスク関連ワークロードの間の数値を期待すべきです。 Memcached Extstore THE 高レベルでは、memcachedがハッシュテーブルとキーをメモリに保管することを可能にしますが、外部のストレージに値を保存します。 ウィキページ 当社のテストでは、1KB の値サイズと最大 14 バイトのキーサイズを持つ 1.25B アイテムで memcached を埋めました。 Extstore では、以前のメモリ内ワークロードに比べて約 11 倍のアイテム数を格納し、削除が始まるまで(上記の画像の右側のパネルに示されているように)削除が始まりました。 Read-Only Performance 実際のパフォーマンステストでは、Extstore を 1KB および 8KB の項目サイズに対して強調しました。 Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms トップ > パイプ > パイプ 16 1KB 32 188k/s 4～5ms トップ > メタ 1 1KB 32 182k/s <1ms> トップ > パイプ > パイプ 16 1KB 64 261K/s 5～6 ms トップ > メタ 1 1KB 64 256k/s 1～2ms トップ > パイプ > パイプ 16 8KB 16 92k/s 5～6 ms トップ > メタ 1 8KB 16 90k/s <1ms> トップ > パイプ > パイプ 16 8KB 32 110k/s 3～4ms トップ > メタ 1 8KB 32 105k/s <1ms> ScyllaDB ScyllaDB は memcached に使用されたアイテム数と同じ数で普及しました。 ScyllaDB は memcached よりも高い GET レートを示しましたが、memcached の非パイペリングワークロードと比較して、少し高い尾の遅延でそれを実行しました。 Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1KB 読み方 1 1KB 268.8K/s 2ms 2.4ms 8KB 読み方 1 8KB 156.8K/s 1.54ms 1.9ms Takeaways Extstoreは、フラッシュストレージのI/Oを完全に飽和させるために、その設定にかなりの調節が必要でした。 Memcached アーキテクチャにより、より小さいパイロットは利用可能なディスクスペースを完全に活用することができず、ScyllaDB に比べてより小さい利点を提供します。 ScyllaDB レートは、キー 値指向で Memcached より一般的に高かったが、特に高いパイロットサイズでは、パイロット リクエストよりも遅れが良かったが、Memcached では個々の GET よりも少し高かった。 トップ > Workload 以前のディスクの結果に基づき、読み込みのほとんどが同じスループット(250K オプス/秒)をターゲットとする2つのソリューションを比較しました。 10%のランダムオーブリットで、「最悪のシナリオ」とみなされます。 「Extstore」の「Basic」テスト Memcached Memcached はテスト中にわずか 249K 未満のレートを達成しましたが、テスト期間中は書き込みレートが安定していましたが、読み込みがわずかに変動したことが観察されました。 : 走りを通して こちらも少し高く観察しました。 読み込み比率が低下したにもかかわらず、遅延は依然として低く残っています。 extstore_io_queue トップページ Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms CMD - GET 64 224K/s 1～2ms CMD セット 64 24.8K/s <1ms> ScyllaDB ScyllaDB テストは、ターゲットレートの半分をそれぞれ持つ 2 つのロード装置を使用して実行されたが、ScyllaDB はわずかに高いスピード(259.5K)を達成したにもかかわらず、書き込み遅延は走行中低く維持され、読み込み遅延はより高かった(memcached と同様)。 下のテーブルでは、2 つのロードヤー間のクライアント側の実行結果をまとめています。 Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms ロード1 124.9K/s 1.4ms 2.6 ms ロッテ2 124.6K/s 1.3ms 2.6 ms Takeaways Memcached と ScyllaDB の両方の書き込み率は安定しており、読み込みは走行中にわずかに変動しました。 ScyllaDB はまだ、ホット スクリプト パスに座っている commitlog overhead を記述しています。 ScyllaDB サーバー側の遅延は、Memcached の結果で観察されたものと類似していましたが、クライアント側の遅延は少し高くなりました。 このプロジェクトの詳細な分析を Gitbook で読む Wrapping Up memcached と ScyllaDB の両方で、すべてのテストで潜在的なハードウェアの利用を最大化し、遅延を予測可能に低く保つことができました。 既存のワークロードがシンプルなキー値モデルに適合でき、パイプラインニングから恩恵を受ける場合、memcached はあなたのニーズにより適合するはずです。 Memcached に固執するもう一つの理由は、NIC が維持できる範囲をはるかに超えるトラフィックを簡単に提供することです。 , dormando は、相当に大きいサーバーのための 55 百万のリリースオプス/秒を超えるスケールアップできることを言及しました。これを考慮して、あなたは、使用可能なメモリとディスクの足跡があなたのワークロードのニーズに十分である限り、同様のワークロードを維持するために、より小さいおよび/またはより安価なインスタンスタイプを使用することができます。 ハッカーニュース thread 考慮すべき別の角度は、データセットのサイズです。Extstore は、RAM を超えてアイテムを格納することを可能にすることにより、大きなコストの節約を提供しますが、メモリの GB につきどのくらいのキーが適合できるかには制限があります。非常に小さいアイテムを持つワークロードは、より大きなアイテムを持つものと比較して小さな利益を観察する必要があります。 また、データの持続性が必要かどうかを考慮することも重要です。その場合は、スクリラDBを複製分散キャッシュとして実行すると、より大きなレジリエンスとノンストップ操作が提供されます。 ) レプリケーションはあなたの効果的なキャッシュサイズを半分にします。残念ながら、Extstoreは温かい再起動をサポートしません、したがって、単一のノードの失敗またはメンテナンスは、あなたのキャッシュミス比率を高める傾向があります。これが受け入れられるかどうかは、あなたのアプリケーションのセマンティクスに依存します:キャッシュミスがデータベースへのラウンドトリップに対応する場合、エンド-to-エンドの遅延は一時的に高くなります。 正しく国を 一貫したハッシュに関しては、memcached クライアントは、分散型サーバー全体でキーを配布する責任があります。これにより、異なるクライアント構成によりキーが異なって割り当てられることになり、一部の実装が互いに互いに互換性がない可能性があります。 ScyllaDB は異なるアプローチを取ります:一貫したハッシュはサーバーレベルで行われ、最初に接続が確立されたときにクライアントに拡散されます。 Memcached's Configuringクライアント wiki では、誰が勝ったのか(または誰が負けたのか)? いいえ... これは競争ではなく、それぞれのソリューションのすべての考慮事項を概要する完全なリストである必要はありません。 ScyllaDB と memcached は、基礎インフラを効率的に活用するために異なるアプローチを使用しています。 ScyllaDB が業界で認められた Memcached の数値に匹敵するのを見るのは私たちに喜ばれました。もちろん、私たちのデータベースが「速くなる」という期待はしていませんでした。
