mongodb world 2014

忙しい人向けの MongoDB World

@y_iwanaga_

丸の内 MongoDB 勉強会 #14

MongoDB World を５分に凝縮。

・新機能

・設計、運用の間違いパターン集

基調講演まとめ

Operations, Development, Internal セッションまとめ

誰？

@y_iwanaga_

@quake_alert

@WeatherAlertJP

地震速報。テレビより早い。

千代田区の気象警報。

@IT で Arduino + JavaScript + IoT 連載中

会場が一番 盛り上がった 瞬間

基調講演

その場で実演

update の処理性能が

$ mongod --setParameter useExperimentalDocLocking=true

約 10 倍に。

新機能、続々。Multi-Document Transaction

Schema Validation

Automation with MMS

ロールバック処理をアプリで実装なくて済む。

Shard + Replica 構築、 Shard 追加、 Background Indexing

複雑なオペレーションまで自動化

将来の布石複数のデータストアが連携する際、 Data Hub の座を狙っている

見落としがちな　　　設計・運用のミス

・何がダメだったの？・正しい解決策は？

設計・運用セッションのまとめ

その１

小売業界。２０ヶ国 以上で展開。

スキーマ

{ id : 709, en_US : { name: ..., description: ..., ... }, en_GB : { name: ..., description: ..., ... }, fr_FR : { name: ..., description: ..., ... }, ...}

検索される製品は 国ごとに偏り がある

１つの document に全言語のデータを詰め込んでいる

アクセスパターン

製品カタログ

どこがダメなの？

ポイント： 使わないデータも RAM にロードされる

１回の検索で使うのは全体の 1/20 のみ

メモリの無駄遣い

mongod は document に何が入っているか知らない

{ id : 709, en_US : { name: ..., description: ..., ... }, en_GB : { name: ..., description: ..., ... }, fr_FR : { name: ..., description: ..., ... }, ...}

→ ドキュメントを取得した後、 projection を行う。

改善策：スキーマを変更する

{ _id : “709-en_US”, name : ... , description : ... , ...},{ _id : “709-en_GB”, ...,}

本当に必要とされるデータのみがメモリに乗る。Disk I/O 減少。レスポンスを劇的に改善。

国ごとに document を分割

結果

その２

sh.shardCollection( “mydb.trades”, { analytics_server_id: 1 })

解析用サーバから送信されたデータを保存

「ある期間内」に、「どんなインシデント」が、何回発生したかを集計

解析サーバが増えても、 Shard 追加で追従できる

クエリパターン

取引ログを解析

Shard Key

どこがダメなのか？

write パターンのみで shard key を決定

→ ほとんどが “ security_id” と “ timestamp” がベース

Shard Key の選び方

Read のパターン

Aggregation する度に scatter & gather

「ある期間内」に、「どんなインシデント」が、何回発生したか

改善策： Shard Key を変更

{ security_id : 1, ts : 1 }

適切な Shard key を設定

ポイント： write と read 両方のアクセスパターンを考慮

compound shard key を利用

その３

heavy bulk update

あるときは 10% の更新あるときは 100% 更新

5 倍 の処理性能が必要に。→ Shard 追加 で追従しようとした

ランダムな update が多い

あるとき、サービスが急成長

意図：スキーマ変更ではこれ以上の改善が見込めない

何がダメなの？

正しい運用： scale up

本当に強化したいのは Random I/O 性能HDD を SSD に変更

・ ホスト１台あたりのコストは上がった。

ポイント

　　 scale out だけでなく、 scale up も検討すべし

・ しかし、全台数の合計コストは下がった。

以上

・新機能

・設計、運用の間違いパターン集

基調講演まとめ

Operations, Development, Internal セッションまとめ