[MongoDB] [MongoTokyo] MongoTokyoに行ってきた

イベント

あまりにほったらかしなブログなので、心を入れ替えて、そろそろちゃんと書こうと思います。
（遅いって）
　

ということで、開催から一週間も経ってしまいましたが、参加報告書いてみます。
聞くばっかりで、当日メモがあんましちゃんとしてなかったのと、変なこととか
間違ったこと書いてたらゴメンナサイ。あと一部社内向けの報告からの転載なので
改行が見にくかったりするのは直します。あとで。たぶん。。。

『Welcome to Mongo Tokyo and Introduction to MongoDB』/『Replication and Sharding』/『Schema Design』

最初のセッションは３つ続けてMongoDB Projectの立ち上げ元で、サポートを行っている
10gen社のエンジニアの方のお話でした。英語のセッションだったので、聞く方に注力していて、
あんまりメモとかとれていませんが、以下印象に残った話。

  • 月間ダウンロード数は12000ダウンロードを越えていて、今も順調に増えている
  • 1000以上のプロダクション利用がされている
  • NoSQL意味するところは？
    • No Relational
    • Next Generation
    • New Data Models ...
  • Mongoでスケーリングして性能を出すには、データモデルの考慮必要
    • 一つのdocumentに埋め込むのかリンクするのか？
    • documentの部分的な更新をするのか置き換えるのか？
  • indexの作りすぎ注意
    • あまり多数の値にindex作りすぎるとランダムアクセスが発生してパフォーマンス下がる
    • 等価な値が複数ある場合は、そのうち一つにしておくこと
    • そうすればワーキングセットを小さく保てるよ！！
  • 書き込み面でのスケーリングはAuto Sharding、読み込み面でのスケーリングはreplicationの機能を利用すること
  • ドキュメントのスキーマデザイン考えるときは以下のパターンなんかがある
    • One-Many
    • Many-Many
    • Tree
    • Queue

NoSQLの意味するところにNo Relationalはよく言われるところですが、Next Generation
という意味を含めているところが印象的でした。そこまでのパラダイムシフトが果たして
見えてくるのか、今後もNoSQLには注目しておくべきでしょう。あと、よくMongoの説明を
するときにスキーマレスが使われるし、自分も使ってしまうのですが、正確には
Semi-Structuredが正しそうです。

『You're Happy When You Choose Ruby and MongoDB』

Ruby(Rails)でMongoDBを利用した場合のお話。レセプト（医療明細）を扱うシステムを
作成したときの例でのお話でした。

  • Rubyで作るときにドライバやMapperの選択をどうするか？
    • MongoMapper
      • すでにあんまり開発進められてない
      • Rails3には対応してない？
      • pluginとか特徴的な機能があるので、それを使いたい人は使う？
    • Mongoid
      • 日本語での情報は一番多い
      • Rails3もサポート
      • 逆にRails2系は弱いかも？
    • Mongomatic
      • MongoMapperが機能ありすぎるからシンプル路線に行ったもの
      • パフォーマンスも上がるように作られた（けど、それほど大きくは変わらない）
      • Railsとか使わないなら選択肢
  • Ruby以外の言語からのアクセスとも比較してみた
    • パフォーマンス的にはRubyのドライバはあんまり早くない
    • PHPの方が圧倒的に速かったりする（特に更新を大量にかけるような場合）
    • Cネイティブのドライバ（C系のドライバを使う言語のドライバ）がやっぱり圧倒的に速い
  • レセプトでの例
    • レセプトのフォーマットがとにかくヒドい
    • ダメダメCSV（値があったりなかったり、変な可変長が混ざってたり）
    • ただ、ヒドいCSVを入れるのにMapperでの事前のスキーマ定義とかやりにくく、いろいろ試行錯誤
    • 黒魔術全開でMongoidのクラスをデータから自動生成とかやってみた、できた
    • けど、結局CSVの左からkey値として番号を降ってしまって、value指定するJSONにして、Mapper使わず直ドライバで扱うのが一番パフォーマンスが出た
    • Mongo+Railsでも必ずしもMapperを利用するという選択肢取らなくてもよいかも
    • CSV→Mongoへデータ格納→Hadoopでデータの解析→Rで出力な流れ

