Redis at LINE中村 俊介 (LINE) / Redis at LINE 「LINE Developer Meetup #36 - Redis -」での発表資料です https://line.connpass.com/event/86642/
Twitterのキャッシュを支えるRedis - ワザノバ | wazanova
https://www.youtube.com/watch?v=rP9EKvWt0zo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのYao Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。 1) Redisを採用している理由 キャッシュだけで、ストレージとしては利用していない。 主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。 以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、（ユーザが閲覧している範囲に追加反映するということなの
redisのデータ型の概要と利用例まとめ
RDBMSの代替としてredisを使うことになり、DB設計する上で考慮すべき型の概要と利用法をまとめる。 間違いやもっと良い使い方があれば教えてください＾＾ ■String - 文字列型 ・概要 １つのkeyに対して1GBまでの文字列を１つ持つことが出来る。基本。 ・使いどころ JPEGイメージ、シリアライズされたオブジェクト情報など単体で持つ時。 （他の型の基本になってるので、これ単体で使うと言うより応用する感じ？単体で十分なとき等で使う？） ■List - リスト型 ・概要 文字列型のリスト。値を追加した順序が保持される。値は重複OK！ リスト前後からの出し入れ、リストの範囲指定での取り出し等の操作ができる。 ・使いどころ 時刻または日付を保持するような情報。TwitterのTLの様な追加順に並ぶ一連のデータ。 要素の追加削除がリストの先頭や末尾（そうでない場合は適さない）に高頻度に発
巨大なデータを扱う場合のRedisの運用戦略 - Qiita
はじめに Read/Writeともに高速で，様々なデータの持ち方が可能なことでキャッシュDBとして人気のあるRedisですが，何も考えずに実運用システムで使用しているとデータが肥大化してしまい非常に扱いにくくなることがあります． 今回は，データの肥大化とともに顕在化する問題と，データの肥大化に対する戦略についてまとめたいと思います． データの肥大化時に顕在化する問題 何のキーが入っているか分からなくなる Redisはオンメモリ型のKVSであるため，データがある程度増えてくるとサーバのメモリ容量を圧迫し始めます． このような状態で，プロダクション環境に対して keys * などをやってしまうと，一時的にメモリ使用量が跳ね上がり，メモリ使用量を抑えるためにRedisがキーを削除したり，OOM KILLERにRedis Serverごと殺されてしまう可能性があるため，そういったコマンドはうてなく
Redis勉強会資料(2015/06 update)
Redis勉強会の資料です。2013年に初版をアップしました。2015年6月にRedis-Clusterの内容を追記して再アップを行っています。
RedisサーバのCPU負荷対策パターン - ゆううきブログ
Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R
Redis 4.0正式リリース。モジュールによる機能やデータの拡張が可能に、新レプリケーションエンジンで運用が改善
Redis 4.0正式リリース。モジュールによる機能やデータの拡張が可能に、新レプリケーションエンジンで運用が改善 Redis 4.0はモジュールによる機能拡張の実現、新しいレプリケーションエンジンによる高速なレプリケーション、新しいアルゴリズムの追加によるキャッシュの改善、フラッシュの非同期実行など、多くの機能追加が行われています。 リリースノートには、「内部における変更に関していえば、4.0はおそらくこれまででもっとも劇的なリリースだろう」と、次のように記されています。 Note that 4.0 is probably one of the most extreme releases of Redis ever made in terms of changes inside the internals 新しいレプリケーションエンジン「PSYNC2」 Redis 4.0では新しいレプリ
ソシャゲ開発経験から学んだゲームに Redis を使う際の Tips
近年の KVS では割と Redis が覇権を取っていることもあり(当社比), 社内の多くのプロジェクトで Redis を使用するようになりました. ということでノウハウ的なのも溜まってきたのでまとめたいと思います. (大量のユーザーデータを扱うソシャゲにしか当てはまらない部分もあるかと思います) 単純にパフォーマンスを RDB < Redis と思い込んでとりあえずでキャッシュしない 「Redis は速い」と言われますが, インデックスをちゃんと貼った RDB のクエリも そこまで遅いわけではありません. 結局通信コストの方が遥かに大きいので内部の 取得時間差はトータルで考えると多くの場合誤差です. 特に RDB の主キーのみで取得できるようなデータを Redis にキャッシュすることに メリットはありません. キャッシュするコードを書くコストの方が高くつきます. キャッシュするのは R
Redisでスコアを複数設定できるランキングを作ってみた
ランキングを作っているとスコアを複数設定したいことがよくあると思います。 例えば「得点が同じだったら早くその得点を出した人優先」とか「勝ち点が同じだったら得失点差が大きい方優先」とかのように、 最初の基準で順位を決められなかった場合の第二基準が欲しいみたいな場合です。 ランキングを作るのにはRedisのSorted Setを使うのが便利ですが、残念ながらSorted Setはひとつしかスコアを設定できません。 少し前にどうやったら実装できるかと社内チャットで話題に上ったので、試しにRedis::LeaderBoardMulti(仮名)という名前で書いてみました。 shogo82148/p5-Redis-LeaderBoardMulti 使い方 メソッドの名前はRedis::LeaderBoardにあわせてありますが、 スコアが複数指定できるようになった関係でちょっと変わってます。 use
Redis の Sorted Sets でランダムにメンバーを取得する - Qiita
Happy Elements 株式会社 カカリアスタジオ Advent Calendar 2016 19日目の記事です。 概要 自分の所属チームのアプリではユーザーランキングの実装に Redis の Sorted Sets を使用しています。Redis についての基本的な解説は別の記事に譲り、この記事ではそのスクリプティング機能（EVAL コマンド）を使った実装について紹介します。 以下のような状況を考えます。（架空の設定です） 100万人のユーザーがそれぞれ自分のスコアを持っており、それによってリアルタイムにランキングされています。スコアはユーザー同士のバトルによって変化します。例えば自分より大きなスコアのユーザーに勝利すれば自分のスコアが大きく加算され、小さなユーザーに勝利すれば小さく加算されます。対戦相手の選択には自分と同程度のスコアをもったユーザーを選択するのが望ましく、また、毎回
Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いぬごやねっと