Redisでアクセスランキングを実装
ニュースサイトのサイドメニューでよく見かける「アクセスの多かった記事」のようなランキングを Redis のデータ型 Sorted Set で実装する方法をメモ。 東洋経済の例 Redis の Sorted Set を使ったアクセスランクの表現 Redis のデータ型 sorted set は文字通り順序付けられた集合。 key 単位で集合を定義でき、各メンバーはスコアを持ち、スコアによって集合内で順位付けられる。 メンバーを記事、スコアをアクセス数とみなして、アクセスランクを表現する。 日別ランキングであれば下図のようになる。 週別ランキングであれば下図のようになる。 スコアの大きい順(=アクセスの多い順)に並べればアクセスランキングの完成となる。 Sorted Set の操作 次にアクセスされた時の Sorted Set の操作を考える。 キーは YYYYMMDD で持ち、アクセスされる
HTTP ベンチマークツール wrk についてメモ
モダンな HTTP ベンチマークツール wkr の簡単な使い方についてメモ。 wrk の特徴は以下。 C で書かれている マルチコア CPU を 活かした高負荷をかけられる スレッドと epoll/kqueue のイベントドリブンを活用して負荷をスケールさせる(NOTICE ファイルを読むと Redis Event Library(ae event loop) を拝借しているようです) Lua スクリプトで HTTP クライアントの処理や実行結果のレポートをカスタマイズできる Installing wrk in CentOS 6 まずはビルドに必要なパッケージをインストールします。 $ sudo yum install git $ sudo yum groupinstall 'Development Tools' $ sudo yum install openssl-devel opens
route53のネガティブキャッシュについて
DNS にはネガティブキャッシュの仕組みがあり、存在しないドメイン(NXDOMAIN)を問い合わせた時は、そのドメインが存在しないということを一定期間キャッシュしてくれる。 ドメイン追加前にうっかりフライングで新規ドメインを名前解決しようとするとネガティブキャッシュされていまい、ドメイン追加してもキャッシュが expire されるまでは名前解決できなくなってしまう。 一般的な DNS サービスでは、SOA の minimum 値がネガティブキャッシュ期間となる。 Amazon の DNS サービス route 53 はネガティブキャッシュ期間を次のルールで決定している。 The minimum time to live (TTL). This value helps define the length of time that an NXDOMAIN result, which indic
SSHの多重接続について
tl;dr デプロイツールによっては 同じサーバに SSH で何回もコマンドを実行することがある(ansible とか)。 コマンドごとに毎回コネクション(トンネル)を確立するとオーバーヘッドも大きくなる。 OpenSSH は $HOME/.ssh/config に次の設定を書くことで、接続を多重化(multiplex)することができる。 # $HOME/.ssh/config Host machine1 HostName machine1.example.org ControlPath ~/.ssh/controlmasters/%r@%h:%p ControlMaster auto ControlPersist 1h multiplex 前後の速度差 SSH を使ってリモートサーバで echo コマンドを実行した時の速度差を計測 before multiplex $ time ssh
PostgreSQL9.3をカラム指向ストレージ(cstore_fdw)に対応させる
分析向けデータベースを展開している CitusDB が PostgreSQL を列指向ストレージ対応させる foreign data wrapper(cstore_fdw) をオープンソース化したので、とりあえずインストールしてみた。 cstore_fdw の特徴 github の cstore_fdw に特徴がまとめられている。 http://citusdata.github.io/cstore_fdw/ 箇条書きすると Faster Analytics – Reduce analytics query disk and memory use by 10x Lower Storage – Compress data by 3x Easy Setup – Deploy as standard PostgreSQL extension Flexibility – Mix row- and c
exponential backoffのメモ
exponential backoffとは? データ送信処理が失敗して再送信するときに、失敗回数が増えるに連れて再送信するまでの待ち時間を指数関数的に増やす仕組みを exponential backoff という。 有名な例としては Carrier sense multiple access with collision detection (CSMA/CD) や Carrier sense multiple access with collision avoidance(CSMA/CA) といった通信方式で、失敗回数 N に対して、[0, 2^N-1] からランダムな数を選び、その slot time 分だけ待って再送信するようになっている。 ランダムに選んでいるのは、複数の通信が同じタイミングで失敗した時に、また同じタイミングで再送されないようにするため。 また、失敗回数が一定値を超え
djbが開発したcdb(constant database)メモ
ふと組み込み型 kvs の cdb(constant database) の仕様を知りたくなったのでメモ。 URL http://cr.yp.to/cdb.html http://en.wikipedia.org/wiki/Cdb_(software) http://thedjbway.b0llix.net/cdb/overview.html 特徴 オフィシャルサイトの “What is it?” のコピペ cdb is a fast, reliable, simple package for creating and reading constant databases. Its database structure provides several features: Fast lookups: A successful lookup in a large database norma
Dead Letter Channel Pattern with RabbitMQ
メッセージングシステムで送信されたメッセージが正常に処理されなかった場合どうするのか? RabbitMQ 2.8 以降では expire したメッセージや拒否されたメッセージを dead letter として専用の exchange に転送する事ができる。 dead letter になるユースケース 以下のケースで、メッセージは dead letter になる The message is rejected (basic.reject or basic.nack) with requeue=false The TTL for the message expires Enterprise Integratin Patterns との対比 Gregor Hohpe & Bobby Woolf の “Enterprise Integratin Patterns” では 前者は Invalid M
ØMQをつかってLevelDBをClient-Server型にする
Google が開発する KVS の LevelDB はライブラリーとしてのみ提供されており、そのままではクライアント-サーバ型では使えない。 There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library. http://code.google.com/p/leveldb/ ググったところ、ØMQ(zeromq) を使ってサーバサイドを実装した LevelDB Server というプログラムがあった。ØMQ のお勉強を兼ねて実装をメモ。 LevelDB Server 概要 2011年11月に github 公開。その後、放置(LevelDB は2011年
Kestrel:Reliable Read
メッセージングシステムで、dequeue 後に正しく処理できずに異常終了したらどうなるのか? Twitter などで利用されている Kestrel には reliable read という仕組みがあり、一度 dequeue したアイテムの処理中にエラーが発生しても、キューの先頭に enqueue できる。 この動作を実際に確認してみた。 Reliable Read Command Memcached プロトコルで reliable read をするには、キューからアイテムを取得する際に / に続けて以下のオプションを指定する。 /open : 一時的に dequeue /close : dequeue を確定 /abort : dequeue を取り消し、queue の先頭に enqueue Reliable Read Examples 以下の4パターンについて、キューの処理と peek
GNU Parallel作者が書いたParallel:The Command-Line Power Toolを読んだ
プログラムを並列処理する GNU Parallel というプログラムがある。このプログラムの作者 Ole Tange が usenix February 2011, Volume 36, Number 1 に “The Command-Line Power Tool” という記事を書いていたので読んでみた。6ページで GNU Parallel の主要機能がひと通り解説されているので、GNU Parallel の機能をピンポイントでしか知らない人(=自分)が読むと、いろいろと使いどころが湧いて来ると思う。 GNU Parallel: The Command-Line Power Tool February 2011, Volume 36, Number 1 Authors: Ole Tange https://www.usenix.org/publications/login/februar
[PostgreSQL][Redis]redis_fdwを使ってみた
大量のユーザリクエストを Redis に書き込み、foreign data wrapper(FDW) を使って定期的に PostgreSQL にロードするユースケースが PgCon 2013 で発表されていた。 Using PostgreSQL with Redis Using native wrappers and a Foreign Data Wrapper for two-way Redis integration http://www.pgcon.org/2013/schedule/events/574.en.html フロントエンドの Redis では高速にリクエストを処理しつつ、バックエンドの PostgreSQL ではデータウェアハウス的な処理を行うのが狙い。 トークでは redis_fdw redis_wrapper の2つの Redis 向け FDW が紹介されている。
シーケンスの代わりにuuidをIDとして使う
stop using numbers as IDs. just use UUIDs. seriously — Postgres: The Bits You Haven’t Found by pvh UUID の違い v1 Generate a UUID from a host ID, sequence number, and the current time. v3 Generate a UUID from the MD5 hash of a namespace UUID and a name. v4 Generate a random UUID v5 Generate a UUID from the SHA-1 hash of a namespace UUID and a name. この内、ID として利用できるのは v1 と v4 の2つ。v1 は最後 48 ビットがハード固有のノー
InstagramのIDシャーディングについて
約1年前の Instagram Engineering Blog で ID のシャーディングについて解説されていたのでメモ。 Sharding & IDs at Instagram http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram 背景 毎秒大量に行われる写真投稿やユーザーの行動をデータベースに保存するために、Instagram ではシャーディングを行なっている。 データベースにデータ格納するにあたり、シャードが別であっても、写真といったコンテンツごとにユニークなIDを振らないといけない。 Before writing data into this set of servers, we had to solve the issue of how to assign uniqu
RabbitMQ(2.8向け)のHAクラスタ構成
RabbitMQ Highly Available Queues and Clustering using Amazon EC2 という AWS 環境での RabbitMQ クラスタ構築に関する面白い記事を見かけた。 知識の再確認のため、以下をメモ。 RabbitMQ のクラスタの構築 HA:Active-Standby(Shared Nothing) HA:Active-Standby(Shared Storage) HA:Active-Active(Mirrored Queue) RabbitMQ のクラスタリングの特徴 Erlang/OTPの 分散フレームワークをベースにしている。 ノード間でCookie(/var/lib/rabbitmq/.erlang.cookie)を同じにする ノード名(デフォルトはホスト名)をクラスタ間で重複しないようにする キューのメタ情報とキューが管理さ
Redisのメモリ管理ポリシーについて
オンメモリ KVS の Redis では、使用メモリに上限を設定し、閾値を超えた場合のポリシー(maxmemory-policy)を複数の中から設定できるようになっている。 パラメータとポリシーを整理したのが以下 使用メモリの上限値 redis.conf の次のパラメータで設定する。 maxmemory maxmemory-policy メモリ使用量が閾値を超えている状況でキー追加する場合の振る舞いを定義する。以下の 6 つの maxmemory-policy から選択できる。 volatile-lru : remove the key with an expire set using an LRU algorithm allkeys-lru : remove any key accordingly to the LRU algorithm volatile-random : remove
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
