2010年12月12日日曜日

第1回 MongoDB JP & CouchDB JP 合同勉強会 in Tokyoメモ

ギリギリ繰り上げで参加できることになったようだったので行ってきた。ちょうど会場近くの友人宅の家にいたから昼からそのまま直行。ちょうど今からmongoDB使いはじめてるからすごいいいタイミング。


ざっくりとメモと生かせそうな所を書いておく。

MongoDB JPからのメッセージ @doryokujin
  • 11月18日設立
  • 12月12日時点で200人弱
  • MongoDB Conference in Japan開催に向けての活動。日本でぜりやりたい!
  • 2011年2月末~3月 開催を目指して調整中

MongoDBを用いたソーシャルアプリのログ解析 @doryokujin


  • ログ解析をどう活用していくのか。GTEの場合は「意思決定を支援するための結果」に特化している
  • MySQLすばらしい。がスキーマの制約が行動ログの保管には厳しい
  • Hadoop、HIVE、pig強力だが大げさ、、、
  • Cassandra、HBaseはバックエンドとして強力だがフロントエンドには面倒
  • mongoDBは全体的に便利。joinはできないが範囲検索ができるなどfindが強力
  • インデックス張るのに時間かかる?
    →かかるけどバックグラウンドでのんびりやってくれる
  • データを見せながら会話、議論ができるのがよい
mongoDBのRESTinterface、これいいな。
と思ってオフィシャルみたらNode.js版もAlphaだけど作られていた。Pythonよくわからなくてハックし辛いからこなれるならNode.js版使いたいな。。。
ログレシーバみたいな高速処理が必要なのはNode.jsのほうがいいのかも。

Ameba Pico におけるMongoDB運用事例 @snamura

なぜmongoDBにしたのか?
mongoDB前は独自のDistributed Databaseを作っていた。(バックはMySQL)
しかし不安定になってきたので新DBの選定に移った。

データベース選定の条件
  • バイナリ形式に対応している
  • キーに対するRange Scanが可能
  • Horizontal Partioningによる分散
  • 開発チームがアクティブ
mongoDB
  • BSON
  • インデックスのサポート
  • Shardingによる分散。Chunkの分割の方式が既存と同じ
  • 開発チームが積極的でアクティブ

最初の計画
  • Arbitery=ReplicaSetは3台が基本で、2台でやりたい場合はArbitaryが必要
導入した構成
  • Shard x 3 x 3のReplicaSet
  • configはSecondaryに配置。SocketServer側にmongosを設置
  • mongos=ShardingされたDBがあたかも1つに見えるような形になる
  • データ移行の際はバイナリのソート方式に注意

遭遇した問題
  • ext3はextentに時間がかかる
  • 推奨されているのはext4,xfs。Picoはext4

Shardingの偏り
  • 普通に運用すると偏る。Webから各コレクションのアクセス量を確認し、多いコレクションはmoveChunkコマンドで移動する
  • ドキュメント量の少ないコレクションはRead、Writeが偏るので適宜アプリで対応

接続プール
  • ファイルオープン数を増やしてスレッド数やプール数を調整する
  • =OSのファイルオープン数を調整する必要がある。mongoDBを再起動する
Primary選択問題
  • EBSを使っているSecondaryのPriorityを0にしてPrimaryに昇格しないようにしていた
  • oplog(=リレーログ、バイナリログ)というものがあり、これが最新のものが昇格するルールもある
  • よってoplogの状況とPriority次第では両社がブロックしてPrimaryがいない→コマンドも受け付けないのでstepDownもできない
  • configサーバを直接いじって直した

→Priority:0今は危険!!!

よかったところ
  • 思ったよりずっと安定している
  • プロトコルがシンプルでノンブロッキングIOなドライバへの対応が用意
  • Atomic modifiers便利
  • Sharding+Replica Set
  • mmapを活用するので基本メモリキャッシュに乗る→すごくはやい!!!

気になるところ
  • Durability
  • Chunkが分割されるときのフリーズ
  • Shardingの安定性
  • Primaryがダウンしたときのデータロス
  • ディスク容量を結構使う

CouchDB JPからのメッセージ @yssk22

  • 1月Hackathon開催
  • 3月OSC Tokyo Spring
  • 12月MongoDB&CouchDB勉強会
  • CouchDB on Android
  • BigCouch

BigCouchの話 @yssk22

  • クライアントも視野に入れたクラスタリング
  • クラスタリングが無い=OuchDB。。。
  • CouchDBの開発者は元々Lotus
  • CouchDBの目指すクラスタはかなり方向性が違う

