サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
redis-documentasion-japanese.readthedocs.io
Redis はなぜ他のキー・バリューストアと違うのか?¶ それには 2 つの理由があります。 Redis は、複雑なデータタイプをもつことができ、またそれらに対して定義されたアトミックな操作を備えている、という点で、他のキー・バリュー DB とは異なる進化を遂げてきました。Redis のデータタイプは基礎的なデータ構造と深い関わりをもち、付加的な抽象レイヤを介することなくプログラマに公開されています。 Redis はディスクにも永続化を行いますが、インメモリデータベースであり、そこにはトレードオフが存在します。つまり、メモリ容量より大きなデータ・セットを保持できない代わりに、高速な書き込みと読み込みを達成します。インメモリデータベースのもうひとつの利点は、複雑なデータ構造のメモリ表現は、同じ構造をディスクに格納するのに比較すると、よりシンプルに操作できる、というものです。そのため Redi
Redis の管理¶ このページでは Redis の管理に関する話題を記述します。すべてのトピックは、FAQ 形式で完結しています。新しいトピックは随時追加される予定です。 Redis セットアップヒント¶ Linux オペレーティングシステム 上に Redis をデプロイすることを推奨します。Redis は OSX でも十分に、またしばしば FreeBSD や OpenBSD でもテストされています。しかし、私たちは Linux にて主な負荷テストを実施しており、またほとんどのプロダクション環境は Linux で稼働しています。 Linux のカーネルを overcommit memory setting to 1 としてください。 /etc/sysctl.conf に vm.overcommit_memory = 1 を設定し、リブートもしくは即時反映のため sysctl vm.ove
レプリケーション¶ Redis のレプリケーションでは、マスター・スレーブ型のレプリケーションを簡易に設定できます。マスター・スレーブ型レプリケーションでは、スレーブサーバーはマスターサーバーの正確なコピーになります。以下は、Redis レプリケーションについての、いつくかの重要なポイントです。 Redis は非同期レプリケーションを採用しています。ただし Redis 2.8 以降、スレーブはレプリケーション・ストリームから、処理されたデータを定期的に受信するようになりました。 マスターは複数のスレーブをもてます。 スレーブは他のスレーブからの接続を受け付けられます。同じマスターに多数のスレーブを接続するだけでなく、スレーブは graph-like に他のスレーブと接続できます。 Redis のレプリケーションはマスターサイドでノン・ブロッキングです。つまり、1 つかそれ以上のスレーブが初
注釈 このドキュメントは Redis Documentation の非公式翻訳(未完成)です。 誤訳を見つけたら 翻訳リポジトリ に Issue を登録してください。 留意事項: このRedisドキュメントは, redis-doc github repository (原文のリポジトリ)にて raw (computer friendly) フォーマットでも入手できます。Redisドキュメントは、 Creative Commons Attribution-ShareAlike 4.0 International license のもとで公開されています。 Work in progress...
Pub/Sub¶ SUBSCRIBE, UNSUBSCRIBE, および PUBLISH は、 Publish/Subscribe messaging paradigm を実装しています。送信者(パブリッシャー)はメッセージを特定の受信者(サブスクライバ)へ向けて送信するようにはプログラムされていません。代わりに、特定のチャネルにメッセージを配信します。(存在するとしたら)どのようなサブスクライバが存在するのかという知識はもっていません。サブスクライバは、関心のある一つもしくは複数のチャネルを購読し、そのチャネルからのみメッセージを受信します。(存在するとしたら)どのようなパブリッシャーが存在するのかという知識はもっていません。このような、パブリッシャーとサブスクライバの疎な関係は、スケーラビリティとダイナミックなネットワークトポロジーを可能にします。 たとえば、’foo’, ‘bar’
メモリ最適化¶ このページは作業中です。現在のところ、メモリに関する問題が発生したときにチェックするべき項目のリストにすぎません。 小さな集約データ型のための特別なエンコーディング¶ Redis 2.2 以降、多くのデータ型は、ある一定のサイズ以下であれば、使用する空間が小さくなるように最適化がされています。Hash, List, 整数型からなる Set, および Sorted Set は、既定の上限より要素数が小さく、かつ個々の要素のサイズが上限を超えない場合は、非常にメモリ効率の良い方法でエンコードされます。このエンコーディングにより、メモリ使用量は 最大で 10 分の 1 、平均で 5 分の 1 程度に削減されます。 これは、ユーザーやAPIからは完全に隠蔽されます。また、CPU とメモリのトレードオフとなるため、エンコードを適用する最大要素数や各要素の最大サイズは redis.co
キー・スペース通知¶ 重要 keyspace notifications は 2.8.0 以上で提供される機能です。 機能概要¶ keyspace notifications は、Redis データセットに対するなんらかの変更イベントを、クライアントが Pub/Sub チャネルで受け取るための仕組みです。 以下は、受け取れるイベントの例です: あるキーに作用するすべてのコマンド LPUSH 操作を受けたすべてのキー database 0 の中で、expire されたすべてのキー イベントは、ノーマルな Redis の Pub/Sub レイヤを介して配信されます。そのため、Pub/Sub を実装しているクライアントであれば、修正を加えることなくこの機能が利用できます。 Redis の Pub/Sub は現在のところ fire and forget であるため、 信頼性のある通知 を必要とする
大量データのインサート¶ しばしば Redis インスタンスは、数百万のキーをできるだけ高速に作成するため、既存の、またはユーザーが生成する大量のデータを、短時間でロードする必要があります。 これは mass insertion と呼ばれます。このドキュメントでは、Redis にできるだけ高速にデータを投入する方法について、情報を提供することを目的とします。 プロトコルを使うんだ, Luke¶ 大量データの投入に、標準の Redis クライアントを使うことは、いくつかの理由により良い方針ではありません: コマンドをひとつひとつ送信するナイーブなアプローチは、毎回のコマンドの度にラウンドトリップが発生するため低速です。パイプライニングを使うことも可能ですが、大量のレコードを追加するためには、書き込みコマンドを発行する一方で、同時にできるだけ高速に応答を読み込まなければいけません。 ごく少数の
入門 : Redis のデータ構造と概念¶ Redis は プレーン なキー・バリューストアではありません。実質的には、異なる種類の値をサポートする データ構造サーバー (data structures server) といえます。つまり、従来のキー・バリューストアでは、キーに文字列値を関連づけるのに対して、Redis では値はシンプルな文字列に限定されず、もっと複雑なデータ構造を格納することができます。以下のリストは、Redis でサポートされるすべてのデータ構造の一覧です。このチュートリアルで、それぞれについて説明していきいます: バイナリ・セーフな文字列 Lists: 文字列のコレクション。挿入された順序を保つ。基本的には linked list. Sets: ユニークで、順序づけられない文字列のコレクション。 Sorted sets: Sets に似ているが、すべての要素には スコ
Redis による分散ロック¶ 異なるプロセス同士が、相互に排他的な方法で共有リソースに対して操作を実行する、という環境において、分散ロックは非常に役に立ちます。 Redis を使った DLM (Distributed Lock Manager) の実装については、多くのライブラリやブログポストがあります。しかし、ライブラリごとに異なるアプローチがとられており、またその多くは、より複雑なデザインと比較するとシンプルで、そのぶん保証される内容が低いアプローチとなっています。 このページは、Redis 上で分散ロックを実装するにあたり、標準的なアルゴリズムを提供することを目指すものです。私たちはここで Redlock と呼ぶアルゴリズムを提供します。これは DLM 実装の一種で、よく見かけるような、ひとつのインスタンスを使うアプローチよりも安全である、と私たちは考えています。コミュニティがこの
このページでは Redis の永続化について、技術的な説明を提供します。すべての Redis ユーザーはこの内容に目を通しておくことを推奨します。Redis の永続化と障害耐性の保証について、より広範に概観するため Redis persistence demystified も参照すると良いでしょう。 Redis の永続化¶ Redis は、守備範囲の異なる永続化オプションを提供します: RDB 永続化は、ある時点のデータセットのスナップショットを、特定の間隔ごとに作成します。 AOF 永続化では、サーバーが受け付けたすべての書き込みコマンドを記録します。サーバーは起動時にログをリプレイし、元のデータを再構成します。コマンドは Redis プロトコルと同じフォーマットを使い、追記方式で記録されます。ログが大きくなりすぎたら、Redis はバックグラウンドでそれをリライトします。 サーバーが
トランザクション¶ MULTI, EXEC, DISCARD および WATCH は Redis におけるトランザクションの基本です。これらは、複数のコマンドの実行をひとつのステップで行えるようにします。その際、2 つの重要な点が保証されます。 トランザクション中のすべてのコマンドは直列化され、順に実行されます。他のクライアントにより発行されたリクエストが、Redis トランザクションの 途中に 入り込むことはありません。このことは、コマンド群がひとつの隔離されたオペレーションとして実行されることを保証します。 すべてのコマンドが実行されるか、ひとつも実行されないかのいずれかであり、すなわち Redis のトランザクションはアトミックです。 EXEC コマンドはトランザクション中の全コマンドの実行のトリガです。もし、クライアントがトランザクションの途中で、 MULTI [訳注: EXEC
Redis を LRU キャッシュとして使う¶ Redis をキャッシュとして使う際、新しいデータを追加するときに自動的に古いデータを追い出すようにできると便利です。この振る舞いは、人気の高い memcached システムのデフォルトの振る舞いであるため、開発者の間では非常によく知られています。 LRU は、実際にはエビクション・メソッドのひとつにすぎません。このページでは Redis のメモリ使用量を制限するための ‘maxmemory’ ディレクティブについて、より一般的なトピックを扱います。また、Redis で使用されている LRU アルゴリズムについても扱います。Redis の LRU アルゴリズムは、実際には正確な LRU ではなく、その近似です。 メモリ設定のためのディレクティブ¶ ‘maxmemory’ ディレクティブは、データセットに対して指定された量のメモリを使用するよう
このページを最初にブックマークしてみませんか?
『redis-documentasion-japanese.readthedocs.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く