KeyDB - Redisのマルチスレッドフォーク
(A Multithreaded Fork of Redis)
KeyDBは現在Snap Inc.の一部となっています!ここで発表をチェックしてください
リリースv6.3.0は、オープンソースとエンタープライズの製品を単一のBSD-3ライセンスプロジェクトに統合したため、大幅な改善が加えられています。詳細については、ロードマップを参照してください。
JavascriptでKeyDBを拡張したいですか?モッズJSをお試しください
ヘルプが必要ですか?豊富なドキュメントをご覧ください。
KeyDB は Slack 上にあります。詳細を確認し、KeyDB Community Slack ワークスペースに参加するには、ここをクリックしてください。
KeyDB とは何ですか?
KeyDBは、マルチスレッド、メモリ効率、および高スループットに重点を置いたRedisの高性能フォークです。パフォーマンスの向上に加えて、KeyDBはアクティブレプリケーション、フラッシュストレージ、サブキー有効期限などの機能を提供します。KeyDBにはMVCCアーキテクチャがあり、データベースをブロックしてパフォーマンスを低下させることなく、KEYSやSCANなどのクエリを実行できます。
KeyDB は、Redis プロトコル、モジュール、およびスクリプトとの完全な互換性を維持します。これには、スクリプトとトランザクションの原子性の保証が含まれます。KeyDB は Redis 開発と同期しているため、KeyDB は Redis 機能のスーパーセットであり、KeyDB は既存の Redis デプロイメントに代わるドロップインになります。
同じハードウェア上で、KeyDB は Redis よりも大幅に高いスループットを実現できます。アクティブ・レプリケーションにより、ホット・スペア・フェイルオーバーが簡素化されるため、レプリカ間で書き込みを容易に分散し、シンプルなTCPベースのロード・バランシング/フェイルオーバーを使用できます。KeyDBのより高いパフォーマンスにより、より少ないハードウェアでより多くのことを行うことができ、運用コストと複雑さが軽減されます。
以下のグラフは、最新の Redis6 io-threads オプションや TLS ベンチマークなど、いくつかの KeyDB と Redis のセットアップを比較したものです。
完全なベンチマーク結果とセットアップ情報については、こちらをご覧ください。 https://docs.keydb.dev/blog/2020/09/29/blog-post/
なぜレディスをフォークするのですか?
KeyDBには、コードベースがどのように進化するかについて異なる哲学があります。使いやすさ、高性能、および「バッテリー込み」のアプローチが、優れたユーザーエクスペリエンスを作成するための最良の方法であると感じています。私たちはRedisメンテナに大きな敬意を払っていますが、Redisのアプローチは、ユーザーの複雑さを犠牲にして、コードベースの単純さに焦点を当てすぎていると考えています。その結果、一般的な問題を解決するための外部コンポーネントと回避策が必要になり、全体的に複雑さが増します。
この意見の違いのために、KeyDBに適した機能はRedisには適さないかもしれません。フォークを使用すると、この新しい開発パスを探索し、Redisの一部ではない可能性のある機能を実装できます。KeyDB はアップストリームの Redis の変更と同期し、該当する場合はアップストリームのバグ修正と変更を行います。2つのプロジェクトが成長し続け、お互いから学ぶことができることを願っています。
プロジェクト支援
KeyDBチームはSnap Inc.の一部としてこのプロジェクトを維持しており、KeyDBはSnapによってキャッシュインフラストラクチャの一部として使用されており、完全にオープンソースです。個別の商用製品や利用可能な有料サポートオプションはありません。私たちはオープンソースコミュニティとのコラボレーションを本当に大切にしており、PR、バグレポート、オープンディスカッションを歓迎します。コミュニティサポートやプロジェクトへの参加については、こちらのコミュニティサポートオプション(Slack、フォーラム、ミートアップ、githubの問題)をご覧ください。私たちのチームはこれらのメンバーを定期的に監視しています。
関連資料
KeyDB Docker Image を試す
スラックで参加する
KeyDBの広範なドキュメントを使用して詳細をご覧ください
コミュニティフォーラムに投稿する
KeyDBロードマップを参照して、何が待ち受けているかを確認してください
ベンチマーク KeyDB
keydb-benchmark と redis-benchmark は現在シングルスレッドであり、KeyDB を適切にベンチマークするには遅すぎることに注意してください。memtier などの Redis クラスターベンチマークツールを使用することをお勧めします。ローカルでテストする場合は、マシンにKeyDBとmemtierの両方に十分なコアがあることを確認してください。KeyDB は、割り当てられているすべてのコアの排他的使用を想定しています。
新しい構成オプション
新機能には新しいオプションが付属しています。他のすべての構成オプションは、期待どおりに動作します。既存の構成ファイルは、変更されずに引き続き機能します。
server-threads N
server-thread-affinity [true/false]
要求の処理に使用されるスレッドの数。これは、ネットワークハードウェアで使用可能なキューの数に関連しており、コアの数ではありません。 機械。KeyDBはスピンロックを使用してレイテンシーを短縮するためです。これを高くしすぎると、パフォーマンスが低下します。ここでは 4 を使用することをお勧めします。デフォルトでは、これは 2 に設定されています。
min-clients-per-thread 50
KeyDB が新しい接続を別のスレッドに割り当てる前のスレッド上のクライアントの最小数。このパラメーターの調整は、オーバーヘッドのロックと複数のコアへのワークロードの分散の間のトレードオフです。
replica-weighting-factor 2
KeyDB は、スレッド間でクライアントのバランスを均等に試みます。ただし、レプリカクライアントは通常、通常のクライアントよりもはるかに高価であるため、KeyDBはレプリカを持つスレッドに割り当てるクライアントの数を減らしようとします。以下の重み係数は、この動作の調整を支援することを目的としています。レプリカの重み係数 2 は、レプリカを 2 つの通常のクライアントと同等に扱うことを意味します。この値を調整すると、レプリケーション使用時のパフォーマンスが向上する場合があります。最適な重み付けはワークロード固有です - たとえば、読み取り負荷の高いワークロードはこれを 1 に設定する必要があります。非常に書き込み負荷の高いワークロードは、数値が大きいほどメリットが得られる場合があります。
active-client-balancing yes
KeyDBはスレッド間でクライアントのバランスをとるために積極的に試みるべきですか?これは、新しいクライアントを受け入れるパフォーマンスに影響を与える可能性があります。デフォルトでは、これは有効になっています。無効にしても、カーネルからスレッド間でSO_REUSEPORTに分散するための最善の努力がありますが、それはそれほど公平ではありません。デフォルトでは、これは有効になっています
active-replica yes
アクティブ/アクティブ レプリケーションを使用している場合は、オプションを "yes" に設定します。これにより、両方のインスタンスが同期されたまま読み取りと書き込みを受け入れることができます。ドキュメントセクションでactive-repの詳細については、ここをクリックしてください。ドキュメントにはドッカーの例もあります。
active-replica
multi-master-no-forward no
RREPLAYメッセージを他のマスターに転送することは避けてください。警告:この設定は危険です!すべてのマスターが真のメッシュトポロジで相互に接続されていないことを確認する必要があります。このコマンドを使用して、マルチマスターバストラフィックを削減できます。
db-s3-object /path/to/bucket
KeyDB をダンプして AWS S3 に直接ロードする場合、このオプションはバケットを指定します。このオプションを従来のRDBオプションとともに使用すると、KeyDBは両方の場所に2回バックアップされます。両方が指定されている場合、KeyDB は最初にローカルダンプファイルからのロードを試み、失敗した場合は S3 からのロードを試行します。これには、データを転送するために内部で使用されるAWS CLIツールをインストールして設定する必要があります。
storage-provider flash /path/to/flash
KeyDB フラッシュストレージを使用する場合は、ストレージメディアを指定し、その後にローカル SSD ボリューム上のディレクトリパスを指定します。この機能はまだ実験的であると考えられており、慎重に使用する必要があることに注意してください。FLASH ボリュームの設定と設定の詳細については、FLASH のマニュアルを参照してください。
キーデータベースの構築
KeyDB はコンパイルでき、Linux での使用がテストされています。KeyDBは現在、Linuxでのみ利用可能なSO_REUSEPORTの負荷分散動作に依存しています。スレッド間の接続のマーシャリングをサポートする場合は、FreeBSDなどの他のオペレーティングシステムをサポートする予定です。
CentOS/Archlinux/Alpine/Debian/Ubuntu の依存関係とビルドの詳細については、こちらをご覧ください: https://docs.keydb.dev/docs/build/
サブモジュールの依存関係の初期化とクローン:
% git submodule init && git submodule update
依存関係をインストールします。
% sudo apt install build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl-dev uuid-dev libcurl4-openssl-dev libbz2-dev libzstd-dev liblz4-dev libsnappy-dev libssl-dev
コンパイルは次のように簡単です。
% make
systemdサポートを使用してビルドするには、systemd開発ライブラリ( Debian/Ubuntu では libsystemd-dev として、CentOS では systemd-devel として) を実行し、以下を実行します。
% make USE_SYSTEMD=yes
KeyDB プログラム名に接尾辞を追加するには、次のコマンドを使用します。
% make PROG_SUFFIX="-alt"
次の依存関係が必要になる場合があることに注意してください。 % sudo apt-get install autoconf autotools-dev libnuma-dev libtool
TLS サポートを使用して buik=ld を使用するには、次を使用します。
% make BUILD_TLS=yes
TLSを有効にしてテストを実行する(インストールする必要があります):
tcl-tls
% ./utils/gen-test-certs.sh % ./runtest --tls
KeyDB フラッシュサポートを使用してビルドするには、次のコマンドを使用します。
% make ENABLE_FLASH=yes
KeyDB FLASH機能は実験的(ベータ)と見なされ、慎重に使用する必要があることに注意してください
依存関係またはキャッシュされたビルドオプションに関するビルドの問題を修正する
KeyDBには、ディレクトリに含まれるいくつかの依存関係があります。 依存関係が自動的に再構築されません 依存関係のソース コードが変更されます。
deps
make
ソースコードを更新するとき、またはコード内のコードを更新するとき 依存関係ツリーは他の方法で変更されていますが、必ず次のものを使用してください コマンドを実際にすべてクリーンアップし、最初から再構築するために:
git pull
make distclean
これはきれいにします:ジェマロック、ルア、ヒレディス、ラインノイズ。
また、32ビットターゲットなどの特定のビルドオプションを強制すると、Cコンパイラはありません 最適化(デバッグ目的)、およびその他の同様のビルド時オプション、 これらのオプションは、コマンドを発行するまで無期限にキャッシュされます。
make distclean
32ビットバイナリのビルドに関する問題の修正
32ビットターゲットでKeyDBを構築した後、再構築する必要がある場合 64ビットターゲットを使用する場合、またはその逆の場合は、KeyDBディストリビューションのルートディレクトリでaを実行する必要があります。
make distclean
KeyDBの32ビットバイナリをビルドしようとしたときにビルドエラーが発生した場合は、試してください 次の手順:
- パッケージ libc6-dev-i386 をインストールします (g++-multilib も試してください)。
- の代わりに次のコマンドラインを使用してみてください:
make 32bit
make CFLAGS="-m32 -march=native" LDFLAGS="-m32"
アロケーター
KeyDB構築時のデフォルト以外のメモリアロケータの選択は、 環境変数。KeyDB はコンパイルされ、libc に対してリンクされます。 デフォルトでは malloc ですが、Linux では jemalloc がデフォルトである システムズ。このデフォルトが選ばれたのは、jemallocが少ないことが証明されているためです。 libc malloc よりも断片化の問題。
MALLOC
libc malloc に対してコンパイルを強制するには、次のコマンドを使用します。
% make MALLOC=libc
Mac OS X システムで jemalloc に対してコンパイルするには、次のコマンドを使用します。
% make MALLOC=jemalloc
単調時計
デフォルトでは、KeyDBはPOSIX clock_gettime関数を使用してビルドされます。 単調クロックソース。最近のほとんどのシステムでは、内部プロセッサクロック パフォーマンスを向上させるために使用できます。注意事項はここにあります:http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/
プロセッサの内部命令クロックをサポートしてビルドするには、次のコマンドを使用します。
% make CFLAGS="-DUSE_PROCESSOR_CLOCK"
詳細ビルド
KeyDBは、デフォルトでユーザーフレンドリーなカラー出力でビルドされます。 より詳細な出力を表示するには、次を使用します。
% make V=1
キーデータベースの実行
デフォルト設定でKeyDBを実行するには、次のように入力します。
% cd src % ./keydb-server
keydb.confを提供する場合は、追加のものを使用して実行する必要があります パラメータ(設定ファイルのパス):
% cd src % ./keydb-server /path/to/keydb.conf
It is possible to alter the KeyDB configuration by passing parameters directly as options using the command line. Examples:
% ./keydb-server --port 9999 --replicaof 127.0.0.1 6379 % ./keydb-server /etc/keydb/6379.conf --loglevel debug
All the options in keydb.conf are also supported as options using the command line, with exactly the same name.
Running KeyDB with TLS:
Please consult the TLS.md file for more information on how to use KeyDB with TLS.
Playing with KeyDB
You can use keydb-cli to play with KeyDB. Start a keydb-server instance, then in another terminal try the following:
% cd src % ./keydb-cli keydb> ping PONG keydb> set foo bar OK keydb> get foo "bar" keydb> incr mycounter (integer) 1 keydb> incr mycounter (integer) 2 keydb>
You can find the list of all the available commands at https://docs.keydb.dev/docs/commands/
Installing KeyDB
In order to install KeyDB binaries into /usr/local/bin, just use:
% make install
You can use if you wish to use a different destination.
make PREFIX=/some/other/directory install
Make installはシステムにバイナリをインストールするだけで、構成は行いません スクリプトと構成ファイルを適切な場所に初期化します。これはそうではありません KeyDBで少し遊びたいだけなら必要ですが、インストールしている場合は それは生産システムのための適切な方法です、私たちはこれを行うスクリプトを持っています Ubuntu および Debian システムの場合:
% cd utils % ./install_server.sh
注:Mac OSXでは動作しません。Linux専用に構築されています。
install_server.sh
スクリプトはあなたにいくつかの質問をし、あなたが必要とするすべてを設定します KeyDBをバックグラウンドデーモンとして適切に実行し、再度起動します システムが再起動します。
KeyDB を停止および起動するには、 などの という名前のスクリプトを使用します。
/etc/init.d/keydb_<portnumber>
/etc/init.d/keydb_6379
マルチスレッド アーキテクチャ
KeyDB は、複数のスレッドで通常の Redis イベントループを実行することで機能します。ネットワーク IO とクエリ解析は同時に行われます。各接続には accept() のスレッドが割り当てられます。コア ハッシュ テーブルへのアクセスは、スピンロックによって保護されます。ハッシュテーブルアクセスは非常に高速であるため、このロックの競合は少なくなります。トランザクションは、EXEC コマンドの間、ロックを保持します。モジュールは、すべてのサーバースレッドが一時停止されたときにのみ取得されるGILと連携して動作します。これにより、モジュールが期待する原子性保証が維持されます。
ほとんどのデータベースとは異なり、コアデータ構造はシステムの最速部分です。クエリ時間のほとんどは、REPLプロトコルの解析とネットワークとの間のデータのコピーから発生します。
コードの貢献
注:送信を含む任意の形式でKeyDBプロジェクトにコードを提供することによって Github経由のプルリクエスト、プライベートメール経由のコードフラグメントまたはパッチ、または 公開ディスカッショングループの場合、あなたは利用規約に基づいてコードをリリースすることに同意します KeyDBに含まれているコピーファイルにあるBSDライセンスの ソース配布。
詳細については、このソースディストリビューションの貢献ファイルを参照してください。 情報。
