Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mongodb World 2014

964 views

Published on

Published in: Technology
  • Be the first to comment

Mongodb World 2014

  1. 1. 忙しい人向けの MongoDB World @y_iwanaga_ 丸の内 MongoDB勉強会 #14
  2. 2. MongoDB World を 5分に凝縮。 ・新機能 ・設計、運用の間違いパターン集 基調講演まとめ Operations, Development, Internal セッションまとめ
  3. 3. 誰? @y_iwanaga_ @quake_alert @WeatherAlertJP 地震速報。テレビより早い。 千代田区の気象警報。 @IT で Arduino + JavaScript + IoT 連載中
  4. 4. 会場が一番 盛り上がった 瞬間
  5. 5. 基調講演
  6. 6. その場で実演 update の処理性能が $ mongod --setParameter useExperimentalDocLocking=true 約 10 倍に。
  7. 7. 新機能、続々。 Multi-Document Transaction Schema Validation Automation with MMS ロールバック処理をアプリで実装なくて済む。 Shard + Replica 構築、Shard 追加、Background Indexing 複雑なオペレーションまで自動化 将来の布石 複数のデータストアが連携する際、Data Hub の座を狙っている
  8. 8. 見落としがちな 設計・運用のミス ・何がダメだったの? ・正しい解決策は? 設計・運用セッションのまとめ
  9. 9. その1
  10. 10. 小売業界。20ヶ国 以上で展開。 スキーマ { id : 709, en_US : { name: ..., description: ..., ... }, en_GB : { name: ..., description: ..., ... }, fr_FR : { name: ..., description: ..., ... }, ... } 検索される製品は 国ごとに偏り がある 1つの document に全言語のデータを詰め込んでいる アクセスパターン 製品カタログ
  11. 11. どこがダメなの? ポイント: 使わないデータも RAM にロードされる 1回の検索で使うのは全体の 1/20 のみ メモリの無駄遣い mongod は document に何が入っているか知らない { id : 709, en_US : { name: ..., description: ..., ... }, en_GB : { name: ..., description: ..., ... }, fr_FR : { name: ..., description: ..., ... }, ... } → ドキュメントを取得した後、projection を行う。
  12. 12. 改善策:スキーマを変更する { _id : “709-en_US”, name : ... , description : ... , ... }, { _id : “709-en_GB”, ..., } 本当に必要とされるデータのみがメモリに乗る。 Disk I/O 減少。レスポンスを劇的に改善。 国ごとに document を分割 結果
  13. 13. その2
  14. 14. sh.shardCollection( “mydb.trades”, { analytics_server_id: 1 } ) 解析用サーバから送信されたデータを保存 「ある期間内」に、「どんなインシデント」が、何回発生したかを集計 解析サーバが増えても、Shard 追加で追従できる クエリパターン 取引ログを解析 Shard Key
  15. 15. どこがダメなのか? write パターンのみで shard key を決定 → ほとんどが “security_id” と “timestamp” がベース Shard Key の選び方 Read のパターン Aggregation する度に scatter & gather 「ある期間内」に、「どんなインシデント」が、何回発生したか
  16. 16. 改善策:Shard Key を変更 { security_id : 1, ts : 1 } 適切な Shard key を設定 ポイント: write と read 両方のアクセスパターンを考慮 compound shard key を利用
  17. 17. その3
  18. 18. heavy bulk update あるときは 10% の更新 あるときは 100% 更新 5 倍 の処理性能が必要に。 → Shard 追加 で追従しようとした ランダムな update が多い あるとき、サービスが急成長 意図:スキーマ変更ではこれ以上の改善が見込めない
  19. 19. 何がダメなの?
  20. 20. 正しい運用:scale up 本当に強化したいのは Random I/O 性能 HDD を SSD に変更 ・ ホスト1台あたりのコストは上がった。 ポイント scale out だけでなく、scale up も検討すべし ・ しかし、全台数の合計コストは下がった。
  21. 21. 以上 ・新機能 ・設計、運用の間違いパターン集 基調講演まとめ Operations, Development, Internal セッションまとめ

×