Your SlideShare is downloading. ×
0
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
CyberAgentにおけるMongoDB
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CyberAgentにおけるMongoDB

12,987

Published on

0 Comments
65 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
12,987
On Slideshare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
98
Comments
0
Likes
65
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CyberAgentにおける MongoDB 株式会社サイバーエージェント アメーバ事業本部 テクノロジーグループ Ameba Infra. Unit                 桑野 章弘 13年12月12日木曜日
  • 2. アジェンダ n Amebaのサービス n サービス環境の変遷 n サービスを支えるMongoDB n 困ったことなど n 運用について n まとめ 13年12月12日木曜日
  • 3. 自己紹介 n 桑野章弘 l サイバーエージェント l Ameba を運営しています。 l ピグソーシャルゲームの運用/構築を担当 l Twitter l @kuwa_tw l Blog l http://d.hatena.ne.jp/akuwano/ 13年12月12日木曜日
  • 4. ピグライフ 13年12月12日木曜日
  • 5. ピグライフ n サービス情報 l 2011/05/31オープン l 自分の庭の育成ゲーム 13年12月12日木曜日
  • 6. ピグアイランド 13年12月12日木曜日
  • 7. ピグアイランド n サービス情報 l 2012/05/22オープン l 自分の島育成ゲーム 13年12月12日木曜日
  • 8. ピグカフェ 13年12月12日木曜日
  • 9. ピグカフェ n サービス情報 l 2012/08/21オープン l カフェ経営ゲーム 13年12月12日木曜日
  • 10. ピグワールド 13年12月12日木曜日
  • 11. ピグワールド n サービス情報 l 2012/11/27オープン l 自分の街をつくろうゲーム 13年12月12日木曜日
  • 12. なぞってピグキッチン 13年12月12日木曜日
  • 13. なぞってピグキッチン n サービス情報 l 2013/11/19オープン l スマートフォンのブラウザゲーム l パズルをクリアして自分のキッチンを育てようゲーム 13年12月12日木曜日
  • 14. ゲーム概要 n PC l ユーザ数は100万ユーザ∼300万ユーザ以上 l ピーク帯同時接続数10万以上 l オンプレミス n SPサービス l リリースしたばかり l AWS上で構築 13年12月12日木曜日
  • 15. 全ゲーム MongoDBを使用 13年12月12日木曜日
  • 16. サービス環境の変遷 13年12月12日木曜日
  • 17. n まずは弊社サービスの成長の変遷について説明し ます 13年12月12日木曜日
  • 18. アーキテクチャ n アプリケーションサーバ l Node.js l Nginx n データストアサーバ l MongoDB 13年12月12日木曜日
  • 19. アーキテクチャ BackEnd FrontEnd ユーザ/エリア等の状態 staticサーバ Flashデータ 必要なデータの取得 →リクエスト/取得 HTTP WebSocket接続 ・ユーザ情報 ・チャットデータ →リクエスト/取得 ユーザ (ブラウザ:Flash) 13年12月12日木曜日 データ Node.jsサーバ Socketサーバ mongodbサーバ
  • 20. [ピグライフ]の変遷 13年12月12日木曜日
  • 21. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在 13年12月12日木曜日
  • 22. ピグライフ n リリースから現在 l βテスト時代 l リリース後 l 現在 どんなフェーズを経たか 13年12月12日木曜日
  • 23. ピグライフ:βテスト時代 n 4/26∼5/31 l テストユーザ数5000∼30000 l 毎日リリース、機能追加、インフラ構成変更 l サーバも最小限を用意 13年12月12日木曜日
  • 24. ピグライフ:βテスト時代 βテスト時に実 装 6 mongos Staticサーバ Node.jsサーバ MongoDB 13年12月12日木曜日 行動ログの保存 MongoDB Log
  • 25. ピグライフ:リリース後 n 問題点洗い出しのフェーズ l Node.jsのサーバや、mongodbも、パフォーマン スが出ていなかったため増設 l Swfファイルをnode.jsのサーバから静的ファイル専 用のサーバへと切り出す 13年12月12日木曜日
  • 26. ピグライフ:リリース後 n 5/31 ∼ l ピグライフ、正式リリース l 人気が爆発、予想以上の伸び l 開始3週間(6/22)で100万人突破 l とにかく増設の時期 13年12月12日木曜日
  • 27. リリース時構成 大量追加 44 3 mongos Staticサーバ Node.jsサーバ 行動ログの保存 サーバにも取得 MongoDB Log 1シャード追加 (合計4シャー ド) MongoDB 13年12月12日木曜日
  • 28. ピグライフ:リリース後 n パフォーマンス確保のフェーズ l ボトルネック調査 l 状況を見つつサーバ台数、リソースの確保 13年12月12日木曜日
  • 29. ピグライフ:現在 n 9/1 ∼ l 順調な成長 l 開始3ヶ月弱(8/22)で200万人突破 13年12月12日木曜日
  • 30. 現在時構成 リリース時切替 高スペックサー バにリプレイス 5 5 10 mongos Staticサーバ_A系 Staticサーバ_B系 Node.jsサーバ_A系 ・・・・・ MongoDB 13年12月12日木曜日 10 Node.jsサーバ_B系 mongos 行動ログの保存 DB統合 23シャード追 加(合計27シャ ード=81台)
  • 31. ピグライフ:現在 n 運用改善のフェーズ l メンテ時間短縮のため稼働グループを分割 l A系、B系での切替 l 構成はシンプルにしていく l CDNなどの導入検討 (CDNを入れられるように仕様変更) 13年12月12日木曜日
  • 32. ピグライフ:成長速度 n 成長速度 l リリースから3ヶ月程度で、サーバ規模としては8倍 に。それにともなって、トラフィック(1.3Gbps)、 総コネクション数(18万)も増加。 l その期間は3ヶ月余り。3週間の伸びは単位にすれば 30倍 サービスの予想以上の成長 13年12月12日木曜日
  • 33. サービスを支える MongoDB 13年12月12日木曜日
  • 34. この成長速度を支えた MongoDBの基本的 な機能 13年12月12日木曜日
  • 35. MongoDBの構成 アプリケーションサー バ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 13年12月12日木曜日
  • 36. アーキテクチャについて n システムアーキテクチャ l スキーマレス l 冗長化 l ReplicaSets l スケーラビリティ l Sharding 13年12月12日木曜日
  • 37. アーキテクチャの課題 n スキーマレスなデータ構造による柔軟なデータ管 理 l ユーザ情報なども柔軟に持つことができるので、機能 追加時等が比較的楽 l 次ページ例 13年12月12日木曜日
  • 38. アーキテクチャの課題 n スキーマレスなデータ構造 l ユーザーコレクションに趣味を追加したい場合 { "_id" : "1234567889", "userid" : "akuwano", "username" : "Akihiro Kuwano" } { "_id" : "1234567889", "userid" : "akuwano", "hobby" : Movie , "username" : "Akihiro Kuwano" } 13年12月12日木曜日
  • 39. アーキテクチャの課題 n ReplicaSets l 相互死活監視&投票により冗長性を保つ。最小単位は 3台。 プライマリ セカンダリ 13年12月12日木曜日 セカンダリ
  • 40. アーキテクチャの課題 n ReplicaSets l 相互死活監視&投票により冗長性を保つ。最小単位は 3台。 生きているサー バで投票が行わ れ新しいプライ マリが選ばれる セカンダリ 13年12月12日木曜日 プライマリ セカンダリ → プライマリ
  • 41. アーキテクチャの課題 n Sharding l データをChunkの細かい粒度に分割する。 各mongodに分散して渡すことで各サーバの負荷を 分散します 13年12月12日木曜日
  • 42. MongoDBの構成 アプリケーションサー バ Sharding データをChunk の単位に分ける ReplicaSetsに よりサーバの冗長 性を確保 DATA mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 13年12月12日木曜日
  • 43. MongoDBの構成 アプリケーションサー バ Sharding データをChunk の単位に分ける ReplicaSetsに よりサーバの冗長 性を確保 ChunkA ChunkB ChunkC mongos mongocはシャ ーディング情報を 持つ Mongod[ShardA] Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC -> ShardC 13年12月12日木曜日 Mongod[ShardC]
  • 44. MongoDBの構成 アプリケーションサー バ ReplicaSetsに よりサーバの冗長 性を確保 Sharding データをChunk の単位に分ける mongos mongocはシャ ーディング情報を 持つ ChunkA Mongod[ShardA] ChunkB Mongod[ShardB] mongoc ChunkA -> ShardA ChunkB -> ShardB ChunkC -> ShardC 13年12月12日木曜日 ChunkC Mongod[ShardC]
  • 45. アーキテクチャの課題 n MongoDBのこれらの基本機能により、アプリ 側の実装コストは軽くなります。 n 前述した、9台→100台への変更においても、ア プリ側のDB接続部分の変更点は殆どありませ ん。 n スケーラビリティを保ったまま、シンプルなサー ビス構築を行うことができています。 13年12月12日木曜日
  • 46. ユースケース 13年12月12日木曜日
  • 47. ユースケース n MongoDBにかぎらず、NoSQLはできる、で きない、がハッキリしています n NoSQL使うならできる部分を伸ばす必要があり ます。もし、できない部分を突き詰めると RDBMSとなります 13年12月12日木曜日
  • 48. ユースケース:得意なもの n データ量が大き過ぎない n 書き込みが多過ぎない n 単位時間あたりの処理データが各シャードのメモ リ量を超えない処理は得意 n 得意なユースケース l ゲーム系Webアプリケーション l 一時的ログ解析基盤 13年12月12日木曜日
  • 49. ユースケース:苦手なもの n ホットデータが無い様なデータの使い方は苦手 l データ量が爆発的に増える l 常に全データへのアクセスを行うような n 苦手なユースケース l ソーシャル系等のWebアプリケーション l 継続的 or 統合的 ログ解析基盤 13年12月12日木曜日
  • 50. なぜか? 13年12月12日木曜日
  • 51. ユースケース n MongoDBのメモリ管理 l アクセスしたデータファイルはmmapとしてキャッ シュ l メモリからあふれた場合はアクセスされた物を入れ て、使われてないものを削除 l LRU的な仕組みはなく、OS任せ 13年12月12日木曜日
  • 52. ユースケース mongodb mmap datafile.0 13年12月12日木曜日 datafile.1 datafile.2 mmap
  • 53. ユースケース mongodb mmap datafile.0 13年12月12日木曜日 datafile.1 datafile.2 mmap datafile.3
  • 54. ユースケース mongodb メモリ量以上のデ ータアクセス毎に メモリ<ー>ディスク へのアクセスが頻 発 mmap datafile.0 13年12月12日木曜日 datafile.1 mmap datafile.2
  • 55. 困ったことについて 13年12月12日木曜日
  • 56. 運用中に困ったことに ついて 13年12月12日木曜日
  • 57. n クラスターのスローダウン l 必要なデータを一気にデータをインポートした場合 l oplogデータ量範囲を超えてレプリケーションが停止 l 一度に入れたため、PrimaryShardにChunkが溜 まってしまいI/Oバウンドに l 負荷が高いのでBalancerは動かないためクラスタの スローダウン →Oplogの容量を増やすことができるのでそれらで対 応 13年12月12日木曜日
  • 58. n シャード設定のスローダウン l ほんとに突然パフォーマンスダウンする 「10分前は動いてたけど、、、」 l PrimaryShardはリソースを潤沢な状態にする l 各シャードのmmapの容量が実メモリを超えてきた ら注意する →シャード設定は定期的に確認&シャードの設定を自 動化 13年12月12日木曜日
  • 59. n データ肥大 l 運用していくに連れてデータの肥大化する l 定期的なデータのコンパクションが必要です l repairコマンドは、データ容量と同容量のスペース を利用するので注意 l データ容量が小容量かつ、一時的にMongoDBを止 められる場合、データdrop→データresoreの方が 簡単です。 l RS組んでいるならローリングコンパクション 13年12月12日木曜日
  • 60. 日々の運用 13年12月12日木曜日
  • 61. ここからは実際の運用 でやっていること 13年12月12日木曜日
  • 62. n MongoDBに使用するハードウェア l CPU l (現在は)CPUはあまり負荷が来ないためそれほど良い物で なくて良い l そのかわりノードを増やすことになるのであればラックの効 率を上げるため消費電力の少ないものを選択する 13年12月12日木曜日
  • 63. n MongoDBに使用するハードウェア l メモリ l 積めば積むほどキャッシュが効くのでできるだけ積む l 現在は1ノード32GBのサーバを用意 13年12月12日木曜日
  • 64. n MongoDBに使用するハードウェア l DISK l こちらも書き込み、読み込みが早いに越したことは無い l 今までは、SAS * 4 RAID10 -> SSD * 2 RAID0 l 現在はSSDはSASの3倍のiops l FileSystemはxfs or ext4 - 高速なfallocate()がサポートが必要 13年12月12日木曜日
  • 65. n MongoDBに使用するハードウェア l DISK l ioDriveでの検証は、現状では8000opsを超えた位で ReplicaSetsのoplogの転送が止まる事を確認していた l が バージョン2.4ではこの現象はない=ioDrive 等を上手く 活用することでサーバ台数を減らすことができる 13年12月12日木曜日
  • 66. n バックアップ l mongodump l mongos経由の実行 l ポイントイン・タイムバックアップ l ReplicaSetsのDelay 13年12月12日木曜日
  • 67. n バックアップ l mongodump l mongosに対してmongodump実行するのはバックアッ プとしては一番簡単 - 稼働中ではポイントイン・タイムバックアップではない l mongodumpはmongodが起動していなくてもデータフ ァイルに直接かけてBSONファイルを取得できるので、これ を利用してポイントイン・タイムのバックアップを実装して います 13年12月12日木曜日
  • 68. n バックアップ l 稼働中にスナップショットバックアップを取得 l RSメンバとしてarbiterとnovoteのプロセスを起動 l 1,mongos経由でAutoBalancingをOff l 2,各レプリカセットのnovoteプロセスをダウン l 3,各mongodからmongodumpでデータ取得 l 4 , mongos経由でAutoBalancingをOn l 5 ,各Dumpデータの収集 l 13年12月12日木曜日
  • 69. バックアップの構成 アプリケーションサーバ 1、Chunkがバ ックアップ中に移 動させない バックアップサーバ 5,各シャードか らデータを取得 3,各シャードで Dumpデータを 生成 mongos Arbiter Mongod[ShardA] ✕ no vote Dump Arbiter Mongod[ShardB] no vote mongoc Arbiter Mongod[ShardC] no vote 13年12月12日木曜日 2,no vote プロセスダウン
  • 70. n バックアップ l ReplicasetsのDelay l バックアップと言うよりはオペミスの防止 l 常に最新の状態よりも一定期間古い状態となる、 Replicasetsを追加します 13年12月12日木曜日
  • 71. MMS n MongoDB Management Service(MMS) l 監視 l Muninプラグインとして提供 l バックアップ l シャード環境でのポイントイン・タイムバックアップを提供 - 13年12月12日木曜日
  • 72. MMS n MongoDB Management Service(MMS) l 監視 l Muninプラグインとして提供 l バックアップ l シャード環境でのポイントイン・タイムバックアップを提供 - 13年12月12日木曜日
  • 73. RS Delayの構成 アプリケーションサー バ この Replica Sets のみ、他の RSよりも3時間 前のデータを持つ mongos Mongod[ShardA] Mongod[ShardB] mongoc Mongod[ShardC] 13年12月12日木曜日
  • 74. n Index l indexが効いているかはexplain()で確認 l できるだけPK=_id で検索する実装にする replSetTest1001:PRIMARY> db.User.find({'Field01': 'test'}).explain() { "cursor" : "BtreeCursor testIndex_1", "nscanned" : 1, "nscannedObjects" : 1, "n" : 1, "millis" : 7, "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false, 13年12月12日木曜日
  • 75. n Index l 詳しいオプティマイザの実行結果が欲しい場合 は .explain(true) replSetTest1001:PRIMARY> db.User.find({'_id': 'test'}).explain(true) "allPlans" : [ { "cursor" : "BtreeCursor _id_", "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "indexBounds" : { "start" : { "_id" : "test" }, 13年12月12日木曜日
  • 76. n ロック l 同じサーバ上に異常に書き込みの多いコレクションが あるとクラスタ全体のアクセスに影響するため、コレ クションを分ける l アプリ実装はコレクション間をできるだけ疎結合に l 2.2以降DBレベルロックなのでDB分割 13年12月12日木曜日
  • 77. n ロック Collection A 13年12月12日木曜日 Collection B Collection C
  • 78. n ロック Collection A 13年12月12日木曜日 Collection C Collection B
  • 79. n 運用効率化 l どうしても台数が多くなる傾向にあります。 l そのため「標準のコマンドだと表示が多すぎて見づら い」「今のマスターの一覧が簡単に出したい」等の不 満がでます。 l これらはスクリプト作成等で対応しています、このあ たりもJSONで各種データを取ってこれるために管理 ツールなどは作りやすいです。 13年12月12日木曜日
  • 80. n 運用効率化 :運用スクリプトの内容 l ロックタイムの取得 l シャードに入っているmongod一覧のリスト出力 l レプリカセットのマスター検索 l レプリカセットのpriority検索 l printShardingStatusの整形 l レプリカセット一括作成/設定変更(現在のRSに Delayホスト追加するなど) 13年12月12日木曜日
  • 81. n 各種コマンド、ステータスなど l トレンドが見たい l 現状が把握したい 13年12月12日木曜日
  • 82. n 各種コマンド、ステータスなど l mongostat l mongotop l mongosniff 13年12月12日木曜日
  • 83. n mongostat l クエリや、プロセスの現状を確認するコマンド $ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018 insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr¦qw ar¦aw netIn netOut conn set repl time 192.168.8.41:27018 0 361 132 0 209 437 0 36.1g 76.2g 14.3g 1 2.2 0 0¦0 2¦0 85k 698k 3056 RSTest1001 M 11:16:57 192.168.8.62:27018 0 384 164 0 245 480 0 30.1g 63.9g 15.6g 0 2 0 0¦0 2¦0 96k 652k 2587 RSTest1002 M 11:16:57 13年12月12日木曜日
  • 84. n mongostat - 見るべき項目 l faults - 1秒当りのページフォールト数 l Locked % - グローバルライトロックの時間割合 l idx miss % - indexのヒット率の時間割合 l qr¦qw - 読み込みキュー¦書き込みキュー の大きさ 13年12月12日木曜日
  • 85. n mongostat - 見るべき項目 l faults が多い場合 キャッシュメモリ溢れの可能性があるので、メモリ、 もしくはサーバを増設 l Locked % が高い場合 書き込みのクエリを見直す or クラスタ分割。 l qr¦qw が高い場合 サーバ負荷が低ければ、ロックの可能性を疑う。負荷 が高ければ単純なクエリ増による高負荷を疑う。 13年12月12日木曜日
  • 86. n mongotop l 現在重いmongodのどのcollectionへアクセスがか かっているかを確認したりとかできまする。 l 障害の時がメイン $ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018 connected to: mongos_ip ns total read write 2012-05-23T02:14:12 local.oplog.rs 1929ms 1929ms 0ms life_prd_main.TestOnline 0ms 500ms 10ms life_prd_main.Test2Soil 8ms 0ms 8ms 13年12月12日木曜日 writeに時間 がかかってい
  • 87. n mongosniff l 最後はパケットキャプチャですので、何か会った際の アクセス状況の確認が可能 l mongosのアクセス状況とか、複雑なクエリを見た い場合はこれで見るのが良い # mongosniff --source NET eth0 27017 # 以下にパケットがズラズラっと並ぶ 127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes id:kjkjkjkj 14086840 query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0 127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268 2000171624 - 14086840 13年12月12日木曜日
  • 88. n ステータス確認・変更 l profiling l loglevel変更 l Working Set Analyzer l db.adminCommand("connPoolStats") l db.serverStatus() l db.currentOp() l db.collection.stat() l db.stats() 13年12月12日木曜日
  • 89. まとめ 13年12月12日木曜日
  • 90. まとめ n MongoDBを上手く使用することで、以下の様 なことが実現できています l 運用の安定 l 構成を変えずスケーラビリティを確保 l JSONを直接扱える事で開発スピードを早く 13年12月12日木曜日
  • 91. まとめ n ですが、運用するにあたって気をつけなければな らない点などがあり、上手い運用にはある程度の ノウハウが必要とも考えています n その辺りは私達もこのような場で適宜露出してい ますし、サポートしていただける所も今後増えて いくのではないでしょうか。 13年12月12日木曜日
  • 92. まとめ n ですがNoSQLは適材適所、という言葉もあり、 徐々に使って慣れていくのが大事だと思います。 スモールスタートでまずは使ってみてはどうでし ょうか。 13年12月12日木曜日
  • 93. ご清聴ありがとう ございました 13年12月12日木曜日
  • 94. 質疑応答 13年12月12日木曜日

×