Mongo Tokyo 2012
前日に @key3 が「行くべき」みたいなことを言っていたので、「そうか、んじゃ行くか」的に行ってきた。自腹で。
とりあえずNoSQL系はだいぶ前にCassandraを少し触ったりしたくらいであまり予備知識なし、MongoDBに至っては名前しか知らないレベルで飛び込んできた、という感じ。
まずは会場について。
今回の会場は楽天タワーのだだっ広い部屋を借りての実施だったので、広さは全く問題なかった。何人入るんだあの部屋は。
ただ、パイプ椅子が固かったのはともかく、電源が取れなかったのがちょっと痛いなあ。
休憩時間に(非公式に)空いてるコンセントを使って充電させてもらってなんとか、という感じ。MacBook Airみたいに駆動時間の長いPCでほぼフル充電だったから良かったけど、そうじゃなきゃ途中で切れてたと思う。
まあ、電源については会場を借りる都合で難しい場合もある(特に楽天は震災後かなりの節電を推進してる)ので、できれば欲しいよね、っていう程度で。
無線LANは利用者多すぎでなかなか繋がらなかった。まあこれも致し方ないかなー。電源の方が重要。
内容の方は、まず俺がMongoについて殆ど知らないのでだいたい興味深く聞けた。
今日聞いた限りで、Mongoの特徴はこんな感じかなーと思った。
pros
- ObjectをJSON likeな形式で格納する
- sparseなデータ保持
- READが速い
- 多彩な検索条件を指定できる
- サーバーのメンテナンスが簡単らしい
- なかなか死なない (Single Point of Failureがない)
- サーバー分散で負荷分散や可用性向上ができる
- 容量を増やしたりWRITEに使うハードウェアを分散させるSharding
- HA構成やReadOnlyでの分散に使えるReplication
- Replication構成にすると、1つのPrimaryノード(Sharding構成の場合は複数)と残りのSecondaryノード群ができる。書き込みはPrimaryにのみ行われて、他のSecondaryには自動的に伝播される。書き込み時にSecondaryノードへの伝播を待つモードはなさげなので、各ノード群で内容に差異が起こりうる(？未確認)
cons
- WRITEは速くはないし、一度に集中するとOPLOGが溢れる可能性がある
- OPLOGが溢れるとReplicationに失敗して再構築を開始→その後Replicationを開始するが、再構築中にOPLOGが溢れてまた再構築とかいうループに陥ることがある
- トランザクションは無いものと思え (NoSQL全般そんな感じだよね…)
- Lockが行やテーブルではなく、DB全体ロックになる操作が時々ある
tradeoff
- CPU負荷は低いが、代わりにメモリとディスクへの依存が高い
個々の事例の中ではNiftyのHadoop + MongoDB = hadongo開発中です！っていう話が一番興味深かった。あれちょっと使いたいんですが…。何に使うかは考えてないけど。
あとはCAの事例がFlashを使ったゲームだったのでBlazeDSとか出てきて複雑な気分になったりした。
Flexとかそのサーバー側をがっつりやってた頃もあったので…。
基本的にデータを全部メモリーに乗せるから速いという、
ある意味身も蓋もない話やTeraDataを格納するのはまだ不安という声もあり、
個人的には特に書き込みが遅いのが気になっていて
実際の用途にマッチする機会があるかどうかは分からないけどハマれば使いやすい技術かなー、と。