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 very basic (Japanese) / MongoDB基礎の基礎

3,101 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 データベースエンジニア養成読本編集部 技術評論社

×