Redisの10の簡単なヒント

Redisは現在、技術コミュニティで注目を集めています。 Antirezの小さな個人的なプロジェクトから、メモリ内データストレージの業界標準になるまでには長い道のりがあります。これに伴い、Redisを適切に使用するためにほとんどの人が同意できる一連のベストプラクティスが提供されます。以下では、Redisを正しく使用するための10の簡単なヒントを紹介します。

1。キーの使用をやめる*

さて、多分あなたに向かって叫ぶことはこの記事を始めるための素晴らしい方法ではありません。しかし、それはおそらく最も重要なポイントです。あまりにも頻繁に、redisインスタンスを見て、簡単なcommandstatsをプルアップし、まばゆいばかりのKEYSが私をじっと見つめているのを目にします。公平を期すと、プログラムの観点からすると、次のような動作をする擬似コードを使用するのが理にかなっています。

for key in 'keys *':
  doAllTheThings()

しかし、たとえば1,300万個のキーがあると、状況は遅くなります。 KEYSはO（n）であり、nは返されるキーの数であるため、複雑さはdbsizeによって制限されます。また、この操作全体の間、インスタンスに対して他に実行することはできません。

代わりに、SCANをチェックしてください。SCANを使用すると、代わりにデータベースを段階的にスキャンできます。これはインターレーターで動作するため、必要に応じて停止して移動できます。

2。 Redisの速度を低下させているものを確認する

Redisには最も詳細なログがないため、インスタンス内で何が起こっているのかを正確に追跡するのは難しいことがよくあります。幸い、Redisには、これを表示するためのcommandstatユーティリティが用意されています。

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

これにより、すべてのコマンドの内訳、実行された回数、実行にかかったマイクロ秒数（呼び出しごとの合計と平均）がわかります

これをリセットするには、CONFIG RESETSTATを実行するだけで、まったく新しいスレートが得られます。

3。福音の真実ではなく、Redis-Benchmarkをベースラインとして使用する

Redisの作成者であるSalvatoreは、それを巧みに表現しています。「GET / SETを実行してRedisをテストすることは、雨が降ったときにミラーを掃除するのがどれだけ優れているかを確認するフェラーリをテストするようなものです。」多くの場合、Redis-Benchmarkの結果が最適ではないのはなぜかと疑問に思う人がいます。ただし、次のようなさまざまな要因を考慮する必要があります。

• どのようなクライアント側の制限に遭遇する可能性がありますか？
• バージョン管理に違いはありましたか？
• 実行されているテストは、アプリケーションが実行する内容に関連していますか？

Redis-Benchmarkは、redisサーバーが異常に動作していないことを確認するための優れたベースラインを提供しますが、真の「負荷テスト」と見なしてはなりません。負荷テストは、アプリケーションの動作を反映し、可能な限り本番環境に近い環境からのものである必要があります。

4。ハッシュはあなたの親友です

夕食にハッシュを招待します。ワインと食事のハッシュ。チャンスを与えるだけで、彼らがどんな幸せをもたらすことができるかに驚かれることでしょう。以前、このような重要な構造が多すぎるのを見たことがあります：

foo:first_name
foo:last_name
foo:address

上記の例では、fooはユーザーのユーザー名である可能性があり、それぞれが個別のキーです。これにより、エラーの余地が追加され、フォールドに不要なキーが追加されます。代わりに、ハッシュを検討してください。突然、キーが1つだけになりました：

127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"

5。そのTTLを設定してください！

可能な限り、期限切れのキーを利用してください。完璧な例は、一時的な認証キーのようなものを保存することです。認証キーを取得するとき（例としてOAUTHを使用しましょう）、多くの場合、有効期限が与えられます。キーを設定するときは、同じ有効期限で設定すると、Redisがクリーンアップします。 KEYS *がこれらすべてのキーを反復処理する必要はもうありませんね？

6。適切な立ち退きポリシーの選択

キーのクリーンアップのトピックに取り組んでいる間、立ち退きに触れましょう。 Redisインスタンスがいっぱいになると、Redisはキーを削除しようとします。ユースケースに応じて、有効期限が切れるキーがあると仮定して、volatile-lruを強くお勧めします。キャッシュのようなものを実行していて、有効期限が設定されていない場合は、allkeys-lruを検討できます。ここで利用可能なオプションを確認することをお勧めします。

7。データが重要な場合は、試して/除外してください

データがRedisインスタンスに到達することが絶対に重要な場合は、try/exceptを設定することを強くお勧めします。ほとんどすべてのRedisクライアントは「ファイア・アンド・フォーゲット」に構成されているため、キーが実際にデータベースに到達しない場合は常に考慮する必要があります。この場合、redis呼び出しに追加される複雑さはほとんどなく、重要なデータが本来あるべき場所に確実に届くようにすることができます。

8。 1つのインスタンスを氾濫させないでください

可能な限り、ワークロードを複数のRedisインスタンスに分割します。バージョン3.0.0以降、Redisクラスターが利用可能になりました。 Redis Clusterを使用すると、キー範囲に基づいて、指定されたマスター/スレーブのセット間でキーを分解できます。クラスターの背後にある魔法の完全な内訳はここにあります。また、チュートリアルを探している場合は、もう探す必要はありません。クラスタリングがオプションでない場合は、名前の間隔を空けて、キーを複数のインスタンスに分散することを検討してください。データの分割に関する驚くべき記事は、redis.ioのWebサイトにあります。

9。より多くのコア=より良いですよね？！

違う。 Redisはシングルスレッドプロセスであり、永続性を有効にしている場合、最大で2つのコアを消費します。同じホストで複数のインスタンスを実行する予定がない限り（できればその場合は開発テストのみ）、Redisインスタンスに3つ以上のコアは必要ありません。

10。 HA All the Things！

Redis Sentinelは現在非常によくテストされており、多くのユーザーが本番環境で実行しています（ObjectRocketが含まれています）。アプリケーションをRedisに大きく依存している場合は、オンラインを維持するためにHA（高可用性）ソリューションを検討する必要があります。もちろん、すべてを自分で管理したくない場合は、ObjectRocketが24時間365日の消費をサポートするHAプラットフォームを提供しています。ぜひお試しください。