Redisに関する10の簡単なヒント

「2015年3月にObjectRocket.com/blogで最初に公開されました」

Redis®は素晴らしいツールであり、技術コミュニティはそれを気に入っています！ Antireztoが業界標準のインメモリデータストレージであるという小さな個人的なプロジェクトから、長い道のりを歩んできました。これには、Redisを適切に使用するための一連のベストプラクティスが含まれています。この記事では、Redisを正しく使用するための10の簡単なヒントを紹介します。

1。キーの使用をやめる

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

for key in 'keys *':
  doAllTheThings()

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

代わりに、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-ベンチマーク redis-serverを確実にするための素晴らしいベースラインを提供します は正常に動作していますが、真の負荷テストと見なしてはなりません。 。負荷テストでは、本番環境にできるだけ近い環境でアプリケーションがどのように動作するかを反映する必要があります。

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（Time To Live）を設定してください！

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

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

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

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

データがRedisインスタンスに到達することが絶対に重要な場合は、try/exceptを入力することを強くお勧めします 。ほとんどの人がRedisクライアントをfire-and-forgetに構成しているため 、キーが実際にデータベースに到達しない場合を常に計画する必要があります。この場合、Redis呼び出しに追加される複雑さはほとんどなく、重要なデータが本来あるべき場所に到達することを保証できます。

8。 1つのインスタンスをフラッディングしないでください

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

9。コアが多いほどパフォーマンスが向上しますよね？！

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

10。 HAすべてのもの！

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

RackspaceDBAサービスの詳細をご覧ください。

コメントや質問をするには、[フィードバック]タブを使用します。 セールスチャットをクリックすることもできます 今すぐチャットして会話を始めましょう。

Rackspace Cloudの利用規約を表示するには、ここをクリックしてください。