複数のRedisデータベースのポイントは何ですか？

それで、ある特定の種類のデータでkeysコマンドを使用する必要がある場合があるため、redisに格納するデータを別々のデータベースにセグメント化したいと思った場所に来ました。 。

複数のデータベースにセグメント化しても、すべてがシングルスレッドであり、コアを1つしか使用できません。同じボックスでRedisの別のインスタンスを起動しただけの場合、追加のコアを使用できます。その上、Redisデータベースに名前を付けることも、より論理的な識別子を付けることもできません。つまり、これらすべてを踏まえて、必要な追加のデータベースごとにRedisの追加のインスタンスを起動するのではなく、なぜ/いつ複数のRedisデータベースを使用したいのでしょうか？また、関連して、Redisは追加するデータベースごとに追加のコアを使用しないのはなぜですか？データベース間でシングルスレッドになる利点は何ですか？

原則として、同じインスタンス上のRedisデータベースは、RDBMSデータベースインスタンスのスキーマと同じです。

つまり、これらすべてを踏まえて、必要な追加のデータベースごとにRedisの追加のインスタンスを起動するのではなく、なぜ/いつ複数のRedisデータベースを使用したいのでしょうか？

同じredisインスタンスでredisデータベースを使用する明らかな利点が1つあり、それが管理です。アプリケーションごとに個別のインスタンスを起動し、3つのアプリがあるとします。これは、3つの個別のredisインスタンスであり、それぞれが本番環境のHAのスレーブを必要とする可能性が高いため、合計6つのインスタンスになります。管理の観点から見ると、すべてを監視したり、アップグレードやパッチを適用したりする必要があるため、これは非常に面倒になります。高I / Oでのredisのオーバーロードを計画していない場合は、スレーブを持つ単一インスタンスの方が簡単で、 SLAを満たしていれば管理が簡単です。

1つのredisインスタンスで複数のデータベースを使用したくない場合。お気づきのとおり、複数のインスタンスを使用すると、複数のコアを利用できます。データベース選択を使用する場合は、アップグレード時にリファクタリングする必要があります。複数のインスタンスを監視および管理することは難しくなく、苦痛でもありません。

実際、インスタンスに基づいて分離することにより、各データベースではるかに優れたメトリックを取得できます。各インスタンスには、そのデータセグメントを反映する統計情報があり、より適切なチューニングと、より応答性が高く正確なモニタリングが可能になります。最新バージョンを使用し、インスタンスごとにデータを分離します。

ジョナトンが言ったように、keysコマンドを使用しないでください。キーインデックスを作成するだけで、はるかに優れたパフォーマンスが得られます。キーを追加するときはいつでも、キー名をセットに追加してください。keysコマンドは、戻るのにかなりの時間がかかるので、いったん拡大するとひどく役に立ちません。

アクセスパターンによって、データを構造化する方法を決定するようにします。データを思い通りに保存してから、後でアクセスして細かく調べる方法に取り組みます。パフォーマンスがはるかに向上し、データを消費するコードのほうがずっとクリーンでシンプルであることがよくあります。

シングルスレッドに関しては、redisは速度と原子性のために設計されていると考えてください。あるデータベースのデータを変更するアクションが別のデータベースで待機する必要はありませんが、そのアクションがダンプファイルに保存されている場合、またはスレーブでトランザクションを処理している場合はどうでしょうか。その時点で、並行処理プログラミングの雑草に入り始めます。

複数のインスタンスを使用することで、マルチスレッドの複雑さをより単純なメッセージパッシングスタイルシステムに変えます。

Salvatore Sanfilippo（Redisの作成者）でさえ、Redisで複数のDBを使用することは悪い考えだと考えています。ここで彼のコメントを参照してください：

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

私はこれがどのように役立つかを理解していますが、残念ながら、Redisの複数のデータベースエラーはRedisの設計における私の最悪の決定であると考えています...実際の利益がまったくないため、内部が非常に複雑になります。実際には、データベースは、キーやVMのアクティブな期限切れなど、さまざまな理由で適切にスケーリングされません。文字列を使用してDB選択を実行できる場合、この機能がスケーラブルなO（1）辞書層として使用されていることがわかりますが、実際にはそうではありません。

DB番号を使用すると、デフォルトでいくつかのDBを使用することで、この機能とは何か、どのように使用できるかについてのコミュニケーションが向上します。いつかは複数のDBのサポートを完全にやめることができるといいのですが、この機能に多くの人が頼りになっているので、おそらく遅すぎるでしょう。

1. 単一のインスタンスに複数のデータベースを配置することの利点は本当にわかりません。複数のサービスが同じデータベースサーバーを使用していると便利なので、キーの衝突を回避できます。

2. KEYSコマンドはO（n）であり、適切にスケーリングされないため、コマンドを使用して構築することはお勧めしません。別の方法で達成できることのために何を使用していますか？のような機能KEYSが不可欠な場合、redisは最適な組み合わせではないかもしれません。

3. 彼らはFAQでシングルスレッドサーバーの利点について言及していると思いますが、主なものは単純さです。実際の方法で同時実行性を気にする必要はありません。すべてのアクションがブロックされているため、2つのことで同時にデータベースを変更することはできません。理想的には、各サーバーのコアごとに1つ（または複数）のインスタンスがあり、一貫したハッシュアルゴリズム（またはプロキシ）を使用して、それらの間でキーを分割します。もちろん、一部の機能が失われます-パイプは同じサーバー上のものに対してのみ機能し、ソートが難しくなります。

私はメールアドレスのブラックリストを実装するためにredisを使用しており、ブラックリストのレベルごとに異なるTTL値を持っているので、同じインスタンスに異なるDBがあると非常に役立ちます。

Redisデータベースは、新しいバージョンのアプリケーションをデプロイするというまれなケースで使用できます。新しいバージョンでは、さまざまなエンティティを操作する必要があります。

1つのインスタンスで複数のデータベースを使用すると、次のシナリオで役立つ場合があります。

同じデータベースの異なるコピーを、リアルタイムデータを使用した本番、開発、またはテストに使用できます。同じ目的を達成するために、人々はレプリカを使用してredisインスタンスを複製することができます。ただし、前者の方法は、既存の実行中のプログラムが適切なデータベースを選択して目的のモードに切り替える方が簡単です。

私はこの質問が何年も前のものであることを知っていますが、複数のデータベースが役立つかもしれない別の理由があります。

お気に入りのクラウドプロバイダーの「クラウドRedis」を使用している場合、おそらく最小メモリサイズがあり、割り当てた分に対して支払いを行います。ただし、データセットがそれよりも小さい場合は、割り当てが少し無駄になるため、少しお金が無駄になります。

データベースを使用すると、同じRedisクラウドインスタンスを使用して、（たとえば）開発、UAT、プロダクション、またはアプリケーションの複数のインスタンス、またはその他のものにサービスを提供できます。したがって、割り当てられたメモリをより多く使用するため、コストが少し高くなります。効果的です。

私が見ているユースケースには、それぞれ200〜300Kを使用するアプリケーションのインスタンスがいくつかありますが、私のクラウドプロバイダーの最小割り当ては1Mです。10個のインスタンスを1つのRedisに統合することで、制限をなくすことができるため、Redisのホスティングコストを約90％節約できます。このアプローチには制限と問題があることを感謝していますが、言及する価値があると思いました。