Mapperはいろいろあって選択に迷うところですが、必ずしもMapper使わなくてもよい
のかなぁと。というか、ならRailsじゃなくてもよいかもとか。やることによりますが。
あと、Railsと組み合わせて使う場合に、MySQLの置き換えとして利用するのは
パフォーマンス的にも十分現実的な選択肢としてすでに入れてよさそうとのこと。
RDBが向いてることに無理に摘要する必要はないですが、特に非定型なデータを
扱うものには選択肢になるかと。

『Social Data and Log Analysis Using MongoDB』

日本のMongoDBユーザグループの主催者でもある井上さんのお話。この３月まで
（つまり今現在）学生さんな方で、自分でユーザグループ立ち上げしてみるなど
なかなか行動力のある人です。ソーシャルゲームを展開している
芸者東京エンターテインメントでのログ解析事例のお話でした。

  • Accss Logを解析
  • Hadoop→MongoDBという流れ
    • HadoopでAccess LogをJSON形式の解析向けの形式に変換
    • MongoでMRを実効して、望んだデータを件索的に出力する
    • PV、UU、UVを出力
  • 見せ方の部分
    • ソーシャルの関係性とかはNeo4j（グラフDB）にデータを移してグラフ言語のGremlinでグラフ化
    • 数値データとしてのPVなどの表示
      • MongoにPython実装のREST Interfaceであるsleepy.mongooseを利用してRESTでアクセス
      • jQuery.tableやjQuery.chartsなどのjQuery系のライブラリを利用して表示
      • さらに統計的解析が必要な場合はRと連携させる（RESTで）

グラフDBも組み合わせて利用するなど、実践面でAcces Logの解析を行う上で、
いろいろ面白い事例でした。ソーシャルゲームの裏側ということで、今後は
もっとリアルタイム性のある解析もやりたいとのこと。Hadoopが挟まると、
どうしてもバッチ的になるので、そこをどうするかHadoopクラスタの
データフローを扱うFlumeなどをからめつつ念頭におきつつ検討中とのこと。

『MongoDB as a Search Engine Document Repository』

実際の製品に組み込んだ例です。プリファードインフラストラクチャーの
統合検索プラットフォームであるSedueでのMongoDBの組み込み事例で、
Sedueは日経系の各メディアなどで利用されていたりします。お話されたのは
CTOの太田一樹さんです（1985年生まれ、若い！！（><））。

  • Sedueとはエンプラ向けの分散検索エンジン
    • 分散してインデックス作って、分散したそれらに対して検索を実行していくようなもの
    • 5000万件くらいまでの対象を検索することに向けられて作られている
  • どんなデータが検索対象に含まれているかスキーマ定義のようなものが必要
  • 対応が必要になったこと
    • 顧客毎（とくにメディア関係のようなところでは）どんどん検索対象のスキーマが変わっていく
    • 扱うデータのフォーマットも様々
    • 先週言われた対象が、今週はいらないと言われたり、いると言われたものが使われなかったり
    • いちいちRDBのようなものでそれらをもっていていはシステム止めずにメンテとかできない
  • といくことでMongoを利用
  • Sedueでは裏で動くFile SystemやらStorageやらDBやらをプラガブルに利用できる構造になっている
  • その機構を利用してMongoを組み込み
  • MongoでサポートしているFile SystemであるGridFSにパフォーマンス面での難がややあるものの、問題になるほどではない（というか問題にならないような部分で使っている）
  • 実際に組み込んでみて分かったいくつかの問題点
    • ディスク容量を大量に必要とする（アペンドオンリーにありがちだけど）
    • アペンドオンリーなんでバキュームも用意されているけど、ロックしてしまう
    • データの圧縮にも今のところ対応してない
    • Fire-and-Forgetなので、実行後すぐに成功の返答あるけど、サーバ側失敗している可能性もある
      • getLastError関数を呼び出してみるまでは実は分からない（し、これを呼ぶとパフォーマンスが落ちる）
    • Shardingもまだパフォーマンス問題ありかも
      • 特にドキュメント増えていくほど
  • その他
    • 10genの人達はすごく反応が速い
    • バグフィックスのパッチとか送るとCTOから3分後にメールが来たり、そしてすぐ取り入れてもらえたり
    • あと協力するとマグカップがもらえるので、みんなで協力しよう!!

実際の製品組み込みで、運用されている事例なので貴重です。Shardingの話などは特に。
SlideShareに上がっている資料も見るべき（ってリンクどこいった。後で更新します。）

『Kiosk: The Schema Layer for MongoDB and PHP - Schema is Not Your Enemy』

