2006-11-02 Thu

渋谷 一蘭 ラーメン

町田に一蘭ができる、と研究室でニュースになっていたので、
渋谷の一蘭に行ってみた。これで2回目。

画像画像

おいしいなぁ、と思った。
食べてる間、ずっと唐辛子ダレのためか舌がビリビリ。
次回から唐辛子ダレは無しで良いかも。

ラーメンを食べていたら終盤に頭が痛くなったので、
もしかしたら一蘭のラーメンは体に合わないのかもなぁ。
スープがかなり残ってしまった。残念。

細麺の豚骨ラーメンを食べると、高確率で頭痛が起きるので
やっぱり博多ラーメン特有の材料に何か問題があるのかも。
まぁ、町田店には一回行っておこうと思う。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」に行ってきた

DE研チュートリアル「Web2.0時代のデータ工学」に行ってきました。
以下の4つのプレゼンはメモを取りました。

[2006-11-02-2] gooのブログ検索テクノロジー
[2006-11-02-3] Webの進化 - Web2.0とセマンティック
[2006-11-02-5] 大規模ウェブサイトのスケールアウトモデル
[2006-11-02-7] 情報流通とマネタイズ

Web2.0の特質と進化のロードマップ、というプレゼンは
非常に丁寧な資料があって、ほぼその通りに進みました。
なのでメモは取りませんでした。

YahooのJulian Brodyさんの発表は時間が長いし展開が早かったけど、
個人的に知らないことだらけで一番面白かったと思いました。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」 情報流通とマネタイズ

最後の発表は、情報流通とマネタイズというプレゼン。
Yahoo Japan!広告本部のJulian Brodyさんの流暢な日本語に驚いた。
最後の最後まで会場中から笑いを取りまくっていた。

以下メモ、といきたいのですが、まとまってないので後で書く。

関連エントリ

[2006-11-02-8] DE研チュートリアル「Web2.0時代のデータ工学」に行ってきた
[-] 1
投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

svk

のコマンドメモ [Programming]:
svkのコマンドをすぐ忘れてしまう。
一番忘れるのが「svk cp」で、しばしば「svk co」と入力してしまう。
なので、メモしておくことにした。




・SVNリポジトリからsvkのローカルミラーを作成
% svk mirror svn+ssh://SVNリポジトリのあるサーバ/path/to/svn_repos/ProjectName //mirror/ProjectName
% svk sync //mirror/ProjecName

初回のsyncにものすごく時間がかかる。

・svkのローカルミラーから、ローカルブランチを作成
% svk mkdir //local
% svk cp //mirror/ProjectName //local/ProjectName


この$HOME/svk/ProjectNameは、普通のSVNリポジトリとしても使える。
svkを活用する開発では、このローカルブランチを編集する。

cpするディレクトリは以下のようにもできる。

% svk cp //mirror/ProjectName/hoge/fuga //local/piyo


・ローカルブランチをチェックアウトする
% cd $HOME/svk
% svk co //local/ProjectName
% svk switch //local/ProjectName


% svk help commandsすると書いてある。
switch - Switch to another branch and keep local changes


・変更をコミットしたり、ファイルを追加したりする
% svk add hogefuga
したりとか、
% svk commit hogefuga


・ローカルブランチにおける変更をsvkのローカルミラーに反映する
% svk sync //mirror/ProjectName
% svk smerge -C //local/ProjectName //mirror/ProjectName
// コンフリクトが無ければ、-Cをとる。
% svk smerge //local/ProjectName //mirror/ProjectName


-lでローカルのコミットログをまとめて送信できる。
-Iでsvkでのコミットをsvnにそのまま反映できる。
インポートしたあと以外は-Iをつけるとコミットの粒度が小さくなって良さげ。

・svkのローカルミラーに反映された変更を、SVNのリポジトリに反映する
% svk sync //mirror/ProjectName





これ位書いておけば忘れないでしょう。忘れませんように。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」 大規模ウェブサイトのスケールアウトモデル

午後の最初の発表は、大規模ウェブサイトのスケールアウトモデルという発表。
mixiのバタラ・ケスマさんのプレゼン。

以下メモ。




