MongoDBの特徴的な機能である、インデクスについてのウェビナーの日本語翻訳。 MongoDBの性能を最適なする手法として、インデクスは重要な役割を担っています。

1. システム可用性を拡張するイン
デクス戦略
鈴木いっぺい
MongoDB, Inc.

2. アジェンダ
• インデクスとは何か？
• インデクスの基本
• 評価／チューニング
• 地理空間情報機能(Geospacial)
• テキスト検索
• スケーリング

3. インデクスとは何か?

4. インデクスとは何か?
料理の本から特定の料理を、そのレシピの名前
から探そうとした時、索引からレシピを探すの
が最も早い。

5. 索引（インデクス）を利用

6. 連結リスト
1 2 3 4 5 6 7

7. 連結リストを使ってアイテム7を探す
1 2 3 4 5 6 7

8. ツリー構造からアイテム7を探す
1
2
3
4
7
6
5

9. MongoDB内のインデクスはB-Treesによっ
て構造化

10. Query, Insert, Delete処理

11. インデクスはMongoDBの性
能チューニングにとって最も
重要な要素

12. インデクスの基本

13. インデクスの基本
• データベース性能を決める最大要素
13
– インデクスの効果はシステムデザインの初期からレビュー
が必要
– 冗長なインデクス設定を避ける事
// authorのインデクス(abc順)
>db.articles.ensureIndex( { author : 1 } )
– .
// authorのインデクス(abcとは逆順)
>db.articles.ensureIndex( { author : -1 } )
// 複数要素の配列のインデクス– マルチキーインデクス
>db.articles.ensureIndex( { tags : 1 } )

14. サブドキュメント(Sub-document)
インデクス
• サブドキュメントでのインデクス
14
– ドット表記を使用
{
‘_id’ : ObjectId(..),
‘article_id’ : ObjectId(..),
‘section’ : ‘schema’,
‘date’ : ISODate(..),
‘daily’: { ‘views’ : 45,
‘comments’ : 150 }
‘hours’ : {
0 : { ‘views’ : 10 },
1 : { ‘views’ : 2 },
…
23 : { ‘views’ : 14,
‘comments’ : 10 }
}
}
>db.interactions.ensureIndex(
{ “daily.comments” : 1}
}
>db.interactions.find(
{“daily.comments” : { $gte : 150} } ,
{ _id:0, “daily.comments” : 1 }
)

15. 複合(Compound)インデクス
• 複数の要素をもつインデクス
15
//コンソールで表示
> db.articles.ensureIndex( { author : 1, tags : 1 } )
> db.articles.find( { author : ‘Joe D’, tags : ‘MongoDB’} )
//さらに次も可能
> db.articles.find( { author : ‘Joe D’ } )
// Author単一のインデックス指定は必要なし
> db.articles.ensureIndex( { author : 1 } )

16. ソート処理の順序
• 単一インデクスの場合はソートは単純
16
– B-Treeのいずれからも検索可能
• { attribute: 1 } もしくは{ attribute: -1 }
• 複合インデクスの場合はソート順序が重要
– 作者(author)で検索し、日付でソートをしたい場合
// 作者(author)は名前順、日付は新しい日付を先にソートしてインデックする
>db.articles.ensureIndex( { ‘author’ : 1, ‘date’ -1 } )

17. カバード(Covered)もしくはインデクスのみ
のクエリー
• 参照データはインデクスから戻ってくる
17
– データベースファイルはアクセスしない
– 性能の大幅な向上
– Compoundインデクスでも使用可能
• プロジェクション(projection)で指定
> db.users.ensureIndex( { user : 1, password :1 } )
> db.user.find({ user:”joe” },
{ _id:0, password:1 }
)
参考: プロジェクションを使ってクライアントに戻すデータを減らす事も考慮せよ
(_id=0  Object_id を参照しない)

18. オプション
18
• ユニーク度の制限(unique, dropDups)
// authorのインデクスはユニークである必要（一つしか存在しない）
>db.articles.ensureIndex( { ‘author’ : 1}, { unique : true } )
• スパース(Sparce) インデクス
// likesのフィールドを持たないドキュメントが複数あっても良い
>db.articles.ensureIndex( { ‘author’ : 1, ‘likes’ : 1}, { sparse: true } )
* 抜けているフィールドはインデクス内でnull として記録

19. バックグラウンドでのインデクス生成
• インデクス生成は長時間かかる事も多い
• この生成をバックグラウンドに指定する事により他の
オプレーションに対する影響を最小限に
• バックグラウンドで複数のインデクスの生成も可能
• レプリカセットから一旦外したセカンダリーでインデク
スを生成
19
// バックグラウンドでのインデクス生成
> db.articles.ensureIndex(
{ ‘author’ : 1, ‘date’ -1 },
{background : true}
)

