dragonfly

Доступен выпуск системы кэширования данных в оперативной памяти Dragonfly, обеспечивающей поддержку протоколов Memcached и Redis, но позволяющей выполнять запросы с гораздо более высокой производительностью и с меньшим потреблением памяти. https://docs.google.com/document/d/1CBkEIzGmBrJznAeKIt5QxuPIlbOnHpjx7CElJKq6GQ8/edit

Система манипулирует данными в формате ключ/значение и может применяться как легковесное решение для ускорения работы высоконагруженных сайтов, кэширующие медленные запросы к СУБД и промежуточные данные в оперативной памяти.

Код Dragonfly написан на языках C/С++ и распространяется под лицензией BSL (Business Source License).

Лицензия BSL была предложена сооснователями MySQL в качестве альтернативы модели Open Core. Суть BSL в том, что код расширенной функциональности изначально доступен для внесения изменений, но в течение какого-то времени может применяться бесплатно только при соблюдении дополнительных условий, для обхода которых требуется приобретение коммерческой лицензии. Дополнительные лицензионные условия проекта Dragonfly предписывают перевод кода на лицензию Apache 2.0 лишь 1 июня 2027 года. До этого времени лицензия разрешает использование кода только для обеспечения работы своих сервисов и продуктов, но запрещает применение для создания платных облачных сервисов, выступающих надстройкой над Dragonfly.

По заявлению разработчиков и продемонстрированным тестам Dragonfly претендует на звание самой быстрой системы хранения в памяти. По сравнению с Redis в Dragonfly при типовых видах нагрузки удалось добиться 25-кратного увеличения производительности и трёхкратного снижения потребления памяти.

Один сервер Dragonfly может обрабатывать миллионы запросов в секунду, например, в окружении Amazon EC2 c6gn.16xlarge удалось достичь производительности в 3.8 млн запросов в секунду.

その他の言語: English 简体中文 한국어

Web サイト • ドキュメント • クイックスタート • コミュニティ Discord • Dragonfly Forum • Join the Dragonfly Community

GitHub Discussions • GitHub Issues • コントリビュート

世界最速のインメモリデータストア

Dragonfly は最新のアプリケーションワークロードのために構築されたインメモリデータストアです。

Redis や Memcached の API と完全に互換性があるため、Dragonfly を採用するためにコードを変更する必要はありません。従来のインメモリデータストアと比較して、Dragonfly は 25 倍のスループット、より低いテールレイテンシでより高いキャッシュヒット率、そして容易な垂直スケーラビリティを提供します。

コンテンツ

• ベンチマーク
• クイックスタート
• コンフィグ
• ロードマップとステータス
• デザイン決定
• バックグラウンド

Memcached の書き込みパスでの競合により、書き込みワークロードでより優れたレイテンシを示しました。

SET ベンチマーク

Server	QPS(thousands qps)	latency 99%	99.9%
Dragonfly	🟩 3844	🟩 0.9ms	🟩 2.4ms
Memcached	806	1.6ms	3.2ms

GET ベンチマーク

Server	QPS(thousands qps)	latency 99%	99.9%
Dragonfly	🟩 3717	1ms	2.4ms
Memcached	2100	🟩 0.34ms	🟩 0.6ms

Memcached は読み取りベンチマークでより低いレイテンシを示したが、スループットも低かった。

メモリ効率

メモリ効率をテストするために、

コマンドを使用して Dragonfly と Redis に ~5GB のデータを入れ、

memtier

コマンドで更新トラフィックを送信し、

bgsave

コマンドでスナップショットを開始しました。

この図は、各サーバがメモリ効率の面でどのような挙動を示したかを示している。

Dragonfly はアイドル状態では Redis よりも 30% メモリ効率が高く、スナップショットフェーズではメモリ使用量の目に見える増加は見られなかった。ピーク時には Redis のメモリ使用量は Dragonfly の 3 倍近くまで増加しました。

Dragonfly はスナップショットをより早く、数秒以内に終了させました。

Dragonfly のメモリ効率の詳細については、Dashtable ドキュメントを参照してください。

• 斬新なキャッシュデザインのセクションを参照してください。
• hz
  : キーの有効期限評価頻度 (
  default: 100
  )。この頻度が低いと、アイドル時の CPU 使用量が少なくなるが、その分古くなったキーをクリアする速度が遅くなる。
• primary_port_http_enabled
  : もし
  true
  (
  default: true
  ) なら、メイン TCP ポートで HTTP コンソールにアクセスできるようにする。
• admin_port
  : 割り当てられたポートのコンソールへの管理者アクセスを有効にする(
  default: disabled
  )。HTTP と RESP プロトコルの両方をサポートする。