・ステーラビリティはスケールアップとスケールアウト
 - スケールアップ
   - 既存のサーバの機能を強化し、パフォーマンス向上
 - スケールアウト
   - サーバを増やすことでシステム全体のパフォーマンスを向上

・なぜスケールアウト
 - 構築のコスト
   - 32GB*1より4GB*8
   - 32CPU*1より2CPU*16
 - 外部依存性の排除
   - 自社で1024CPUのマシンは作れない
 - スケールアップには限度があるので、いつかスケールアウト

・マシンを増やすだけではスケールできない
 - 増やすだけでスケールすることが目標
   - 解決すべき問題が多い

・モデルケース
 - ウェブサーバ
   - コンテンツの種類
     - 静的コンテンツ
- キャッシュヒット率高
- コンテンツの更新頻度低
- 1、ロードバランサー
- ハードでもソフトでもいい
- 2、キャッシュ
- Squidやらいろいろ
- 3、Webサーバ
- 選択肢たくさん
- キャッシュサーバ増加に伴なう問題点
- キャッシュサーバの数と比例してオリジナルサーバの負荷が増える。
- 同一階層にキャッシュサーバが増えると大変
- オリジナルからキャッシュへの転送が増えるから
- キャッシュ台数が増えるとヒット率が低くなる
- キャッシュサーバ増加問題の解決方法
- キャッシュサーバを階層化する
- 大量の同一階層のキャッシュサーバに、
上位階層のキャッシュサーバが応答する。
そうすることでオリジナルのサーバの負荷を下げる。
- キャッシュを階層化しても問題がある。
- キャッシュサーバにランダムアクセスするのが無駄
- キャッシュサーバにランダムアクセス問題の解決法
- クラスターキャッシュ
- ロードバランサー上で、転送するキャッシュサーバをルールで決める
- 同一の問い合わせを転送するキャッシュサーバが一意に決まる
- 無駄が少ない
- キャッシュ間でも1ファイルの転送が1回になる
- 適用対象
- ファイルの数が多い
- ファイルの数が緩やかに増加する
     - 動的コンテンツ
- キャッシュのヒット率が悪い
- コンテンツの更新頻度が高い
- 動的コンテンツモデル
- ロードバランサーから直サーバに転送
- 動的コンテンツの問題
- 遅い接続
- 転送が終わらないからコネクションの余裕が無くなる
- 例、アップロード、動画配信
- 遅い接続の解決方法
- 機能によってウェブサーバをクラスタ化する
- ロードバランサから転送ルールで転送
- 機能によってドメインを分けて、ロードバランサも分ける
- 部品のキャッシュについて
- コンテンツ全体をキャッシュすると効率が悪い
- コンテンツを構成する部品をキャッシュ
- 部品のキャッシュには共有メモリが必要
- ノードワイド
- 同一マシン上の異なるプロセスがメモリを共有する
- PerlだとIPC::Shareable、mmap、SHM
- システムワイド
- ネットワーク経由
- memcachedやMySQL
- ハッシュマッピングでスケールアウト
- memcachedは標準でハッシュマッピングできる
- 比較
スピードはノードワイド、スケーラビリティはシステムワイドが有利

 - データベースサーバ
   - レプリケーション
     - マスターのデータをスレーブに非同期で複製、更新
   - レプリケーションのモデル
     参照はスレーブ、更新はマスターに行う
   - レプリケーションの問題
     - 更新が多いサイトには向かない
- スレーブを増やしても更新時間を減らせない
- データ遅延が起こる
   - レプリケーション問題の解決法
     - データベースを分割
