12月12日（日）に開催された「第1回 MongoDB JP ＆ CouchDB JP 合同勉強会 in Tokyo」に参加。
atnd http://atnd.org/events/10377
他の報告
スケジュール
時間 発表者 タイトル
14:00 14:15 @doryokujin MongoDB JPからのメッセージ
14:15 15:00 @doryokujin MongoDBを用いたソーシャルアプリのログ解析
15:10 15:50 @snamura Ameba Pico におけるMongoDB運用事例
15:55 16:10 @yssk22 CouchDB JPからのメッセージ
16:10 16:50 @yssk22 BigCouch の話
17:00 17:20 @basuke [LT]：ECサイトでのMongoDB導入事例
17:25 17:45 @madapaja [LT]：MongoDBと位置情報
17:50 18:10 @motokazu [LT]：センサーデータストアとしてのCouchDB
18:15 18:35 @mkouhei [LT]：CoucnDB on Androidでスタンドアローンアプリ
19:00 21:00 懇親会（ピザ・お菓子・アルコール）
—————————————-
MongoDB JPからのメッセージ
発表者 @doryokujin
MongoDB JP 主催者
11/18 MongoDB JP 設立
すでに200 名近い人がMLに登録
10gen も JP 発足を喜んでくれている。
アジア初の MongoDBカンファレンスを開催したい
2011/ 02-03 月開催を予定している。
500名規模
運営協力者募集している
—————————————-
MongoDBを用いたソーシャルアプリのログ解析
発表者 @doryokujin
GTE が提供する GREE/MIXI 向けソーシャルアプリのログ解析担当
ログ解析では
- データをたくさんとれるようにして
- どういうふうに利用すればいいか
つめていく必要がある。
ログ解析といっても backend と frontend で大きくことなる。
- バックエンド => データ収集
- フロントエンド => 収集データで分析
両方をつなげるデータベースサーバーとして MongoDB が存在する
利用技術
プログラミング言語は back/front 両方とも Python
10 億くらいのレコードがあっても、インデックスをはっておけば、高速にセレクトできる
Replica Sets / Auto Sharding が備わっている。
経営・企画の人にみやすいフォーマット(json)で出力することができる。
ユーザー属性に応じて戦略をかえたいという要望が企画側にはある。
JavaScript で関数を定義すればクロス表をすぐに作成できる。
5 億程度でも limit 指定やソートをがんばらない限り 1秒もかからない。
WEB アプリについて
REST インターフェース
基本実装は一日で完了
json 形式なので ajax なども楽
用語
Mongo : collection
RDBMS : table
JOIN について
他 コレクションとの JOIN は基本的にはない。
- クライアントサイドで頑張る
- DBRef を利用する
の2通りがある。
そのほか
Hummingbird = MongoDB + node.js
フルマラソンのベストタイムが2時間33分と驚異的に速いのだが、あの場にいた人たちはマラソンを走ったことがないのか、誰も気に留めていなかった。
—————————————-
Ameba Pico におけるMongoDB運用事例
発表者 @snamura
中規模サービスを何か月か運用したノウハウ。
EC2上で稼動(MongoDB は 64 bit 推奨 -> Large インスタンスを使う -> だと料金が高くなる。)
サーバは全部で30 台(内 MongoDB は 9 台)
アメーバピグでは独自の分散DBを利用している。
HAProxy を利用
3 台でレプリカセットを組むのが mongo の基本
運用してまだ4か月程度しかたっていない。
primary <-> secondary 切り替え
oplog のやりとりをし、 oplog が最新ものもほど優先的に failover 時に primary になる仕様。
MongoDB ドライバーについて
protocol がシンプルでノンブロッキング IO なドライバへの対応が容易
atomics modifiers
ピグでは利用していないが、他のプロジェクトで利用したところ、非常に有効だった。
MongoDB/Memcached の使い分け
memched は永続性のないもののみに対して利用
それ以外は基本的に mongo を直接みている
sharding
2010年6, 7月に正式対応
アクセスベースではなくデータ容量ベースで sharding されている
きれいに分散されず、偏った状態に収束する
Sharing は正式対応から日時がたっていないためノウハウがたまっていない
ベストプラクティスのようなものがまだない。
MongoDB はディスク容量を食う
MySQL よりもかなり消費する。
増え続ける容量とどう格闘するか?
BSON をつかっているので、JSON(JavaScript)と相性がよい。
Java(アメーバピグの実装言語) -> BSON と相性が悪い
Python, Ruby あたりのほうがむいている?
—————————————-
CouchDB JPからのメッセージ
発表者 @yssk22
CouchDB
MongoDB の機能削減+ HTTP プロトコル
sharding なし
BigCounch
スタンドアローンが基本思想にある CouchDB に分散機能を追加
CouchDB の中の人はよろこんでいるが、内部にとりこんではいない。
Couch の開発者は Lotus Notes/Domino の開発者
サーバサイドの人ではない
スタンドアローンが重要
ドキュメンテーション
ドキュメントが少い(弱い)->最近、ドキュメントの重要性に気づき、MySQL のドキュメント担当者を引っこ抜いた
BigCouch の場合 README がすべて
—————————————-
[LT]：ECサイトでのMongoDB導入事例
@basuke
PostgreSQL -> MongDB への移行
クライアントの要求に柔軟に対応
過去のミドルウェアのアップグレードの例
- Postgre 7.4 => 8.1
- PHP 4.3 => 4.4 => 5.1
- framework => 関心空間自家製フレームワーク
今回の移行後のシステム
- MongDB 1.6.3
- PHP : 5.3
- framework : Lithium
Lithium
PHP 5.3 の機能を活かしたもの。
CakePHP の開発者がフォーク
MongoDB/CouchDB をネイティブサポート
逆に RDB のサポートが弱い
管理ツールがしっかりしている。
import/export ツールがしっかり存在している。
秒の単位
MongoDB はコンソール上ではJavaScriptで処理を書く
JavaScript の秒 → ミリ秒
PHP → 秒
Mongo Extended JSONl
時間は ミリセカンド
EC サイトでのアトミックの確保
オーダー処理に関するものは1コレクションに完結するように すること。
オーダー処理をこえてatomic を確保しなくてよい
– orders
– order_items
の 2 テーブルにわかれていたものを1コレクションに集約して対応
MongoDB の JavaScript の TIP
JavaScript で書かれたテストコードが勉強になる。
一読の価値あり。
https://github.com/mongodb/mongo/tree/master/jstests
—————————————-
[LT]：センサーデータストアとしてのCouchDB
発表者 @motokazu
arduino を使ってセンシング
室内温度などのデータを取得。
SDカード内で CouchDB アプリを動かす。
HTTP とセンターは HTTP で通信
センサーのものと実サーバとがレプリケーションしている。
Arduino
=> ソフトウェア を書くような感じで書ける。
ハードウェア が苦手でも C さえかければ OK
ライフハック的な発表で面白かった。
—————————————-
[LT]：MongoDBと位置情報 ～地理空間インデックスの紹介～
発表者 @madapaja
mongo.jp の ホームページ担当者のかた。
Geospatial Indexing
Mongo の位置データ型対応
1.3.3 系列以降で対応
– near/exact 検索
– 半径指定
などが可能。
Sphere クエリ
Ver 1.7.0 以降で対応(開発版)
球体を加味した距離計算をおこなう。
http://www.mongodb.org/display/DOCS/Geospatial+Indexing
“The Earth is Round but Maps are Flat” とか “In 1.7.0 we added support for correctly using spherical distances by adding “Sphere” to the name of the query.” などと書かれている。1.8 の安定板が待ち遠しい。
検索はどのくらいのパフォーマンス?
near のハッシュをもとにしぼりこんでいる。
数万件 => 体感的にはたえられる程度。
「インデクシングのコードを見る限り、、、」とすらっと答えていたのに感動。
発表するかたは、みなさん優秀。
————————————————–
[LT]：CoucnDB on Androidでスタンドアローンアプリ
発表者 @mkouhei
debian.jp で活躍されているかた。
仕事はインフラのより。
夫婦の家計簿ソフトを CouchDB で作成
OpenBlockS600 を利用
Component
– CouchDB
– jQuery(jQuery mobile も)
スマートフォンブラウザ上でのPOST処理にてこずっている。
ライフハックネタ。
————————————————–
自分にかけているもの
普段の仕事がレガシーシステムの保守ばかりとはいえ、自分は新しい技術に疎い。
RDB 以外のデータベース、 Hadoop、 JavaScript(node.js, jQuery, …) などを勉強しないとね。
Siguniang's Blog 