• admin_bind
  : 管理コンソールの TCP 接続を指定されたアドレスにバインドする(
  default: any
  )。HTTP と RESP の両方のプロトコルをサポートする。
• admin_nopass
  : 割り当てられたポートで、認証トークンなしでコンソールへのオープン管理アクセスを有効にする (
  default: false
  )。HTTP と RESP の両方のプロトコルをサポートする。
• cluster_mode
  : サポートするクラスターモード (
  default: ""
  )。現在は
  emulated
  のみをサポートしている。
• cluster_announce_ip
  : クラスタコマンドがクライアントにアナウンスする IP。

一般的なオプションを使用した開始スクリプトの例:

./dragonfly-x86_64 --logtostderr --requirepass=youshallnotpass --cache_mode=true -dbnum 1 --bind localhost --port 6379  --maxmemory=12gb --keys_output_limit=12288 --dbfilename dump.rdb

また、

を実行することで、設定ファイルから引数を指定することもできる。ファイルには 1 行に 1 つのフラグを記述し、キーと値のフラグには空白の代わりに等号を記述します。

ログの管理や TLS のサポートなど、その他のオプションについては

を実行してください。

コマンドリファレンスをご覧ください。

こちらを参照してください。

ネイティブ HTTP コンソールと Prometheus 互換メトリクス

デフォルトでは、Dragonfly はメイン TCP ポート(6379)経由での HTTP アクセスを許可しています。その通り、Redis プロトコル経由でも HTTP プロトコル経由でも Dragonfly に接続することができます。ブラウザで試してみてください。HTTP アクセスには現在あまり情報がありませんが、将来的にはデバッグや管理に役立つ情報が含まれるようになる予定です。

Prometheus 互換のメトリクスを見るには、URL

にアクセスしてください。

Prometheus からエクスポートされたメトリクスは Grafana ダッシュボードと互換性がありますこちらを参照。

重要です！HTTP コンソールは安全なネットワーク内でアクセスすることを想定しています。Dragonfly の TCP ポートを外部に公開する場合は、

または

--nohttp_admin_console

でコンソールを無効にすることをお勧めします。

シェアードナッシングアーキテクチャを使用しています。このアーキテクチャでは、各スレッドが辞書データのスライスを独自に管理できるように、スレッド間でメモリストアの鍵空間を分割することができます。これらのスライスを "shards" と呼ぶ。シェアードナッシングアーキテクチャのスレッドと I/O 管理のためのライブラリは、こちらでオープンソースで提供されています。

複数キー操作に対する原子性保証を提供するために、我々は最近の学術研究の進歩を利用している。Dragonfly のトランザクションフレームワークの開発には、論文 "VLL: a lock manager redesign for main memory database systems" を選びました。シェアードナッシングアーキテクチャと VLL の選択により、ミューテックスやスピンロックを使用せずにアトミックなマルチキー操作を構成することができました。これは我々の PoC にとって大きなマイルストーンであり、その性能は他の商用やオープンソースのソリューションよりも際立っていました。

私たちの第二の課題は、新しいストアのために、より効率的なデータ構造を設計することだった。この目標を達成するために、我々は論文 "Dash: Scalable Hashing on Persistent Memory" に基づいたハッシュテーブル構造を核とした。この論文自体は、永続メモリ領域を中心にしており、メインメモリストアとは直接関係ありませんが、それでも私たちの問題に最も当てはまります。この論文で提案されているハッシュテーブル設計により、Redis の辞書に存在する 2 つの特別な特性を維持することができました: それは、データストアの成長中にハッシュをインクリメンタルする機能と、ステートレススキャン操作を使って変更中の辞書をトラバースする機能です。これら2つの特性に加え、Dash は CPU とメモリの使用効率が高い。Dash の設計を活用することで、私たちは以下のような機能をさらに革新することができました:

• TTL レコードの効率的なレコード期限切れ。
• LRU や LFU のような他のキャッシュ戦略よりも高いヒット率を、ゼロメモリオーバーヘッド で達成する新しいキャッシュエビクションアルゴリズム。
• 新しい フォークレス スナップショットアルゴリズム。

Dragonfly の基盤を構築し、そのパフォーマンスに満足したら、Redis と Memcached の機能を実装していきました。現在までに 185 個の Redis コマンド（Redis 5.0 API とほぼ同等）と 13 個の Memcached コマンドを実装しました。

そして最後に、
私たちの使命は、最新のハードウェアの進歩を活用した、クラウドワークロード向けの、優れた設計、超高速、コスト効率の良いインメモリデータストアを構築することです。現在のソリューションの API と提案を維持しながら、その問題点を解決するつもりです。