Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
Google グループ
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
Redis 本番障害から学んだコードレビューの勘所
Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以
Redis の expire はいつ実際にデータを消しているのか？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
expire で指定した時間を過ぎたデータが実際に消されるタイミングはいつなのかということを調べた。 どこから調べたの 公式ドキュメントのexpireのところ から調べた で、どうやって消してるの Redis は expire で指定した時間が過ぎたデータを消すのにふたつの戦略を使ってる。 値が取得されるときに消すよ 値が取得されるときに、その値がすでに expire 過ぎてたら消す。 値が取得されなくても消すよ 値が取得されるときに消す感じだと、たまにしか取得されないデータとかあるいは全然取得されないみたなデータはいつまでも消えなくて困るよね 値が取得されなくても定期的に消そうねって感じで消す。Redis さんは以下のような感じで消してるらしい まずランダムに20個のキーを選ぶ 選んだキーのデータが expire 過ぎてたら消す 25 個より多くの key が expired だったら1
Redis Cluster のリシャーディングとorphaned masterの話 - CyberAgent エンジニア Advent Calendar 2014 2日目
redis_cluster.md Redis Cluster のリシャーディングとorphaned masterの話 （2019/04 追記 こちらの情報は非常に古く、またRC版での結果となります。記録として残していますが参考になさらないでください） CyberAgent エンジニア Advent Calendar 2014 2日目です。 昨日に引き続き、秋葉原ラボの柿島が担当します。仕事ではHadoopクラスタの運用を中心に、秋葉原ラボのインフラ/ミドルウェアまわりを担当しています。今年はHadoop、mesos、Aerospikeと分散型のシステムを触る機会が多い1年でした。 この記事のテーマはRedis Clusterです。Redis Clusterが使えるようになるRedis 3.0.0は10月にRC1がリリースされました。2015年のQ1にstableリリースを目指しているようで
Redis、計算量の恐怖 | Akatsuki Hackers Lab アカツキハッカーズラボ
はじめまして。アカツキのサーバエンジニアのこうのです。サウザンドメモリーズで主にサーバ側のプログラム・インフラを担当しています。 今回はサウザンドメモリーズで発生した、Redisにまつわるトラブルを紹介したいと思います。 TL;DR RedisのSorted SetのZRANGE系のコマンドは計算量がO(log(N)+M)(Mは取得結果の数)になるので、 適切にLIMITをつけるなどして取得結果数を制限しないと負荷が高くなってしまいますよ、というお話。 背景 サウザンドメモリーズではバトル出撃時に一緒に出撃するフレンドやランダムに選ばれた他のプレイヤーを選択することができます。 この「ランダムに選ばれた他のプレイヤー」の選択ロジックに弊社ではRedisのSorted Setを利用した実装を行っています。 ランダムといってもすべてのプレイヤーからランダムで選んでしまってはアクティブでないプレ
redis ソート済みセット型を利用したタイムラインのリアルタイム生成アーキテクチャ
redis ソート済みセット型を利用した タイムラインのリアルタイム生成 アーキテクチャ スマートフォンコミュニティグループ 寺本 隆彦 2012 年 2 月 29 日 概要 アメブロフェイスというスマートフォン向けのブラウザベースのサービスを リリースした。アメブロフェイスは、自分のタイムライン上にフォローした芸 能人の顔写真のみが表示されるというサービスである。タイムライン形式のイ ンターフェースを実現するにあたり、一般的なアーキテクチャを採用すると、 つながり数が多くなるにつれてレスポンスタイムが遅くなる問題や、データ量 の増加に起因して運用コストが高くなる問題、ディスクへの書き込みがボトル ネックになってコンテンツの反映が遅延する問題などが起きることが想定され た。アメブロフェイスでは、これらの問題を解決すべくresisのソート済みセット 型を利用してリアルタイムにタイムラインを
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のHash型を活用するとメモリ使用量が激減
ユーザ情報のように ID をキーにした大量のデータを Redis で管理する場合、ひと工夫して Hash 型を使うと、単純に string 型を使った場合に比べてメモリ使用量が激減することを教わったので、追試してみた。 データモデル String 型を使う 各 ID のデータを Redis で管理する場合、素直にやるなら string 型で保存する。 > set object:123456 val123456 OK > get object:123456 "val123456" 非常に原始的なキーとバリューのペア。 Hash 型を使う Redis 2.2 以降では hash が機能改善され、フィールド数が一定数におさまり、フィールドのデータが一定サイズに収まると、メモリ使用量が平均して 1/5 に軽減されている。 Special encoding of small aggregate da
分散型メッセージングミドルウェアの詳細比較 | POSTD
メッセージキュー について書いている連載の続きとして、今週末は分散型メッセージングを実行するための様々なライブラリを詳細に分析していきたいと思います。今回の分析では、APIの特性、デプロイメントやメンテナンスの容易さ、そしてパフォーマンスの質を含めて2、3種類の異なる側面に着目します。メッセージキューは2つのグループに分類できます。ブローカレス（brokerless）とブローカード（brokered）です。ブローカードなキューはエンドポイント間に何かしらのサーバを挟んでいますが、ブローカレスなメッセージキューは、メッセージ送信の際でも間に何も挾まないP2Pです。 今回分析するのは以下のシステムです。 ブローカレス nanomsg ZeroMQ ブローカード ActiveMQ gnatsd Kafka Kestrel NATS NSQ RabbitMQ Redis 取り掛かりとして、ほぼ間違
redis, kyototycoon, memcacheの速度比較 - とあるエンジニアの技術ブログ
redis, kyototycoon, memcache の速度を検証したみた。 redis はデフォルト設定のまま非同期ディスク書き込みです。 kyototycoon は以前にブログに記載した memcached plugin をONにして検証しています。 今回使ったサーバスペックはこちら。 CPU Intel(R) Xeon(R) CPU X3353 @ 2.66GHz (2 core) メモリ 5993 MB HDD 386 G OS CentOS release 6.4 速度比較方法として、set, get, delete をそれぞれ100000回繰り返して 時間を測定してみました。 set redis kyototycoon memcache 1回目 4.806134939 8.653364897 4.90881896 2回目 4.698001862 9.185384035 4.
RDBMSの苦手な処理をカバーする、気の利いたNoSQL「Redis」
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます NoSQL徹底研究の特集、第5回は「Redis」です。第1回でNoSQLを利用する企業が増えていると紹介しましたが、実際にはどのような企業がどのような理由でNoSQLを採用しているのでしょうか？ ユースケースを軸に今回のテーマであるRedisを紹介します。 Redisとは Redisは、アクセスが高速なキーバリューモデルを採用するNoSQLです。非常に高速な読み書きとアクセスが可能で揮発型メモリキャッシュの「Memcached」とユースケースが似ており、永続化できるキャッシュとしても、今まで多く採用されています。 RDBMSでは面倒になりがちなケースを解決 多くのNoSQLが、一般的に文字列やJSONなどの構造情報を格納するのに対して、
Redis の仮想メモリはどうなったのか - akishin999の日記
一時期 Redis の特徴として良く挙げられていたものに、搭載している物理メモリ量以上のデータを扱える Virtual Memory という機能がありました。 仮想メモリ技術仕様 ― redis 2.0.3 documentation http://redis.shibu.jp/hacker/virtualmemory.html 個人的には結構便利そうだと思っていたのですが、公式ドキュメントを見ると 2.4 の時点で非推奨となっており、 バージョン 2.6 ではついに削除されてしまったようです。 Virtual Memory – Redis http://redis.io/topics/virtual-memory 検索しているとその代わりとして diskstore を開発中、といった情報が出てきますが、こちらもインメモリデータベースとしてより良いものを作っていく、ということに注力するため
コマンドリファレンス — redis 2.0.3 documentation
古いキー oldname を新しいキー newname にリネームする。もし新しいキーがすでに存在する場合、上書きする。
blog.katsuma.tv
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。 これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。 user system total real
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