- データの種類で分割
- 静的なパーティションマップ
- あれはここに入ってるよー
- パーティションマップのサイズが小さい
- DB_MAIL => 'db01'; DB_BBS => 'db02';
- パーティショニングのキーで分割
- 動的なパーティションマップ
- パーティショニングキーを使う
- 何で分けるかを決めるもの
- プライマリキー
- インデックス
- HASH(ID)
- パーティショニングキー
- 細かいと、負荷がバランスよく分散される
- ただし、パーティションマップは大きくなる
- どんな感じにするか
- たとえばユーザをIDで分割して、ノードに割り当てる
- アルゴリズムベースで分割
- パーティションマップが不要
- 計算式
- Simple Hashing
- Simple Hashingの問題
- 新しいノードを追加したら、ほとんどのノードIDがずれる。
- ずれを最低限にするため、ノード数を2倍に増やす必要がある
- Simple Hashの問題点を解決
- Linear Hashing
- Consistent Hashing
- マネージャベースで分割
- 動的なパーティションマップの更新が必要なとき
- マネージャDB
- テーブルにロックするためのフィールドを入れておいて
更新やメンテナンス時に、フラグを立てておく。
更新時にデータの整合性が取れない、ということが無くなる
- ハイブリッドな手法
- マネージャDBをさらにハッシュマッピングする
- アルゴルリズムとマネージャの比較
- 管理 : マネージャが楽
- 接続 : アルゴリズムは直接ノードに接続できる
マネージャはノードに接続する前マネージャDBに接続
- 柔軟性 : マネージャのほうが柔軟性が高い
 - まとめ
   - システムの特徴にあったソリューションを選ぼう

 -QA
 Q1、成長し続けるサービスのシステムをメンテするのが
 A1、ほとんどのサービスは同じ解決法を使えばよいはず
     ひとつ作れば応用が効くのではないか。

 Q2-1、mixiにおける認証の難しさについて
 A2-1、mixiでは認証は複雑になっていない。

 Q2-2、画像とサービス全体のログインは認証が違いますよね
 A2-2、ごく普通のセッション管理をしてます。

 Q3、ノード間の分散トランザクションについて
 A3、不明
 # 目の前の方の声がでかくて聞こえませんでした。

 Q4-1、技術の発想はどこから出てきたのか
 A4-1、mixiには1日自由に使える時間があるのです。
その時間を使って、さまざまな技術は実装しました。

 Q4-2、バタラさん自身はどこをつくったの?外注はしたの?
 A4-2、自社で開発しました。

 Q5、静的コンテンツのファイルの数が急激に増加する場合は?
 A5、自社開発のイメージサーバを使っている。
     たとえば、画像データの場合にはバイナリデータはどこかに保存し、
     イメージサーバにデータの保存場所を示すメタデータを保存する。
     画像が必要なとき、問い合わせを始めにイメージサーバにして、
     イメージサーバのメタデータをもとにバイナリデータを取得する。




基本的な構成はYAPCと同じような感じ。
ほとんど資料どおりの進行でしたが、
ところどころのコメントが役立ちそうです。

メモというか資料の丸写しっぽくなったなぁ。

技術的な話は大好きなので楽しめました。
ありがとうございました。

関連エントリ

[2006-11-02-8] DE研チュートリアル「Web2.0時代のデータ工学」に行ってきた
[-] 1
投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

ジャーマンハンバーグ

東大駒場キャンパス内の生協食堂でジャーマンハンバーグを食べた。

ハンバーグの真ん中に半分に切ったゆで卵が入っていて驚いたら、
写真を撮る前にハンバーグを崩してしまった。不覚。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」 Webの進化 - Web2.0とセマンティックWeb

DE研チュートリアル「Web2.0時代のデータ工学」の午後2本目は、Webの進化 : Web2.0とセマンティックWebという発表。
タイトルからは内容が読めないなぁ、と思ってた。

以下メモ。




・セマンティックWebのお話でした。

・Web上での生活が日常の生活と一体となった
 - 2つの生活を合わせて初めて意味を持つのではないか

・大規模な情報を扱うことと情報共有を実現することは
  一見すると相反しているが、近年はAPIの提供が盛んになり
  大規模な情報が共有されやすくなってきた。
  今後は情報共有を実現する側面から、大規模データに向けて
  近づくことを考えたい

・前半はというか40分位セマンティックWebのお話。
  配布資料は盛り沢山なので最後まで終わるかどうか不安になってきた。

・Polyphonet
 - Webから人間関係を抽出するシステム
 - 主要アルゴリズム
   - 人間関係を調べたいメンバーのリストは与える
     - リストには名前と所属を記述
   - Googleを使って人名の共起関係の強さを計測する
     - 閾値付きOverlap係数を使う
