MongoDB very basic (Japanese) / MongoDB基礎の基礎

2,707 views

Published on

OSC2014 Kansai@Kyoto で発表したスライドです。著名なNoSQLの一つであるMongoDBについて、ドキュメント指向データベース、パフォーマンスとインデックス、レプリカセット、オートシャーディングといった特徴を取り上げ、教科書的な基礎を紹介しました。

Published in: Technology

MongoDB very basic (Japanese) / MongoDB基礎の基礎

  1. 1. OSC 2014 Kansai@Kyoto MongoDB 基本の基本 2014.08.02 MongoDB 日本ユーザー会 MongoDB JP 小笠原徳彦 (OGASAWARA, Naruhiko)
  2. 2. OSC 2014 Kansai@Kyoto 2/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  3. 3. OSC 2014 Kansai@Kyoto 3/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  4. 4. OSC 2014 Kansai@Kyoto 4/52 MongoDB JP とは MongoDB を使ってる!使いたい!興味ある!人たち の集まり 公式サイト: http://www.mongodb.jp/ Google Groups: https://groups.google.com/forum/#!forum/mongodb-jp Facebook Page: https://www.facebook.com/MongodbJp 丸の内 MongoDB 勉強会 #mongonouchi http://syokenz.github.io/marunouchi-mongodb/
  5. 5. OSC 2014 Kansai@Kyoto 5/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  6. 6. OSC 2014 Kansai@Kyoto 6/52 MongoDB とは MongoDB Inc. が中心になって開発している NoSQL データベース MongoDB http://www.mongodb.org/ MongoDB Inc. http://www.mongodb.com/ ライセンスは AGPLv3 SQL のような DDL は存在しない 言語ごとに異なる「ドライバー」を経由してアクセス C 、 C++ 、 Ruby 、 Perl 、 Python 、 Java 、 JavaScript 、 Scala 、 Haskell 、……
  7. 7. OSC 2014 Kansai@Kyoto 7/52 RDBMS と NoSQL(1) RDBMS (Relational Database Management System) 関係モデルに基づいたデータベース管理システム SQL (Standard Query Language) による宣言的な操作 オプティマイザにより「どうデータを格納し」「どうデータを得 る」かは最適化されて高速に実行される アトミックなデータ操作 データの一貫性保持が重要
  8. 8. OSC 2014 Kansai@Kyoto 8/52 RDBMS と NoSQL(2) しかしクラウド時代においては、データの一貫性保 持はコストが高い……こともある 一貫性保持は常に必要なのか? 例: EC サイトの在庫状況はリアルタイムでなくてもよい 決済時に一貫性が担保されていればよい 一貫性の完全な保持を諦めれば水平にスケールできる DB App Tokyo US App EU App EU AppDB US AppDB Tokyo AppDB
  9. 9. OSC 2014 Kansai@Kyoto 9/52 RDBMS と NoSQL(3) クラウドに必要な要件を持つストレージエンジンを RDBMS と使いわける シンプルな機能 高速 スケーラブル Not Only SQL = NoSQL (SQL に NO! ではない ) Key Value Store (KVS) Apache Cassandra, Tokyo Cabinet, Rakuten ROMA, Redis, Riak グラフ指向 DB Neo4j, HyperGraphDB 列指向 DB Apache HBase ドキュメント指向 DB CouchDB, MongoDB
  10. 10. OSC 2014 Kansai@Kyoto 10/52 NoSQL の一つとしての MongoDB(1) ドキュメント指向データベース バランスの良い NoSQL を目指す https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144 スケーラビリティ&パフォーマンス 機能の豊富さ memcached key/value store MongoDB RDBMS
  11. 11. OSC 2014 Kansai@Kyoto 11/52 MongoDB の強み ドキュメント指向 多彩なクエリー 文字列としてのマッチ、範囲検索、正規表現など 論理演算で複数の条件の組み合わせも可 B-Tree インデックスによる検索・ソートも使える ほぼオンメモリで動作するため非常に高速 { "_id" : ObjectId("524406662caf1cab1f000001"), "title" : "MongoDB is fun!", "body" : "I love MongoDB very much.", "author" : "naruoga@example.com", "created" : ISODate("2013-09-26T10:03:18.825Z"), "comment" : [ { "author" : "foo@example.com", "content" : "I also love it!" } ] }
  12. 12. OSC 2014 Kansai@Kyoto 12/52 MongoDB の割り切り トランザクションを持たない 複数の操作をくるんで、途中で失敗したらロールバック ……といった機能はない 一つ一つのデータ操作はアトミック JOIN がない 複数のドキュメントを DB 側で結合はできない アプリケーションで結合する必要があるがアトミックな操 作ではない …… でも、なくても構わない状況は多いよね? と いう割り切りがポイント
  13. 13. OSC 2014 Kansai@Kyoto 13/52 MongoDB/NoSQL と RDBMS NoSQL とは一般に「使い方にクセがある」「どこか 割り切ったことがある」「その代わりにとても得意な ところがある」もの 事前に「不得意なところが許容できるか」を判断で きないなら、素直に RDBMS を使ったほうが良い 速度 クエリーの種類 トランザクション メモリ使用量 ディスク使用量 スケーラビリティ 0 50 100 RDBMS MongoDB このグラフは 例であり 実際の評価では ありません
  14. 14. OSC 2014 Kansai@Kyoto 14/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  15. 15. OSC 2014 Kansai@Kyoto 15/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  16. 16. OSC 2014 Kansai@Kyoto 16/52 MongoDB = ドキュメント指向 RDBMS: 関係(表) MongoDB: ドキュメント ID NAME EMAIL 1 Naruhiko Ogasawara naruoga@exam ple.com 2 Ichiro Tanaka tanaka.ichiro@e xample.com 3 Taro Yamada taroy@example. com Users ID CONTENT A_ID 1 ぼくもお気に入り! 2 2 使い所難しいです けどね。 3 ... ... ... Comments ID ARTIC LE_ID COMM ENT_ID 1 1 1 2 1 2 ... ... ... CommentsLink ID TITLE BODY A_ID 1 もんごた ん楽しい! MongoDB いいです ね!好きです! 1 ... ... ... ... Entries { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "tanaka.ichiro@example.com", "content" : " ぼくもお気に入り! " }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 " } ] } ↑JSON (JavaScript Object Notation) I
  17. 17. OSC 2014 Kansai@Kyoto 17/52 ドキュメント指向と動的スキーマ (1) RDBMS: 表 各列の型は一致してい る必要あり MongoDB: ドキュメント それぞれの文書の構造 は異なっていても構わ ない 検索その他では存在す る部分だけが対象 ドキュメントの集まりを 「コレクション」と呼ぶ { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "tanaka.ichiro@example.com", "content" : " ぼくもお気に入り! " }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 " }, ] } { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "created" : ISODate("2013-09-26T10:03:18.825Z"), }
  18. 18. OSC 2014 Kansai@Kyoto 18/52 ドキュメント指向と動的スキーマ (2) アプリケーションの設計の段階で、スキーマ定義を 厳密に考えないでも大丈夫 すぐに開発に取り掛かれる カジュアルにスキーマ定義を変更できる スピード感のあるアプリ開発 パフォーマンスを得るにはスキーマに対する十分な 理解が必要なので「スキーマレス」は厳密には NO 作りながらスキーマを定義していく 動的スキーマ
  19. 19. OSC 2014 Kansai@Kyoto 19/52 スキーマ定義の例:ブログ 大雑把な仕様 記事が持つのはタイトル、内容、著者、記事が書かれた 日時、コメント、 permalink コメントが持つのは内容、著者 blog.example.com もんごたん楽しい! by Naruhiko Ogasawara MongoDB いいですね!好きです! 2014/01/23 13:13 comment (2) ラーメン食べたい by Taro Yamada なんだかラーメンな気分。どこかで食べ ていこうかな。 2014/01/22 20:13 comment (2) ... 新着 10 件 Click blog.example.com/permalink もんごたん楽しい! by Naruhiko Ogasawara MongoDB いいですね!好きです! 2014/01/23 13:13 ぼくもお気に入り! by Ichiro Tanaka 使い所難しいですけどね。 by Taro Yamada コメ ント
  20. 20. OSC 2014 Kansai@Kyoto 20/52 ブログのスキーマ例 (1) RDBMS 的にはこう { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author_id" : ObjectId("52e1ee36..."), "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ ObjectId("52e1f310..."), ObjectId("52e1f310...") ] } Collection: posts { "_id" : ObjectId("52e1ee36..."), "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", } { "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", } { "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "taroy@example.com", } Collection: authors { "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : " ぼくもお気に入り! ", } { "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : " 使い所難しいですけどね。 ", } Collection: comments 正規化のためにコレク ションを分割 ● ちょっと煩雑 ● アプリケーション JOIN が必要になる 正規化のためにコレク ションを分割 ● ちょっと煩雑 ● アプリケーション JOIN が必要になる
  21. 21. OSC 2014 Kansai@Kyoto 21/52 ブログのスキーマ例 (2) 投稿とコメントは似た項目が多いのでまとめられる { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author_id" : ObjectId("52e1ee36..."), "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ ObjectId("52e1f310..."), ObjectId("52e1f310...") ] } { "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : " ぼくもお気に入り! ", } { "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : " 使い所難しいですけどね。 ", } Collection: posts { "_id" : ObjectId("52e1ee36..."), "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", } { "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", } { "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "taroy@example.com", } Collection: authors 動的スキーマの利点を用いる ● 扱うコレクションが一個減ってスッ キリした ● アプリケーション JOIN が必要にな る点は変わらない 動的スキーマの利点を用いる ● 扱うコレクションが一個減ってスッ キリした ● アプリケーション JOIN が必要にな る点は変わらない
  22. 22. OSC 2014 Kansai@Kyoto 22/52 ブログのスキーマ例 (3) いっそのこと全部埋め込んでしまおう! { "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", "content" : " ぼくもお気に入り! ", }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 ", }, ] } Collection: posts JSON においては配列の要素内には 任意の JSON オブジェクトをとれるの で、この中にコメントの情報を直接埋 め込んでしまう( embedded ) ● MongoDB の強力な文書操作機能 により、配列内部にデータを押し込 んでも柔軟に操作可能! ● あれ、 author 正規化しなくていい の? ● 考えてみれば、ユーザー名とかパ スワードのたぐいはブログアプリ側 でセッションで管理しているはずな ので、 DB 側でユニーク性を保証す る必要はない!と割り切れる ● 迷ったら埋め込み文書、が MongoDB 的スキーマ設計 JSON においては配列の要素内には 任意の JSON オブジェクトをとれるの で、この中にコメントの情報を直接埋 め込んでしまう( embedded ) ● MongoDB の強力な文書操作機能 により、配列内部にデータを押し込 んでも柔軟に操作可能! ● あれ、 author 正規化しなくていい の? ● 考えてみれば、ユーザー名とかパ スワードのたぐいはブログアプリ側 でセッションで管理しているはずな ので、 DB 側でユニーク性を保証す る必要はない!と割り切れる ● 迷ったら埋め込み文書、が MongoDB 的スキーマ設計
  23. 23. OSC 2014 Kansai@Kyoto 23/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  24. 24. OSC 2014 Kansai@Kyoto 24/52 ●MongoDB の性能の秘密 MongoDB はファイルシステムに展開されているコレ クションを mmap している ローカリティがある READ アクセスについてはオンメモリ でアクセスするので高速 要は「ディスクにスワップアウトできるオンメモリ DB 」 ローカリティが低いアクセスは性能が出ない Storage V. mem P. mem
  25. 25. OSC 2014 Kansai@Kyoto 25/52 データアクセスとインデックス MongoDB のデータアクセスはとても素朴 頭から順に舐めているだけ(線形探索)=検索 O(n) ついでにいうとドキュメントの順序は保証されない インデックス あるキーに着目した B-Tree インデックス=検索 O(log n) 検索・ソートに利用可 Doc1 Doc2 Doc3 … DocN update Doc2 (サイズ拡大) Doc1 Doc2Doc3 … DocN(隙間)
  26. 26. OSC 2014 Kansai@Kyoto 26/52 インデックス詳細 インデックスはコレクション自体と同じファイル どんどん張っているとデータサイズが肥大化する インデックスを後から張るとデータ量に比例した時 間がかかる(当然) 昇順・降順でインデックスは張れる 複数キーのインデックスも利用可能 db.posts.ensureIndex({created_at:-1, author:1}) 部分的に使うことも可能
  27. 27. OSC 2014 Kansai@Kyoto 27/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  28. 28. OSC 2014 Kansai@Kyoto 28/52 レプリカセット基礎 (1) レプリカセット:簡単な仕組みで高可用性を実現 最低 3 台のノードをセットにして動かす アプリケーションに応答するプライマリノードは自動的に 決定される(明示的なマスターノードは存在しない) Secondary 1 Secondary 2Primary Application Driver Read Write Heartbeat Replication Replication
  29. 29. OSC 2014 Kansai@Kyoto 29/52 レプリカセット基礎 (2) プライマリノードがダウンした場合 残ったノード間で投票を行い次のプライマリを決める この場合は「どこまでレプリケーションが終わっている か」で決まる Secondary 1 Secondary 2Primary Application Driver Heartbeat ぼくは 5 分前の 処理まで レプリカもらったよ ぼくは 10 分前 までだなぁ
  30. 30. OSC 2014 Kansai@Kyoto 30/52 レプリカセット基礎 (3) 選ばれたノードが次のプライマリになる この時点でノードがダウンすると、 1 台では投票ができ ないためレプリカセットがダウンする 1/3 冗長 Primary Secondary 2Primary Application Driver Heartbeat じゃあぼくが プライマリーやるね Replication READ WRITE
  31. 31. OSC 2014 Kansai@Kyoto 31/52 レプリカセット基礎 (4) ダウンしていたノードが復活するとセカンダリノード に復帰 ただしダウンタイムが長いと自動復帰は不可 動いているセカンダリノードからリストアするのが無難 Primary Secondary 2Secondary 2 Application Driver Heartbeat Replication READ WRITE
  32. 32. OSC 2014 Kansai@Kyoto 32/52 レプリカセット基礎 (5) Heartbeat: ノード間の死活監視 OPLOG: プライマリノードの操作をセカンダリにレプリケーション するために、操作を保存するコレクション 有限サイズのコレクション( Capped collection ) セカンダリが長時間停止していると溢れてレプリカセットが機 能不全を起こす
  33. 33. OSC 2014 Kansai@Kyoto 33/52 レプリカセット応用 (1) Arbiter: 投票権のみ持ち、データを持たないノード システム構成のコストを下げることが可能 ただし冗長性は下がる(トレードオフ) Primary Secondary Arbiter
  34. 34. OSC 2014 Kansai@Kyoto 34/52 レプリカセット応用 (2) Delayed Node: オペレーションミス対策 レプリケーションを意図的に遅らせたノード オペミスしてデータを失ったときにすぐに Delayed Node から巻き戻せば復帰可能 Primary Secondary Secondary Delayed Secondary 30 分遅れ slaveDelay=1800 priority=0 hidden=true
  35. 35. OSC 2014 Kansai@Kyoto 35/52 レプリカセット応用 (3) セカンダリノードに対するアクセス Write Concern データの書き込みがどこまで波及 するまで待つかを設定する値 基本は即座に戻る セカンダリノードの数も指定可 Read Prefence セカンダリノードからの読み込みを 許可してプライマリの負荷を下げる 古い値を掴んでも大丈夫なとき P S S j : 1 w : 2 P S S PRIMARY SECONDARY
  36. 36. OSC 2014 Kansai@Kyoto 36/52 レプリカセット応用 (4) Disaster Recovery (災害復旧)対策 データセンタをまたいでレプリカセットを構築することで、 DC がまるごと死んだとしてもサービス提供可能 Primary Secondary Secondary Secondary Secondary Arbiter Datacenter 1 Datacenter 2
  37. 37. OSC 2014 Kansai@Kyoto 37/52 レプリカセットの魅力 仕組み自体はとてもシンプル 高可用性を容易に実現できる 高いシステム構成の自由度 DR 対策やバックアップ対策などにも対応可能 水平展開、 DC をまたいだ運用が容易なクラウド時 代にふさわしい仕組み
  38. 38. OSC 2014 Kansai@Kyoto 38/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  39. 39. OSC 2014 Kansai@Kyoto 39/52 シャーディングとは sharding: 一般的なデータベース用語 DB 負荷を分散させるためにスケールアウトさせること RDBMS の場合、同時にアクセスする必要のあるデータ は一つのサーバで処理するように注意深く配置する 非常に難しい スケールアップ DBMS DBMS DBMS スケールアウト DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS
  40. 40. OSC 2014 Kansai@Kyoto 40/52 MongoDB のオートシャーディング MongoDB はスケールアウト(=シャーディング)で パフォーマンスを稼ぐ戦略 シャーディングを簡単に行う仕組みが組み込まれている =オートシャーディング
  41. 41. OSC 2014 Kansai@Kyoto 41/52 オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる naruhiko Shard key: username < 64MB akio rakutaro-∞ +∞ Shard 1 A Chunk < 64MB C ChunkChunk < 64MB B
  42. 42. OSC 2014 Kansai@Kyoto 42/52 オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる naruhiko Shard key: username < 64MB akio rakutaro-∞ +∞ Shard 1 A Chunk < 64MB C ChunkChunk < 64MB B db.foo.insert({username: "osamu", ....})
  43. 43. OSC 2014 Kansai@Kyoto 43/52 オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる naruhiko Shard key: username < 64MB akio rakutaro-∞ +∞ Shard 1 A Chunk < 64MB C ChunkChunk < 64MB B db.foo.insert({username: "osamu", ....}) naruhiko Shard key: username < 64MB akio rakutaro-∞ +∞ Shard 1 A B から 分割 < 64MB C < 64MB B osamu < 64MB D
  44. 44. OSC 2014 Kansai@Kyoto 44/52 オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する 新規にシャードを追加した場合も同様にリバランシング が起きる A Shard 1 Shard 2
  45. 45. OSC 2014 Kansai@Kyoto 45/52 オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する 新規にシャードを追加した場合も同様にリバランシング が起きる A Shard 1 Shard 2 A Shard 1 Shard 2 B
  46. 46. OSC 2014 Kansai@Kyoto 46/52 オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する 新規にシャードを追加した場合も同様にリバランシング が起きる A Shard 1 Shard 2 A Shard 1 Shard 2 B A Shard 1 Shard 2 B C
  47. 47. OSC 2014 Kansai@Kyoto 47/52 オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する 新規にシャードを追加した場合も同様にリバランシング が起きる A Shard 1 Shard 2 A Shard 1 Shard 2 B A Shard 1 Shard 2 B C A Shard 1 Shard 2 B C C
  48. 48. OSC 2014 Kansai@Kyoto 48/52 シャードキーに求められる性質 適度なランダムネス ある程度チャンク分割が進んだあとは、シャード内にまん べんなくチャンクが分配されるようになること シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配 置されること 適度なローカリティ あるひとまとまりの処理が数個のチャンク内で完結する シャーディングでは mmap がチャンク単位になるため、 うまくいくと各シャードでオンメモリで処理が可能になる
  49. 49. OSC 2014 Kansai@Kyoto 49/52 オートシャーディングは万能か? シャードキーをうまく選定できるか?が肝 シャードキーの選定ミスはパフォーマンスの劣化(と、場 合によっては OPLOG 溢れによるデータ喪失)を招く シャードキーは一度決めたら変更は不可能なので、パイ ロットプロジェクトなどで慎重にデータの性質を見極め る必要がある 最初から超大規模なデータを扱うことだけが分かって おり、データの性質が不明確な案件だとリスクがある
  50. 50. OSC 2014 Kansai@Kyoto 50/52 内容 MongoDB JP とは NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング まとめ
  51. 51. OSC 2014 Kansai@Kyoto 51/52 まとめ MongoDB はクラウド時代に必要な種々の要素を備 えた、 RDBMS を補完する優れた DB である ただし嵌まりパターンに使った場合 これは MongoDB に限らず NoSQL に共通 アプリケーションを開発しながらスキーマをデザイン していく動的スキーマ シンプルな仕組みで高可用性を実現し、なおかつさ まざまなバリエーションを作れるレプリカセット 同じマシンを並べてパフォーマンスを稼ぐ水平ス ケーリングを支援するオートシャーディング
  52. 52. OSC 2014 Kansai@Kyoto 52/52 参考図書 MongoDB イン・アクション http://www.amazon.co.jp/dp/4873115906 Kyle Banker ( 著 ), Sky 株式会社 玉川 竜司 ( 翻訳 ) オライリー・ジャパン データベースエンジニア養成読本 [DB を自由自在 に活用するための知識とノウハウ満載 !] http://www.amazon.co.jp/dp/4774158062 データベースエンジニア養成読本編集部 技術評論社

×