PHPでActiveRecord的なMongoDBにアクセスできるMapperを作ってみたよというお話。
すみません、けしてPHPだからではないですがあんまりメモが残っていない（^_^;）

  • やっぱりスキーマレスとはいえ、アプリ作るときにはスキーマ的なものがないと作りにくい
  • PHPのドライバ直が実はパフォーマンスなんかはよいかもだけど、アプリ側で扱うオブジェクトとデータがシームレスに扱える状態にしておきたい
  • PHPでActiveRecord的なものでMongoDBと接続するMapperとしてKioskを作った
  • 使い方的にはActiveRecordと同等

ということで、実際のコードを示した実演もありました。

『Node.js and MongoDB』

日本のザッカーバーグと呼ばれているとかいないとかのサイバーエージェントで
アメーバピグやピグの米国サービスで、facebook platform上で作られている
アメーバピコを作っている名村卓さんのお話。これは非常に面白かった。

  • まだ市場公開はしていないPC向けソーシャルゲームのお話
  • 利用している技術は以下な感じ
    • MongoDB 1.8
    • node.js 0.4
    • WebSocket
    • flash
  • なんでMongoか
    • スキーマの自由度（ゲームなんでいろいろ追加とか変わってくし）
    • インデックスも柔軟につけられる
    • スケールする機能を持ってる
    • ドキュメント毎のatomic性を確保する仕組みもある
  • なんでJavaScriptのnode.jsにしたかの理由は
    • Javaの静的型付けなドライバに絶望した
      • だってスキーマの自由度も理由でMongo採用したのにそれって。。。
    • Rubyは社内の勢力が弱かった
    • Pythonianが多いんだけど、Python+twistedは同僚エンジニアに拒否された
    • なんかnode.jsが流行ってるし
  • Mongoの構成
    • 3台でのreplica setを3つのsharding構成（3x3）
    • 数万ユーザの同時接続をまかなえる
  • MongoDB+node.js
    • 『鼻血が出るほど相性がよい！！』
    • そもそもMongoのデータの持ち方はJSONをバイナリ化したBSON
    • MongoのクエリエンジンもJavaScript
    • クエリもJSON、データもJSONで扱える
    • プログラムとデータがシームレス
    • Mapperなんていらない！！
  • node.jsの特徴
    • 完全非同期
    • DBアクセスも全部コールバック
    • エラーハンドリングもコールバック
    • ネストが深くなりがちなので工夫必要
  • 工夫したこと
    • メソッドチェーンで連続した処理をかけるようにした
    • getLastErrorも裏で処理しておくようにした
  • 運用管理ツールを自作！！
    • ソーシャルゲームは運用が命
    • 裏で使う社内ツールなので、最新技術をバリバリ使える
    • 技術者の腕の見せ所
    • 最新技術使った良いツールを作ってチームのテンションとモチベーションを上げる→売上アップ
    • ということでピグのリアルタイムレポートツール
      • 注：デモを見ましたがほんとにリアルタイムにサクサクとアクセスやユーザの購買データなんかのレポートが流れてきます
      • データ定義をそのままフォームに利用できるので、利用している
      • WebSocketで通信
  • まとめ
    • 仕様やデータの構成が複雑で変更されるようなソーシャルゲームの裏側でMongoを利用するのは相性がよい
    • node.jsはMongoと相性がとてもよい
    • テストがすごく重要
      • スペルミスしちゃっても普通に動いてしまう
    • 厳格なシステムには柔らかすぎるから向かないかも
    • Shardingとかも普通には問題ないけど、たまに手動でチャンクの移動をしてあげないと偏りが出たり、まだまだな部分もある

アメーバでMongo使ってても大して驚かないのですが、共感したのは、
運用ツールのところで、社内で使うツールなんだから最新技術を
どんどん使って技術者のモチベーションも上げていくというところですね。
我々のようなSIとは運用と一口に言っても、異なる面が多いのは
置いておくとしても、社内で使うものに、どんどん最新の技術を
試していくというのはよい文化ですね。

その他

印象に残ったこと雑感

  • スーツな人はほとんどいませんでした。懇親会にも出ましたけど、だいたいがサービサーの中の人。
  • 登壇者、参加者の平均年齢が若い。たぶん1985年生まれから80年生まれくらいが一番多かったのじゃないか。
  • 10genの方がお子さんを連れて来られていた。米国らしいですね。
  • 英語はやっぱできたほうがよいなぁ。。。

以上、雑な報告ですんません。