・閾値kは事前に与える
・|*|はGoogleを使って算出
・閾値付きOverlap係数(= Simpson係数) : R(X,Y)を算出する
  my $R(X,Y);
  if ((|X| > k) && (|Y| > k)) {
    $R(X,Y) = |X∩Y| / min(|X|, |Y|);
  } else {
    $R(X,Y) = 0;
  }

   - Googleの検索結果を元に得たWebページから
     ページの特徴量を抽出し関係を把握する。
   - 結果を重み付きグラフとして出力する。
     - エッジにはノード間の関係を付与する
     - 距離が近いほど共起関係が強い
   - 実験の評価はアンケートで行った
     - 適合率9割程度、再現率は2〜5割

・QA
Q1、folk-ontolgiesは使えるのか
A1、完全な自動化はできないが互いの弱点を補完できるのではないか。

Q2、ontolgiesが登録されている空間は、ユーザが解析されるつもりで登録していないのではないか。権利関係についてのご意見を。
A2、Aggregateされたデータは単純に公開・非公開というわけではなく、
    現状では波風が立たないように気をつけて研究している。
    この世は使える技術は使われてしまうもの。誰にも止められない。
    技術の波にさらされたくないかな、さらされない世界に逃げる人は増える。
    プライバシーについて考える人も増えるはずである。
    たとえば、匿名ブログは本名非公開だけど、著者にとってはアイデンティティそのもの。
    ブログが炎上してしまったときの心情は大変なもの。
    技術の進歩に伴ない、プライバシーについて再考されるようになるだろう。




似たトピックの発表に関する記事として、先端研ブログ:リアルとWebのネットワーク分析が挙げられる。
さすが、たつをさん。Simpson係数(シンプソン係数)の簡単な例もありました。

個人的に一番最後の質疑応答が興味深かったです。

関連エントリ

[2006-11-02-8] DE研チュートリアル「Web2.0時代のデータ工学」に行ってきた
[-] 1
投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」 gooのブログ検索テクノロジー

DE研チュートリアル「Web2.0時代のデータ工学」の午前一つ目は、
gooのブログ検索テクノロジーという発表。
個人的に大変興味深いです。

以下メモ。




