第2回 MongoDB JP 勉強会に行ってきた

今週はMongoDBの勉強会に参加してきました。

Sharding詳解 [twitter:@doryokujin]

MongoDBでShardingを使用する際のポイントや注意点についての発表です。
こういう話はこれからShardingを使おうとする人にとっては大変有益。
前日にさくらVPSで試して見たので、割と理解できたような気がする。

  • Shard Keyの設定は非常に重要、慎重に
    • Shardの偏りを極力減らすことは重要
    • Shard Keyによって偏り具合が大きく異なる
  • 注意点
    • Shard Keyは変更できない
    • Shard Keyを持たないドキュメントは保存できない（nullは可能）
  • Shard Key選択時の悪い例
    • カーディナリティが低い値（性別等）
      • Chunkの分割ができない
      • カーディナリティがNならば、N個のChunkしかできない → N台以上のShardサーバは無意味
    • 常に増加するデータ（Time、ObjectID、シーケンス等）
      • Chunkの分割が常に同じ方向となるため、Shard間で不均一となる
    • ランダムな値（ハッシュ値等）
      • 非常に大きな範囲を持ったChunkが存在する可能性があり、Migration時にRAMを圧迫する
      • indexが非効率
  • Shard Key選択時の良い例
    • 緩く増加するキー ＋ 検索でよく使われるキー
      • アクセス解析{month:1 , user:1}
      • monthは一定期間固定で、userは均等に分布される
      • 時間がたつとmonthのキーの値が増え、古い値のChunkは分割されずMigrationが起こりにくい
  • Sharding環境でShard Keyを使用しないクエリは正しく実行されるとは限らない
    • Chunk Migration中のcount
      • Migration中は移動元、移動先に同じChunkが存在するため、重複してカウントする可能性がある
    • 同時書き込み発生中のunique index
      • 書き込みロックを行わないため、unique indexとして設定したキーが異なるShard間で存在する可能性がある（_idを含む）
    • 同時書き込み発生中のsingle-update()
      • Non Shard Keyに対し、同時にsingle-updateを実行するとエラーとなるため、multi-updateを実行
    • tmp_collectionが削除されないmapreduce(v1.8で改善。手動で削除)
      • tmp_collectionが自動で削除されないため、不要なcollectionが増えていく
Type safe mongodb with Scala [twitter:@bibrost]

勝間Web 中の人の発表。

↓bibrostさんのブログで＋αの話が。
第2回 MongoDB JP 勉強会＋α　アーキテクチャ選択の話

アクセスログをできるだけいろいろ見る時のmapreduce+ニフティクラウドでの構築とパフォーマンスを初心者からわかりやすく [twitter:@muddydixon]

資料は こちら から。

↓muddydixonさんのブログで解説があります。
第2回 MongoDB JP 勉強会 in Tokyoに参加してきました

  • Hadoop streamingとmongoimport相性が良い。
  • mongodbのmapreduceは、hadoopと異なりshuffleフェーズが無かったり、finalizeがあったりと多少異なる点がある。
  • 世界でも数少ないmongodbのmapreduceのサンプルが記載されているので、必見。
地理空間インデックスを利用したWebアプリケーション [twitter:@yamaneko1212]

一部で話題沸騰の農家ニートプログラマことyamaneko1212さんによる発表。

資料は こちら から。（PDFです）

mongodbを使った地理空間インデックスのお話。

Tachy with MongoDB [twitter:@joe_hrmn]

サイバーエージェントの実名携帯SNSサイト「Tachy」でmongoDBを使用した際の話。

↓joe_hrmnさんのブログです。
第2回 MongoDB JP 勉強会に参加してきました

  • ユーザ情報はMySQLで管理しているが、それ以外の情報は全てMongoDBで管理している。
  • 採用理由
    • picoで社内実績あり
    • アクセスが高速
    • 自動failover
    • データ分散が自動
  • 大量のinsertが遅いのでbulk insertにしたら早くなった
Toggeter [twitter:@ixixi]


所管＆まとめ
  • 全体的にログ解析等のバックエンドに使用されている感が強いが、「Tachy」でフロントエンドでも実用事例も出てきている。
  • RDBMSみたいに誰でもなんとなく使えるものではないので、適用箇所、目的をはっきりする必要あり。
  • 難しいのはcollectionやshard keyの設計。Embedした方が良いのか、しない方がよいのか、きちんと考えてから決めるべし。