20. Explain planコマンド
• インデクスとオペレーションの分析を行う際に使用
20
– どのインデクスが使用されたかを確認
– どれくらいのドキュメント/オブジェクトがスキャンされたかを
確認
– コンソール経由、もしくはコードで表示
//コンソールで結果を表示する
> db.articles.find({author:’Joe D'}).explain()

21. Explain planコマンドの出力(インデクス
無し)
21
{
"cursor" : ”BasicCursor",
"isMultiKey" : false,
"n" : 12,
"nscannedObjects" : 25820,
"nscanned" : 25820,
…
"indexOnly" : false,
…
"millis" : 27,
…
}
他のタイプ:
• BasicCursor
• コレクション全体スキャン
（インデクス使用せず）
• BtreeCursor
• GeoSearchCursor
• Complex Plan
• TextCursor

22. Explain planコマンドの出力
22
{
"cursor" : "BtreeCursor author_1_date_-
1",
"isMultiKey" : false,
"n" : 12,
"nscannedObjects" : 12,
"nscanned" : 12,
…
"indexOnly" : false,
…
"millis" : 0,
…
}
他のタイプ:
• BasicCursor
• コレクション全体スキャン
• BtreeCursor
• GeoSearchCursor
• Complex Plan
• TextCursor

23. データベースプロファイラー
• 遅いクエリー処理の発見
23
– すべてを表示する事もオプション指定可能
– デフォルトは100ms以上の処理の表示
//プロファイラの結果をコンソールに表示, 0=オフ1=遅い処理のみ2=すべて
> db.setProfilingLevel(1, 100)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
//プロファイル結果の表示
> show profile
//もしくは次の方法でも可能
>db.system.profile.find().pretty()

24. クエリーの最適化
• 各クエリーに対して、MongoDBは定期的に有効なイ
ンデクスをすべて使う。
• 最適なプランを発見次第、他のインデクスの使用を
中止
• 選択されたプランは、一時的にキャッシュされ、他の
タイプのクエリーにも適用される（1000回分使用され
る）
• MongoDB 2.6はクエリー処理に複数のインデクスの
組み合わせ(intersection)をサポート
24

25. 他のインデクスタイプ
25
• 地理空間(Geospatial)インデクス(２次元球体）
• テキストインデクス
• TTLコレクション(期限付き条件)
• シャーディング向けのハッシュインデクス

26. 地理空間(Geo Spatial)インデクス

27. 2次元球体
• 地理空間上の位置情報をインデクス化
27
– GeoJSON オブジェクトを使用
– 球体の上での２次元位置情報
//GeoJSON インデクスのためのオブジェクト構造
{
name: ’MongoDB Palo Alto’,
location: { type : “Point”,
coordinates: [ 37.449157 , -122.158574 ] }
}
// GeoJSONオブジェクトのインデクス化
>db.articles.ensureIndex( { location: “2dsphere” } )
サポートされるGeoJSON オ
ブジェクト:
Point（点）
LineString（線）
Polygon（ポリゴン）
MultiPoint（複数点）
MultiLineString（複数線）
MultiPolygon（複数ポリゴン）
GeometryCollection (位置情
報コレクション）

28. 記事情報の拡張機能
• 記事(article)が投稿さ
28
れた位置情報を記録す
る
• 位置情報はブラウザー
から
Articles コレクション
>db.articles.insert({
'text': 'Article
content…’,
'date' : ISODate(...),
'title' : ’Intro to
MongoDB’,
'author' : ’Joe D’,
'tags' : ['mongodb',
'database',
'nosql’],
‘location’ : {
‘type’ : ‘Point’,
‘coordinates’ :
[37.449, -122.158]
}
});
//位置情報を取得するJavascript機能.
navigator.geolocation.getCurrentPosition();
//GeoJSONデータ構造に変換する必要あり

29. 例
29
– 指定した座標値に”近い”場所を検索する
>db.articles.find( {
location: { $near :
{ $geometry :
{ type : "Point”, coordinates : [37.449, -122.158] } },
$maxDistance : 5000
}
} )

30. テキスト検索

31. テキストインデクス
• テキストインデクスを使用してコレクション内のド
31
キュメントの中にある文字列検索を行う
• テキストインデクスは任意の文字情報、もしくは
文字情報の配列でも可
• テキストインデクスを利用した検索の際には、
$text オペレータを使用

32. テキスト検索
• コレクション一つに対し
32
て一つのテキストイン
デクス
• $** オペレータを使い、
コレクション内の文字列
をインデクス化
• “weights”を使って文
字列の重要度を指定
>db.articles.ensureIndex(
{title: ”text”, content: ”text”}
)
>db.articles.ensureIndex(
{ "$**" : “text”,
name : “MyTextIndex”} )
>db.articles.ensureIndex(
{ "$**" : "text”},
{ weights :
{ ”title" : 10, ”content" : 5},
name : ”MyTextIndex” }
)
オペレータ
$text, $search, $language,
$meta

33. 検索
• $text と$search オペレータを使ってクエリー処理
• Cursorが戻ってくる
• $meta を使って結果のスコアを求める
33
// Articlesコレクション内を検索
> db.articles.find ({$text: { $search: ”MongoDB" }})
– .
> db.articles.find(
{ $text: { $search: "MongoDB" }},
{ score: { $meta: "textScore" }, _id:0, title:1 } )
{ "title" : "Intro to MongoDB", "score" : 0.75 }

34. スケーリング

35. ワーキングセットが物理メモリを超える

36. いつスケールすべきか？
• 特定のリソースがマシン、もしくはレプリカ
セット上でのボトルネックになった場合
• RAM
• ディスクI/O
• ストレージ
• コンカレンシー(Concurrency)

37. 垂直スケール(スケールアップ)

38. 水平スケール(スケールアウト)

39. シャーディング
• ユーザがシャードキーを選択
• シャードキーはデータレンジを定義
• シャードキーに従ってデータはシャード毎にパ
ティションされる

40. スケーラビリティ
40
自動シャーディング
シャード１ シャード２ シャード３ シャードN
水平スケール
• キャパシティを自由に拡張
• コモディティサーバやクラウドアーキテクチャに最適
• 容易な運用とコストの明確化がメリット