Web2.0
 - Ajaxな立地インターフェイス
 - 一般人の知識の集約(CGM
 - ロングテールに対応(e.g. adsense
Web2.0と同時に、各社が独自検索エンジンを持つ時代。

検索エンジンのクエリがロングテールであることへの解釈。
 - 利用者が幅広い→幅広くても上手く探してもらえるように

検索エンジン技術は推移している
 - 検索インデックス量と検索速度の時代
 - 検索精度の時代(PageRankなど
 - ユーザの目的に応じて最適な結果を返す競争
→特徴のある検索サービスが競争力を生む

gooは日常生活に役立つ検索サービスを目指す。
消費行動モデル「AISCEASアイシーズ」の各フェーズに対応。
注意、興味、検索、比較、検討、購買、情報共有

情報共有→ブログホスティング
検索→各種検索エンジン
比較・検討→評判検索、地域情報検索
購買(行動)→ショッピング用のコンテンツ
      地図や写真の提供

# 個人的には、比較・検討、行動がおもしろそう

・gooのトップページの右上にgooラボへのリンクがあるよ。

・goo地図
 - Ajax
 - 内部でマッシュアップ
 - マンパワーで写真収集

・ローカルサーチ
 - ローカルサーチは駅などを中心とした行動圏のおすすめ情報を網羅
 - ブログのマッピング
   - gooが特派員を雇用してgooが取り込みやすい形式でブログを書いてもらう
     - 情報を抽出し、緯度経度を付与し、マッピング
     - 登録画面では、地域情報検索とカテゴリ+店舗名+住所+キーワードを登録

・ローカルトピック検索
 - 観光スポットに対するブログ上の情報をブロガーの信頼度で順位付け
   - ブログからローカルトピックを抽出し、EigenRumorでランキング
     - アイゲンルーモア
     # 初めて発音が分かった

・goo地図のAPIを提供してますよー

・gooブログ
 - UU数:1302万人 / 月
 - PV数:2億7千万PV / 月
 - UU/PV数は12ヶ月で1.4倍
 - ブログ開設数:62万
   - 20,30代で65%を占め、20代女性が多い。
   - 男女比は全体にすると半々くらい

・ブログ検索
 - 即時性が武器
 - 情報の性質が整理されていない
   - 個人的な発言が多い
     - 評判や感想を期待できる

定番検索はWeb検索、トレンドはブログ検索か

ブログ記事は個人と紐付けられた構造化済みの時系列情報。
解析対象データとしておもしろい。

・gooブログのクロールの注意点
 - 如何に負荷を欠けないようにクロールスピードを調整するか
   - ひとつのドメインで複数のユーザを扱うサイトの収集
     - はてな、goo、アメーバ、So-net、Yahoo!など
   →収集が間に合わない可能性があるので、
     複数サーバの存在を期待して短い時間でクロールしている。
     # なるほど
   - バーチャルホストで各ユーザを扱うサイトの収集
     - ココログ、excite、Seesaa、Jugemなど
   →サーバがパンクするかもしれないので、
     各ドメインを同一のドメインとして束ねてコントロール
     # そうですね
そのために↓
 - 複数のIPアドレスをまとめて、同一ドメインとしてコントロール
 - また、robots.txtやmetaタグの処理も当然サボらない

・ブログの本文抽出
 - ブログの固定リンクページも収集して本文を抽出
 - 変更が無いヘッダやメニューは検索対象にしたくない
 - Descriptionに本文の一部しか登録されていなくても大丈夫
 - 主要なブログサイトはルールベース
 - ルールが使えない場合には自動化して主要な部分をとる
   # もうちょっと具体的に聞きたいなぁ

・トレンドランキング
 - ブロガーはある程度偏った話題や
   テクノロジーに関する話題を多くとりあげる傾向があるようだ。

・BLOGRANGER1.0
 - 現在、本チャンサイトへの移行中。近くgoo検索で公開。
 - outlinkを束ねると、引用元を見つけやすくなる
 - 固有表現を抽出し、属性分けし、リストを提示
   - ユーザの興味を補助してる
 - 注目語は、属性分けして並べると、それだけでも良い感じ

・EigenRumor(アイゲンルーモア)
 - ブログは新しい記事が多くてPageRankが反映されにくい
 - ブログはひとつの書き手が沢山の記事を書いている
   - ブロガーの過去の記事を使って上手にランキングしたい
   - 過去に良質なリンクを張られた記事を持つブロガーは
     良質な記事を書くというポリシー

・BLOGRANGER2.0
 - 自分専用のブログ検索エンジン
 - ブログパーツを提供
 - 検索結果の比較
   # ブロガーに言及されてるテレビ番組を
   # テレビ番組表のような形で見せている。
   # 個人的に好きだなぁと思った。
 - モバイル対応
   - 検索結果に対するQRコードを生成する

・gooのAPI戦略
 - インデックスのみではなくマイニングも提供
 - 通常のAPIだけでなく、簡単に使えるブログパーツを提供

Q1、EigenRumorの利点、問題点
EigenRumorは人をランキングできる。
ブロガーのラングはその一例。
問題点は計算量の問題点が挙げられる。
ブログ検索も膨大なマトリクスを処理する必要がある。
計算結果の末端のユーザを枝狩りするのが課題のひとつだった。




技術担当の方のプレゼンテーションではないということで、
細かい質問ができない雰囲気でしたが、
興味があったブログ検索のクロールについて言及があったので
収穫があったな、と思います。

誰かクローラーカンファレンスとか開いてくれないかなぁ。

あと検索エンジンがブログパーツを積極的に提供する姿勢は、
個人的にかなり好きです。
APIなんて文系だった主婦にとってはちんぷんかんぷんですよね。

おもしろかったです。ありがとうございました。

関連エントリ

[2006-11-02-8] DE研チュートリアル「Web2.0時代のデータ工学」に行ってきた
[-] 1
投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

DE研チュートリアル「Web2.0時代のデータ工学」へ行く

電子情報通信学会のチュートリアルとして「Web2.0時代のデータ工学」が開催される。
なので、今日は夕方まで外出。

場所は東京大学の駒場キャンパス。
東北沢から徒歩10分くらいかな。

事前申込人数が定員に満たない場合は当日の申込みも受け付けます


とのことなので、参加したい人は行ってみるといいかも。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

関連エントリ

[2006-06-14-1] ベルン BERNE 夏のミルフィーユ
[-] 1