BigCouchとは何か
  • 構成‐CouchDBを並べたもの
  • CouchDBにクラスタ構成の機能を追加。本家とは別に作られている
  • 表側からは単一のCouchのように見える→アプリを書く側からは意識することはない
  • 分散アルゴリズムはDynamoほぼそのまま
  • Shardの数は3以上は欲しい
  • 中の人曰く、「ドキュメントはWebにあるものが全て=ソースみろ」
  • 設定ファイルがErlangの機能を前提にしているのでErlangの知識も必要
トレードオフの関係
  • q:シャード数
    増やすほどMapReduceの負荷が分散
  • n:複製するシャード数
    増やせば増やすほどディスクを食う
    r <= n w <= nでないといけない
  • w:書き込み保証数
    増やせば増やすほどレイテンシは下がるが整合性が高くなる
  • r:読み込み保証数
    増やせば増やすほどレイテンシは下がるが整合性が高くなる
運用は結構大変。仕事でやるの結構やだな。。。
BigCouchはmongoDBの真似しているような感じで面白くない。
オフラインでも使えるように端末に組み込むなどCouchならではな使い方をしたほうがいいのでは。

[LT]ECサイトでのMongoDB導入事例 @basuke

PostgreSQLからmongoDBへの移行
  • not only 規模問題
  • 複雑性への解決!
オーナーのこだわりが凄い。しかも自分でテキスト書いて写真をつけたりしている。
でも楽はしたい。通販サイトなのである程度は構造は必要。
とにかく色々と要望が多い。

どうするのか?→そこでmongoDB

元々はPHP&PostgreSQL
そこからMongoDB+PHP5.3+Lithiumへ変更予定

移行に必要なデータの変換について
MongoDBはツールが結構揃っている。しかもドキュメントがちゃんとある。
PHPで変換スクリプトを組んでmongoimportで入れた

PHPはつらい。Pythonのほうがよかったと後で思い返した。

小ネタ1:atomicについて
→オーダーレベルでatomicであれば問題ないので1つのコレクションにまとめる

小ネタ2:シリアルについて
→注文系だとシリアルな番号も欲しい。
 そういう時はファンクションを書いてevalで呼び出す。

小ネタ3:mongo on github
 JavaScriptのSnippet万歳

[LT]センサーデータストアとしてのCouchDB @motokazu

とりあえずデータをためたい人にはよい。
センサーからデータを送るにはhttpが都合がよい
relaxって何?

家の中をモニタリングブーム
  • オール電化
  • 部分的に設置
  • センサーを自分で作る(Arduino)
自分で作れば安くどうにかなる!
JSONをsprintfで生成してhttpで送ってあげる仕組み
map->reduce->rereduceで集めないといけない

何がいいのか
  • 一人、オール電化
relaxとは?
  • ストレスなくdbつめこみからWebアプリまでできる

[LT]MongoDBと位置情報 @madapaja

地理空間インデックスの使いかた
位置情報が今Hot。GPSとか色々

二次元の地理空間情報をインデックスにして検索ができる

Indexの作成
Indexを作成したいフィールドにensureIndex "2d"
ただし二つのGeoIndexははれない

保存も簡単。2つのfloatをx,yの順で入れるといい

クエリー色々
  • 完全一致→あんまり意味が無い
  • $near→指定ポイントから近い順にソート
  • $maxdistance→検索範囲を指定する
  • geoNearコマンドを使うと詳細情報を取得できる
    near→GeoHashのビット列が返る
  • $within→領域を指定して検索できる。長方形と円形が使える
普通に使うと赤道から離れるほど精度が落ちてしまう。
そこで1.7.0以降で利用できる予定の「Sphere」クエリ
これで正しい距離でのソート可能になる。
※Sphereでは距離の単位ではラジアンになる

利用の注意
  • Shardされたコレクションでは利用できない
  • (Sphereの場合)経度、緯度はX,Yが並んでいることを前提に計算する
  • (Sphereの場合)北極、南極や+-180以上は対応していない

[LT]CoucnDB on Androidでスタンドアローンアプリ @mkouhei

家計簿に割く時間が多く、負荷が高いのをなんとかしたいというところからスタート。
レシートの入力はAndroidで実行し家のMacBookで閲覧するような形に。

自分でWebアプリ作るにはなかなかいいかも。

内容以上に家の環境が凄くてそこが記憶に残った。。。
トリにふさわしい面白い話でよかった。

-------

というわけでこれから懇親会に。

0 件のコメント:

コメントを投稿