Redis の SortedSets 同点問題について - blog.nekokak.org
WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。 WEB+DB PRESS Vol.73posted with amazlet at 13.03.05設樂 洋爾 白土 慧 奥野 幹也 佐藤 鉄平 後藤 秀宣 mala 中島 聡 堤 智代 森田 創 A-Listers はまちや2 大和田 純 松田 明 後藤 大輔 ひろせ まさあき 小林 篤 近藤 宇智朗 まかまか般若波羅蜜 Mr. O 技術評論社 売り上げランキング: 335 Amazon.co.jpで詳細を見る 買ってください。 このRedis特集の第五章では、Redisを使ったリアルタイムランキングについて取り上げたのですが、 記事中にある同点問題について、執筆時から状況が変わりましたのでupdateします。 記事中では、RedisのSortedSetsはスキップリストというアルゴリズムを使っている特性上、 同じス
SELECT FOR UPDATEする上での注意点 - blog.nekokak.org
MySQLで行ロックかけてトランザクションを効かせたい場合、SELECT FOR UPDATEを使うわけですが、 以下のようなクエリを発行しちゃうと行ロックではなくテーブルロック風味に扱われるので注意。 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from user order by id DESC limit 1 for update; +----+---------+ | id | name | +----+---------+ | 4 | xaicron | +----+---------+ 1 row in set (0.00 sec)このクエリを実行中に別のセッションから同じことを実行するとロック待ち状態になり 最悪デッドロックで死亡します。 ERROR 1205 (HY000): Lock
簡易2WaySQL - blog.nekokak.org
2WaySQLというものがあるわけです。 2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation を参考にしてもらうとして、 超絶簡単に説明すると、実行可能なSQLを書いておいて（where句の値もデフォルト値を書いておくので実行可能となる） プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。 どんなSQLかというと SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)こういう感じ。 普通に実行可能ですよね。 これを、 my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1
Kyoto.pm#01のQudoの発表についてのレス - blog.nekokak.org
@shiba_yu36さんがQudoの発表をするというのがKyoto.pmに行く強いきっかけになったので、 一番まえの席に陣取って発表を見ていました。 @Yappoさんのように発表者が発表している最中にtwitterという公開の場でlive disをするのはためらわれたので、 今あらためて@shiba_yu36さんの発表内容を振り返りつつ突っ込んでみたいと思う。 disじゃないよ。 @shiba_yu36さんの発表資料 http://shibayu36.hatenablog.com/entry/2012/03/18/230525 拡張性について Job Queueを使う上でTheSchwartzではなくQudoを使った利用に、 「TheSchwartzはオーバースペック」 「たくさんカスタマイズ詩たいわけではない」 ⇩ 「Qudoがちょうどよさそう」 とあったのですが、Qudoは拡張性が高
Clutchの仕様と構想と（その２） - blog.nekokak.org
投げっぱなしrequest まぁ、Gearmandで言うところのdispatch_backgroundである。 clientはworkerにリクエストを投げる、 workerはリクエストを受け付けた事だけをclientに通知し、client - workerの接続を終了する。 workerはその後clientからのリクエストを処理する。 こうすることでclientはworkerの処理結果は受け取れないが、即時に処理を終了させることができる。 usecaseとしては、ページングの際の先読みキャッシュを作ったりとか。 multi request 複数のworkerに対してまとめてリクエストを投げたいケースもある。 一つの方法としてはclientが対象となるworkerにまとめてリクエストを投げる方法。 各workerへの接続をそれぞれ持ち、selectかけつつぐるぐるループさせて、read
2011の振り返り - blog.nekokak.org
ちょっと落ち着いたので振り返りなどしてみようかとおもう。 1月 転職を決意し動き出す Teng作ってたみたい Jonkも触ってた 2月 退職の準備とおもいきや１０日で１サイトつくるとかやってた SQL::Objectとかつくってた ３月 転職 地震 ４月 HandlerSocketに興味を持ってたみたい CPANモジュールガイド献本もらったり tmux入門してすぐにscreen回帰した MySQueueとかネタでつくったみたいだ ５月 Yokohama.pmでHandlerSocketの発表とか ６月 Redisの検証をしてた Hokkaido.pmに参加する準備してた DBIx::Handlerを作ったりしてた ７月 Hokkaido.pmに参加。飯が美味かったなり ８月 Web+DBにJobQueueについて寄稿 ９月 Test::Function後のTest::Attribute::
quick hackの必要性 - blog.nekokak.org
ふと思ったのでメモっておく位の感じ。 仕事ではquick hackって重要だなぁと。 業務で本当に必要と思うような仕組みがあったとして、それをすぐに導入できるかは大人の事情とかがあり なかなか難しかったりするのが普通じゃないでしょうか？ 必要な仕組みだから周りだったり上司だったりを説き伏せて正しい（？）手段で導入するのももちろん正道だとおもいますが、 それがなかなかムズカシイのも世の常かなぁと。 自分は必要だとおもっても、周りにその問題意識があるかどうかは別なので。 好き勝手やっていいよって会社であれば別なんでしょうけど、そういう会社って結構珍しいんじゃないかなぁ。 もちろん相談出来る相手がいて、色々と相談や議論をし、協力者を見つけるのもいいし、そういう相手がいるんであればやるべきだとは思います。 そうすれば自分が思っていなかったような問題点なんかが出てきて考えの幅が広がるかもしれない。
Hokkaido.pm #06 - blog.nekokak.org
自腹で参加してきました。北海道の人から事前に、「コケるなよ*2」と言われ天気予報みたら普通に最高気温が氷点下だったのでかなりビビってたんですが、 お陰様でコケることもなく、寒さにもなんとか耐えることができました。 帯広はもっと寒いとか。 今回は最近自分が作ったClutchというdistributed job queueを開発に至る経緯/設計方法/仕組/簡単なデモで紹介させて頂きました。 コードはまだどこにも公開してないのですが、書きなぐったままなので、もうちっと整えたらだそうかなと思っています。 Job QueueだったりMessage Queueだったりを使ってる人自体あんまりいない風味だったので どこまで響いたかわからないのですが＆サービスが大きくないから使うまでも無いんですという話もお聞きしましたが、 そういうアーキテクチャがあるんだとココロの片隅にでもあると今は必要無くても何かあっ
DBI#cloneの取り扱い注意 - blog.nekokak.org
前の記事で、 clone使ったら接続きれてもて再接続できるよーといいましたが、 これは DBIを生で使う人が reconnectを実現するための機能ではありません reconnectするためだけにcloneつかうとかバカなことはやめましょう。 ORMを使わないケースで、処理中で接続が切れる可能性があり、自動で再接続をしたい場合はDBIx::Handlerを使いましょう。 DBIx::Handlerをつかわずに接続切れたらcloneとかいうコード書くと トランザクションに不整合が発生する可能性が生まれます。 なお、DBIx::Connectorではそのあたりの処理が中途半端でdatabase側から接続が切られた場合や ネットワーク的な問題で接続が切れた場合はよしなにやってくれないので やっぱりDBIx::Handlerをつかいましょう。 # DBIx::Connectorでは$dbh->FE
DBI#cloneというメソッド - blog.nekokak.org
http://search.cpan.org/dist/DBI/DBI.pm#clone DBIにcloneメソッドがあることを@nihenさんがみつけました。 #いやーDBIのドキュメントは良く読むと便利メソッドが一杯ありますね TengとかSkinnyではconnect_infoを受け取るだけでなく、 $dbhを受け取って利用する仕組みも提供しているのですが、 そこで一番問題になっていたのはdbへの接続がブチギレた場合のreconnectの問題でした。 connect_infoがある場合は接続情報を自分で持っており、簡単に再接続できるんですが $dbhしかない場合はいままでできないとおもっていました。 DBI的にも接続時につかったpasswordを取るインタフェースがなかった。 なので$dbhを渡された場合は自動reconnectは行わずにエラーで死亡にするようになってたんですが、 D
ORMについて - blog.nekokak.org
最近方々でORM不要論が巻き起こってたりするとかしないとか。 まぁ自分も結構煽ってた節があるのでここでちょっくら おそらく日本のPerl界隈のORMで一番使われているであろう(自分の適当調べ)、 DBIx::SkinnyとTengの作者の本気の意見 を、ここに吐露してみようと思う。 結論から言うと、一般的なWebアプリだったりそれに付随するアプリ、 DB周りを操作するアプリに関しては普通にORM使えばいいと思います。 以上 以下は色々思うことなどをつらつらと。 正直つかいたければDBICやDODやその他のORMも使い倒したらいいと思います。 DBICにはDBICの良さがあり、typesterさんが今も愛用するにはそれなりに訳があるし DODはL社でよく使ってるらしいし、DODの透過キャッシュがやっぱり便利だという声も聞きます。 要件を満たせばどんなORMだってつかえばいいんですよ。 もちろ
Redisをつかったjob queue - blog.nekokak.org
最近Redisに興味があったんで 色々な使い方を検討してるんですが、その中でRedisをつかったJob Queueを思いついたので実装してみました。 ちなみにRedisをつかったJob Queueは既出で、githubなんかで使われている resqueというのがあります。 まぁ通常のJob Queueだったら正直別にRedisつかわなくていいのでちょっと違う感じで実装してみました。 # 個人的には普通のQueueだったらQ4MとかQudoとかTheSchwartzでいいとおもう。 # こんなところで無駄にRedisとか使うメリットないわ。 通常JobQueueだと1個ずつjobをとりだして(dequeue)処理を行うと思います。 ただ、ケースによってはある一定の個数のjobをまとめてdequeueして処理を行いたい時があります。 私は普段業務では、Q4Mを多用しているんですがQ4Mにはそう
DBIx::Handler#queryというjust idea - blog.nekokak.org
ほんとjust ideaですが DBIx::Handlerにquery methodを足して見ました。 my $handler = DBIx::Handler->new(@connect_info); my $sth = $handler->query('select * from query_test where name = :name', +{name => 'nekokak'}); m $row = $sth->fetchrow_hashref; # +{name => 'nekokak'}; bindで渡す引数の形に応じてnamed_placeholderしてくてたり、 prepare / executeまでやってsthをかえすだけなんですが。 また { package Mock::Result; sub new { my ($class, $handler, $sth) =
Test::Function - blog.nekokak.org
名前は適当なんだけどねっ local $Test::Builder::Level = $Test::Builder::Level + 1 するのに飽きたので Test::Level 書いた @xaicronとこの件についていつもイケテナイよなぁってはなしてたら @xaicron便利系を実際に実装してるのみてついカッとなって書いてみた。 https://github.com/nekokak/p5-test-function use strict; use warnings; use Test::More; use Test::Function; sub test_foo : test_foo { ok 0; } sub test_nest2 : test_nest2 { ok 0; } sub test_nest1 : test_nest1 { ok 0; test_nest2(); } t
WEB+DB PRESS Vol.64に寄稿しました - blog.nekokak.org
WEB+DB PRESS Vol.64posted with amazlet at 11.08.23柏木 泰幸 松野 紘明 林 聖高 杉 義宏 飯塚 直 高橋 征義 徳永 拓之 Tehu（張 惺） 中島 聡 おにたま 技術評論社 売り上げランキング: 204 Amazon.co.jp で詳細を見る 連載が続いているPerlHackersHubに今回JobQueueの記事を寄稿しました。 自分が使用している、自分が作った、使ったことのある Q4M, TheSchwartz, Qudoをザックリ紹介したのと、JobQueueを利用する上で気をつける事などをまとめてみました。 原稿書いててTheSchwartzはなんどもtypoをして残念な子だなぁと思ったり、 Qudoをもっとチューニングしてqpsあげたいなぁともおもったり いやいやJonkをこの夏リリースするんだったと思いだしたり、 Q4Mは
実行時に使用したメモリを取得する幾つかの方法 - blog.nekokak.org
あんまこういうの詳しくないので、詳しい人に教えてもらいたいのですが、 Perlのプログラムでどれだけメモリを消費したか確認するのに幾つか方法があると思います。 今回はwebアプリで１リクエスト毎に消費したメモリを取得したい感じ。 自分が知ってる方法は １：Plack::Middleware::Debug::Memoryでやってるようにpsを叩いてメモリを取る my $out = `ps -o rss= -p $$`; $out =~ s/^\s*|\s*$//gs;こういうやつ。 ２：Devel::Mallinfoを使う Devel::Mallinfoを使えばmallinfoが取得できるので、mallocされたサイズを取得できるので 開始と終了でmallinfoをとって差分を出せばプロセス中にどれくらいメモリを消費したかが分かる。 #! /usr/bin/perl use strict;
OrePANがcoolすぎる - blog.nekokak.org
みなさんCPANモジュールの管理どうしてますか？ rpm? deb?いやーメンドクサイですね。 メンドクサすぎて日がくれます。 それにそんな一元管理の方法したらコンポーネントが複数ある場合、 簡単にmoduleのバージョンがupでいないじゃないですか。 so badですね。 いまだとperlbrewとextlibでコンポーネント毎にcpanモジュールを管理することが 大分と楽にはなりましたが、OSの差はどう仕様も無い！ 実際にサービスに撒くmoduleに関してはサービスのosで作ったperlbrew+extlibで管理していいとおもいますが、 localの開発環境が、MacOSとかだとすると激しくメンドクサイですね！ さらにextlibとかに入れてるバージョンと全く同じバージョンのモジュールを 手元のmacに入れるとか実は結構むずかしいんですよね。 Makefile.PLでバージョンを指定
DBIx::Handler的なものをでっちあげた件 - blog.nekokak.org
最近はORMを一切使わず生なDBIでもりもりコードかいてます。 ORMを使うと隣の人に刺されるのでェ で、です。生のDBIを使うとforkする処理を書く時に面倒だったりします。 現在のところDBIx::Connectorとかつかってて基本問題ないんですが、 どうしてもこのDBIx::Connectorのインタフェースが気に入らなくてイライラしてました。 隣の人はそうでもないみたいですが で、です。ついカッとなってDBIx::Handlerというのを書きました。 実はこいつは今年の初め頃に一度軽く書いたんですが、その時はDBIx::Connectorよりも低機能だし おれおれコネクター書くのはよくないよなーとおもって自重してたんです。 でもついカッとなったのでしかたないです。 個人的なDBIx::Connectorの嫌な部分を列挙すると、 - トランザクションのかけ方がcodeblockでし
Redisのめものもめ - blog.nekokak.org
めものもめなので適当です。 replicationと耐障害性について 例えば 192.168.1.10:6379 で起動しているredisがあるとする。これをmasterとする。 別サーバでreplicationを受けるサーバを容易 192.168.1.11:6379 で起動したとする。これをslaveとする。 redis-cliコマンドでslaveのredisに接続し。 redis> slaveof 192.168.1.10 6379と実行するとon the flyでslaveになることが出来る。 データ量によりどの程度レプリケーションにラグができるかは未検証 次にmasterが死亡したとする。ぷぎゃー。 取り急ぎアプリケーションの参照先をslaveに変更し、 redis-cliでslaveに接続 redis> slaveof no oneと実行することでreplicationをon
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Perse::DaemontoolsStatus - blog.nekokak.org