Redisに耐久性が加わったAmazon MemoryDB for Redisが登場 | DevelopersIO
MemoryDB はElastiCache の約1.5倍、Aurora の約1.2倍と若干高価です。 耐久性を重視するMemoryDBはElastiCacheで言うところの「クラスターモード」しか存在しないため、{シャード数} x {ノード数/シャード} x {インスタンス利用費} 分の利用費が発生する点にもご注意ください。 最後に Redisを永続的なデータストアとしても使える Amazon MemoryDB for Redis が爆誕しました。 データ耐久性のトレードオフとして書き込み速度は低下したものの、読み取りの速さはまさにRedisです。 クライアントはRedisコマンドを投げるだけで、MemoryDBが良しなにやってくれるため、使い勝手が良さそうです。 今後はDynamodB+DAXの代替として検討したり、RDB+キャッシュRedisなシステムを MemoryDB に集約すると
cloudpackブログ - Redisってなんじゃ？（レプリケーションとクラスタリング）
Redisはとても高速ですが、メモリ量の圧迫や負荷によっては分散が必要な場合があり、 分散の種類としては、レプリケーションとクラスタリングがあります。 レプリケーションは、マスタに書き込んだデータをスレーブにコピーすることで、書き込みはマスタ、 読み取りはスレーブと担当を分けることで負荷を分散させます。 読み取りにはマスタも参加することもあります。 クラスタリングは、キーのハッシュ値等によって保存するサーバーが決まり、書き込みと読み取りの両方を 同時に負荷分散します。 ○レプリケーション レプリケーションはRedisの基本機能として提供されているので、すぐに利用することができ、 設定も簡単で、スレーブサーバーの設定ファイルに1行追記するだけとなります。 それでは試してみます。 ここではRedis1をマスター、Redis2をスレーブとします。 インストール＆設定 ○Redis1（10.0.0
ElastiCache + Redis に出てくる概念と、クラスタモードごとの違い - nyamadoriの日記
はじめに Web サイト表示速度向上の一環として、仕事で、ElastiCache + Redis によるキャッシュ層を導入する。 導入にあたり、ElastiCache + Redis で利用するノードタイプ（インスタンスタイプ）や、制限などの事前調査が必要になった。 ElastiCache + Redis は、ノードタイプやクラスタの種類によって、機能サポートが異なり、混乱するところが多々あったため、AWS のドキュメントを参考に、分かりにくいところをまとめた。 これから導入する段階なので、AWS のドキュメントの内容以上のことは書いていません。 運用についてとか、ハマったところなどの記述はありません。 内容におかしいところがあれば教えてください 概念 実際に使うかどうかに関わらず、シャードやレプリカという用語がバンバンでてくるので、まとめる。 参考: http://docs.aws.am
LINE LIVE チャット機能を支えるアーキテクチャ - LINE ENGINEERING
! This post is also available in the following languages. 英語, 韓国語 LINE株式会社のOklahomerです。 本記事では、LINE LIVEという動画配信サービスのチャット機能が、どのような構成で成り立っているのか紹介します。 チャットの紹介 LINE LIVEのiOS/Android アプリでは、配信中の動画を視聴しながらリアルタイムにコメント投稿できるチャット機能を提供しています。この機能の役割は、視聴者同士が対話を楽しむだけにとどまりません。配信者が視聴者のコメントに返答するという形で配信者と視聴者の接点として機能したり、また配信者がコメント内容に従って企画を進めるなど、配信者と視聴者が一体となって配信を作り上げていく上でも重要な機能となっています。 これが有名人による配信となれば当然視聴者数も多くなりますし、その配信
3分でRedisのpub/subを使ってみる【redis】 - DRYな備忘録
pub/sub オンメモリのKVSでありながら、なおかつディスクに永続化する機能も持つRedisですが、あるクライアントプロセスから別のクライアントプロセスへ通知を送る、いわゆる「pub/sub」も提供しています。 「pub/sub」とは「publish」と「subscribe」の略で、日本語訳するなら「発行」と「購読」。あるチャンネルに誰かがイベントを「発行」すると、そのチャンネルを「購読」している人すべてにそのイベントが通知される、といった意味。 ゴール 3分でredisのpub/subを体験してみる redisのインストールなどは MacにRedisをインストールしてことはじめ【redis】【MacOS】 - DRYな備忘録をご参考。 登場人物 redisサーバプロセス redisクライアントプロセス その1 redisクライアントプロセス その2 で、クライアントその1がSUBSC
Redis に保存されてる値を見ようと思った時に覚えておきたい redis コマンド | そんなこと覚えてない
設定したりもっと細かい作業をしたい場合は help コマンドを使う。 種類ごとのヘルプをみたい場合は @ をつけるとよい 例えばリスト関連のコマンドを知りたいなら > help @list といった感じ。 以下は解説 keys 登録されている key がわからないと何もできないので、keyの一覧をみる方法 > keys * 引数にはパターンを入力する hogeではじまるものに絞りこみしたい場合は > key hoge* とかする。shell の場合はアスタリスクはエスケープする必要があるのに注意 $ redis-cli keys \* type redis は key に格納された値の種類によって取得コマンドが違うらしい。 値をみるために種類の確認が必要。 hoge というキーがあった場合は > type hoge とする。 返す値としては string list set zset has
RailsをRedisで「効率よく」高速化してみる（＋おまけ） - ぱろっと・すたじお
仕事でコードを書く時間が減ると、別なところでコードを書きたくなるもので、 久々にチェンクロパーティーシミュレーター（以下ccpts）の システム部分をいじっていました...φ(･ω･｀) ccpts.parrot-studio.com 以前react化したり、Rails5に置き換えたりしたわけですが・・・ parrot.hatenadiary.jp parrot.hatenadiary.jp ・・・どうしても「遅い」ってのが問題でして(´-ω-) react化＝表示自体を全てJavaScriptで制御となると、 JSを解釈するまでメイン部分が描画されないわけで、 どうしても体感で遅くなってしまいます 「部分的react化」により、見かけ上の描画を早くすることは可能ですが、 私のスキルが追いついていないので、それはいったん置いておいて・・・Σ(・ω・ノ)ノ 私にできるのは「APIの速度改善」
Cassandra vs Riak vs Redis 〜 NoSQLの性能を比較してみた
CassandraとRiakとRedis、どれが一番速いのかなーってことで性能を比較してみました。 後ほど詳しく書きますが、若干Redisに有利なベンチマークの取り方しています。 各ミドルウェアの条件と特徴はこれ。 アーキテクチャ比較 version: 2.0.5 構成: cluster depend: Java, Python データモデル: カラム指向 アーキテクチャ: Gossip ノード管理: 設定ファイル/コマンド/GUI 無停止ノード管理: 無停止 CUIクライアント: cqlsh 管理ツール: 付属のweb ui Cassandraのインストール〜クラスター構築はこちらをどうぞ。 Cassandra2系のクラスターをRHEL系LInuxに構築する version: 2.0.0pre11 構成: cluster depend: Erlang データモデル: Key-Value
今更だが、RedisのSlaveのExpireは信用してはいけない - maedamaのブログ
また、障害起因でのブログです。忘れないようにこちらにメモります。 http://trapezoid.hatenablog.com/entry/2013/02/10/035020 にも詳しくかいてあります。 とあるreplication をくんでいるRedisの系統があった。Replication をくんではいるものの、とある事情により Slaveには参照していなかったが、突如 Masterのロードがあがったので Slave に負荷分散する必要が生まれ、あれ？大丈夫だっけ？とある事情ってなんだっけ？ってなったのでそのとある事情についてまとめます。 Slave の expireは信用できない。 結論だけ述べると、 MASTER に 以下のようなコマンドうち SETEX foo 3 1 #key Fooに3秒のexpireで1というvalueをset 10秒後にSlaveにGetコマンドをうつと
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
