昨日第16回InfoTalkに参加してHadoopの話、関数型言語の話を聞いてきました。 その中でHadoopのボトルネックとチューニングについて聞いてきたのでメモしておきます。

Hadoopのチューニング

いらないし、ほとんどできない（パラメーターがない）

と、いうわけでメモ。

PostgreSQL9.0？

8.5 = 9.0 あと2～3ヶ月でリリーススケジュールが見えてくる・・・と思うとのこと。

新機能予定

• 組み込みReplication
• Join removeal
• EXCLUDE制約
• EXPLAIN BUFFERS

PostgreSQLのReplication

2つの技術の合せ技

逆ジオコーディング？

緯度経度→住所の変換 元データ

1. 市区町村判定

• 国土数値情報(行政区域)(無償)を利用 by 国土交通省
• ポリゴンデータなのでクエリ一発で内外判定できる

2. 丁目・番地判定

• 街区レベル位置参照情報 by 国土交通省
• 代表点データ(ポリゴンではない)
• 代表点への距離を計算しないと内外判定できない →緯度経度から、クエリ2発で住所がフルでわかる。 (XeonX3210 Mem1GBで2～3msecくらい)

PostGIS

地理空間データを含んだデータを処理するもの。 http://postgis.refractions.net/ geometry型の地理空間データの管理・操作などを提供してくれる。 座標系の管理、空間インデックスなどなど。 市区町村判定まではクエリ1発でできる(ST_Within())。 ※インデックス張らないと遅い

概要

8.5～予定。本体内蔵。Slave側で参照クエリ実行可能。

• stream replicatoin: replicationを実現する。
• hot standby: Slave側で参照クエリを実行可能にする。 replicationが本体にない＝mysqlに対する大きなディスアドバンテージだった。

1. もともの方針: replicationの要件は色々すぎて満たしきれない→本体に入れない方針
2. これからの方針: シンプルなものを本体に入れておく ※本体同梱はシンプルなものなので、んまり高機能ではない！

replication

特徴

いつもどおりメモメモ。ちょいちょいにまとめなおしているので、そのままではありません。 適当に随時更新します。

Google Wave

現代の技術でemailを作り直したら・・・Google Wave

いつもどおりメモメモ。ちょいちょいにまとめなおしているので、そのままではありません。 適当に随時更新します。

スケールさせるためには

方法論を変えないといけない。 ツールだけ変えてもだめ(RDBMS→KVS)。

いつもどおりメモメモ。ちょいちょいにまとめなおしているので、そのままではありません。 適当に随時更新します。

セカイカメラのオープン化戦略

横向きで持って使う→使ってると怪しいｗ(不評らしい) そのうち世間がかわる、はずっ。

いつもどおりメモメモ。 ちょいちょいにまとめなおしているので、そのままではありません。 適当に随時更新します。

時代の流れ

• 10年単位でのトレンド
• 80' ダウンサイジング
• 90' クラ・サバ、インターネット
• 00' クラウド
• ・・・次は？
• プレイヤーの交代
• UNIX / RDBの台頭
• Sun, Oracle,,,の台頭。。(合併)
• 終わった時代
• レガシーな基幹システムしかなかった時代
• PCがなかった時代
• インターネットがなかった時代
• Googleがなかった時代
• OSSがなかった時代
• コミュニティがなかった時代

ライフサイクルのはなし

• 技術の寿命よりも技術者の寿命のほうが長い！
• 企業の寿命よりも技術者の寿命のほうが長い！ ↓
• 変化に敏感であらねば
• 常に学ばねば
• 仲間を作らねば ポイント: 時代の基本的な傾向を把握する→特定の技術・企業に閉じない！

丸山予想

• エンタープライズでは、エンタープライズクラウドと企業内システムのハイブリッド化
• 企業内システムはOSS活用によりシステムがコモディティ化
• 最近のPCなら1台でモバツイ20万PV/日をさばける
• ユーザ側は、PCからモバイル(クラウド・デバイス)に移行
• 個人-個人のコミュニケーションと情報の共有の要求がIT技術をドライブ

クラウド

Webスケールが実現可能に！

BPStudy#25に参加しました。 いつものとおりメモ。

MySQLのはなし

奥さん@サイボウズラボ

Happy Optimization

重要なこと

• プロファイラを使う
• Oprofileなどなど
• 局所的な最適化よりも前に考えておくことがある
• 投入したコストを回収できないと意味がない
• 「物理限界の○○%」(MIPS、帯域など)を目標にする→ゴールが明確 物理限界＝ゴール(の目標値算出に使える)
• 一般的にはIPCがネックになることが多い
• ソケットだと 100k transaction/sec 程度
• CPUクロックなどから限界値を算出する
• サーバ側でがんばるか、がんばらないかは考えましょう
• C10Kの問題はあるわけで。。。 限界を越えよう
• SIMD(SSE)
• Instruction per secが足りないならベクタ演算する
• 圧縮する
• I/Oの帯域が足りないなら圧縮転送
• グループコミット
• I/Oの帯域が足りないならまとめて書き込む(バッファリング)
• ロック回避

Scaling

Scale?

例によってメモ～

Twisted

コンピューターは待ちがいっぱい→解決したい 方法は2通り。

スレッドで多重化して効率化

• 同期型を多重化
• ブロッキングI/O
• コードが簡単でわかりやすい
• 遅い
• 無駄が多い(なにもせずただ待つ)
• 多重化したら、切り替えのオーバーヘッドがある

状態が変化したときだけ処理をすることで効率化→Network Programing Style！

例: AJAX, Chrome, Weave, Ariel AirOne, などなど