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