Kazuho@Cybozu Labs: アクセスログからアテンション（注目情報）をデータマイニングする手法について
多数のユーザーの行動記録からアテンション情報（注目されているデータが何か）をデータマイニングしたいというのは、大量のデータを扱っているウェブサイトにおいては自然と出てくる要求です。そこで、先月末にサービスを終了したサービス「パストラック」において使用していた、アクセスログから注目度（人気度）の高いウェブページや人名等のキーワードを抽出するためのアルゴリズムを紹介しておきたいと思います。 たとえばはてなブックマークのような、ユーザーの能動的な行為（「ブックマークする」という作業）から注目情報を抽出するのは決して難しいことではありません。それは、直近の一定期間内のブックマーク数＝注目度、という前提が上手に機能するからです。現に、はてなブックマークの人気エントリーは、最近24時間程度の期間内にブックマークしたユーザー数の多い URL を降順で並べているように見受けられます。 しかし、アクセスログ
Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法
監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
書評: 集合知プログラミング(Programming Collective Intelligence) | 秋元@サイボウズラボ・プログラマー・ブログ
献本いただいたもの。 翻訳が出ると聞いてからずっと気になっていた本なので、いただけたのはとてもラッキーだった。 集合知プログラミング 著者／訳者：Toby Segaran 出版社：オライリージャパン( 2008-07-25 ) 定価：￥ 3,570 原題(Building Smart Web 2.0 Application)にあるとおり、集合知プログラミングは、ウェブサイトの背後でいろいろと賢いことをするために使えるいろいろな技法を広く紹介した技術書だ。 大勢の過去の行動データから推薦を行なう 集団をグループに分ける 検索エンジンとランクづけ 最適解を低コストで見つける スパム判定 条件判定のルールを生成する 価格モデルを作っての価格予測 カーネルメソッドやサポートベクトルマシン 遺伝的プログラミング といったトピックが、Pythonのサンプルコードとあわせて解説されている。 内容は、読む
秋元@サイボウズラボ・プログラマー・ブログ: マイクロソフトのリアルタイム音声検閲特許が成立
ars technicaによると、2004年に申請されていたマイクロソフトの特許がアメリカで成立したという。 その内容はというと、リアルタイムで音声の中から特定の音を見つけ出し、そこを無音化したり、別の音を被せるという技術。つまり「ピー」を自動で入れるソフトウェアである。 # 特定の音を見つける、という技術は、エシュロンとかグレートファイアウォールでやってそうな気もする。まあ当然特許とかには出てこない話だけど。 リアルタイム、ということなので、Fワード等の単語が話し終えられる前に、「ピー」を被せられるということだけど、このへんは、それまで出てきた単語の情報などもあわせて、その話し手が問題のある単語を使いそうかどうか、という確率も加味して閾値を動的に変化させる、というようなことが書いてある。 ars technicaによれば、アメリカの場合、FCC(連邦通信委員会)の規定で、毎日朝6時から夜
ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ
実際に動的なウェブサイトを作ってしまう前に、紙上でデザインや部品の配置、画面遷移などを確認するペーパープロトタイピングという設計技法があります。書籍もありますね。 ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする そのペーパープロトタイピングの事例を集めたページというのがありました。たとえば次のこれは、2000年5月31日にスケッチされたtwitterのプロトタイプです。当時はstat.usという仮名で、これによるとtwitterはLiveJounal(ブログサービス)とAIM(インスタントメッセンジャー)から最初の着想を得てから実装まで5年以上の間があったことになりますね。 FlickrのPlacesページやVimeoなどのペーパープロトタイプの写真も紹介されています。 こちらは韓国のポータルサイトDaumのAjaxウェブメール開発時に行なわれた、ペーパープロト
fav.or.it創業者による「もしtwitterを作り直すなら」 | 秋元@サイボウズラボ・プログラマー・ブログ
コメントつきソーシャルRSSリーダーfav.or.itの創業者Nick Halsteadさんが、自分がtwitterのスケーラビリティを直すならこうする、というエントリを書いている。 twitterは今日も「データベースがロストした」とかで落ちていて、不安定さに対する不満の声をそれこそ毎日のように見かけるようになっている。 技術的な興味から、訳しながら読んでみたのだけれど、ほんとうにこれですべてた解決するのか、については僕はわかっていない。わからないものを出すのもどうかと思い数日放置してたんだけど、もっと手の長い人に読んでもらうのも意味はあるかなと思い直し、以下に公開する。 「fav.or.itはこれよりもっと複雑だ」と言ってるけれどfav.or.itはtwitterほどユーザいないし(笑)。 前段では有名ブロガーのRobert Scobleさんが、技術的な理解無しにtwitterをMS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
