噂のMongoDB
その用途は?
About me
{
名前:
会社:
肩書:
趣味:
悩み:

窪田博昭
Cookpad.Inc
  MongoDBJP代表
Golf,フットサル
30代は体が・・・

twitter:@crumbjp
github: github.com/crumbjp
}
We're hiring !!
-5 -
-6 -
-7 -
-8 -
-9 -
-10 -
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
-13 -
DB tech showcase: 噂のMongoDBその用途は?
NoSQL全般

 RDBMSから機能を削り
 スループットや並列性を確保している

 比較的低機能ではあるが一点豪華主義で
 部分的にRDBMSを凌駕する機能を持つ

 大抵は速度重視
-16 -
MongoDBの特徴
1. スキーマレス
  2. 高機能Index
  3. 高速
  4. 並列性(& automatic failover)
 
・耐障害性
 
・スケーラビリティー
  5.トランザクション無し
   ・代わりのAtomic処理
  6.JOIN無し
Index

-18 -
MongoDBのIndex
商品名
ボールペン

タグ

値段

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

    食料品で200以下の商品を取得
MongoDBのIndex
商品名

タグ

値段

ボールペン

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

商品・テーブル
CREATE TABLE 商品 (
  id INT PRIMARY,
  商品名 VARCHAR(100)
);
タグ・テーブル
CREATE TABLE タグ (
  商品id INT,
  タグ名 VARCHAR(100),
  値段 INT,
 KEY(タグ名,値段)
);

食料品で200以下の商品
商品投入
■RDBMS
INSERT INTO 商品 VALUES (1,'ボールペン');
INSERT INTO タグ VALUES (1,'日用品',198),
   (1,'筆記用具',198);
 苦手な処理
     :
クエリー
 ・Index用のテーブルを
SELECT * FROM
 商品 INNER JOIN タグ
  ON タグ.商品id = 商品.id
  別途用意しJOIN
WHERE タグ名 = '食料品'
AND 値段 <= 200;
 値段が重複管理で筋が悪い。。
MongoDBのIndex
商品名

タグ

値段

ボールペン

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

商品投入
db.商品.save({
 '商品名' : 'ボールペン',
 'タグ': ['日用品', '筆記用具'],
 '値段':198 }
);
       :
       :

食料品で200以下の商品を取得
インデックス
■MongoDB
db.商品.ensureIndex({
 'タグ':1, '値段':1
});
  データ形式、Index共に
クエリー
  完全にサポート!
db.商品.find({
  タグ構造にもってこい!!

 'タグ':'食料品',
 '値段': { $lte : 200 }
});
MongoDBのIndex
商品名
ボールペン

タグ

値段

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

    食料品で果物の商品を取得
MongoDBのIndex
商品名

タグ

値段

ボールペン

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

食料品で果物の商品
■RDBMS
 SQLでの表現は困難
  self join する?

クエリー(2タグ限定版)
SELECT
 *
FROM
 タグ a
 INNER JOIN
 タグ b
 ON
  a.商品id = b.商品id
  AND
  a.タグ名 != b.タグ名
 INNER JOIN 商品 c
 ON
  a.商品id = c.id
WHERE
 a.タグ名 = '食料品'
 AND
 b.タグ名 = '果物'
GROUP BY
 a.商品id;
MongoDBのIndex
商品名

タグ

値段

ボールペン

日用品, 筆記用具

198

包丁

日用品, 刃物, キッチン

2980

バナナ

食料品, 果物

348

ほうれん草

食料品, 野菜

98

牛乳

食料品,

148

食料品で果物の商品
■MongoDB
 $all が使える
  今の実装では最初の
  要素のみIndex scan

クエリー
db.商品.find({
 'タグ': { $all : ['食料品', '果物']}
});
MongoDBのIndex
 主なIndex
 ・配列へのIndex(tag)
 ・複合Index
 ・平面/球面座標Index
 ・図形Index(交点,内包,近傍など各種検索)
  ・円, 線, 多角形, etc
 covered indexesも搭載
 NoSQLの弱点を多機能なIndexで補う戦略
高スループット

-26 -
MongoDBのスループット
計測条件

・3 core 3GB memory
  ・構文解析込み(SQL, JS)
  ・lo経由通信 (localhost)
int(11)
  ・1レコード、4kb程度 id int(11) PRI
value0
value1 int(11)
  ・1,000,000 レコード value2 int(11)
value3 varchar(50)
value4 varchar(50)
    = 4GB
value5 varchar(50)
value6 varchar(50)
value7 varchar(255)
  ・11 column
value8 int(11)
value9 text
  ・MySQLはInnoDB      
MongoDBのスループット
Insert
・MySQL
: 345 sec (5m 45s)
 ・MongoDB : 123 sec (2m 03s)
 ・(MyIsam ) : 240 sec (4m 00s)
MongoDBのスループット
 Range fetch (10,000件 x 100)
SELECT
・MySQL
: 202 sec
*
FROM
 ・MongoDB : 3.7 sec
mytbl
WHERE
id BETWEEN 0 AND 9999;

 Range count (10,000件 x 100)
・MySQL
: 37 sec
SELECT
COUNT(*)
 ・MongoDB : 0.4 sec
FROM
mytbl
     
WHERE

id BETWEEN 0 AND 9999;
MongoDBのスループット
 MongoDB 範囲検索は特に速い!
  ・B-tree実装が良い
 Countが速い!
  ・カーソルの両端を先に見る
Read >>> Write
な
WEBシステムに最適
     
並列性

-31 -
MongoDBの並列性
 MongoDBは2つのスケールアウト方式
  が用意されている
 ・Replica-set(ミラーリング)
Read系の並列化、対障害性
 ・Sharding(パーティショニング)
   Write系の並列化、大量データ対策
Replica-set

-33 -
replica-set
Primary:
書き込み可能ノード
Secondary:  読み取り専用ノード
全てのノードは同じデータを持っている

Primary
同期

Secondary Secondary Secondary Secondary
-34 -
replica-set
Primary:
書き込み可能ノード
Secondary:  読み取り専用ノード
Primaryが死んでも自動Failover

Primary

Primary
昇格

同期

Secondary Secondary Secondary Secondary
-35 -
replica-set
Primary:
書き込み可能ノード
Secondary:  読み取り専用ノード
自動Failoverではsplit brainが怖いのでvotingで対策
(以下の例では4/5 で当選)

Primary

Primary
投票

Secondary Secondary Secondary Secondary
-36 -
replica-set
www.mongodb.jp
httpd
PHP

mongo A

mongo B

mongod
secondary

mongod
primary

replica-set
replica-set
www.mongodb.jp

www.mongodb.jp

httpd

httpd

PHP

PHP

mongo A

mongo B

mongo C

mongod
secondary

mongod
primary

mongod
secondary

replica-set
Sharding

-39 -
Sharding
mongos:クエリーゲートウェイ
      mapping情報に基づき振り分ける
config: mapping情報を保持

key = 'abc'

key = 'xyz'

mongos

config
config
config

key => replicaset map
a.. ~ hz.. => Replica-set1
ia.. ~ rc.. => Replica-set2
rd..~ z.. => Replica-set3

Replica-set1 Replica-set2 Replica-set3
-40 -
Sharding
 RDBMSのパーティショニングと同じ発想
 複数のReplica-setを束ねるイメージ
 並列性や冗長性はReplica-setに任せる
 Shardingキーの選択さえ適切ならば
 Auto migrationでデータを適度に分散
 
 詳細はコチラ

Sharding
MongoDBの並列性
 Read負荷が高いならReplica-set
  MongoDBは元々高速なので殆どの問題は
  Secondaryを増やせば解決する
 Write負荷やデータ量の問題はSharding
  Write負荷 :非時系列のShard-key
  データ量 :時系列Shard-key
        (扱いやすいから)
トランザクションが無い

-44 -
MongoDBの排他
 Webシステムでは、殆どの場合
  トランザクションを使わない。使えない。
 HTTPはstatelessなプロトコルで
 statefulなトランザクションと相性が悪い。
  掛けたまま帰っちゃう!
  いつ戻って来るのか?
  もう来ないのか?
    不明!!
MongoDBの排他
 とはいえ、ある程度の排他処理は必要
 NoSQLでは楽観ロックが主流
  並列化を目指すと悲観ロックは機能しない
 
 memcached の CASが有名
  (Check and Set)
MongoDBの排他
CAS
 1. aがデータAをget
A (cas=1)
 

memcached
A (cas=1)
MongoDBの排他
CAS
 1. aがデータAをget
A (cas=1)
 2. ほぼ同時にbがデータAをget
  A (cas=1)
  楽観ロックなので
取れて良い

memcached
A (cas=1)
MongoDBの排他
CAS
 1. aがデータAをget
A (cas=1)
 2. ほぼ同時にbがデータAをget
  A (cas=1)
 3. aがデータAを更新
 

A' (cas=1)

memcached
cas値が一致する
ので更新成功

A (cas=1)

A' (cas=2)
MongoDBの排他
CAS
 1. aがデータAをget
 2. ほぼ同時にbがデータAをget
  A (cas=1)
 3. aがデータAを更新
 4. bがデータAを更新
A''(cas=1)

memcached

A' (cas=2)
cas値が不一致で
更新失敗
atomic操作

-51 -
atomic操作
 MongoDBにはCASが無い
  もっと強力なatomic操作がある
 特に便利なatomic操作
 $inc
  フィールドをインクリメントする
 $setOnInsert
  upsertの際、insert時だけ値を設定する
簡易CAS
GET
data1 = db.myData.findOne({
_id : 'FOO'
});

PUT
db.myData.update({
_id: data1._id,
 cas: data1.cas
},{
$inc : { cas : 1 },
$set { field1 : 'updated' }
});

CASの実装は簡単
 ・update時に常にcas値を1つ増加させる。
 ・update時のクエリにドキュメントのcas値を使えば
  衝突した際にはcas値が合わずupdateが失敗する

-53 -
atomic操作
 配列系のatomic操作
 $pop / $pullAll / $pull
  配列フィールドから値を削除
 $pushAll / $push
  配列フィールドに値を追加
 capped array
  配列フィールドに値を追加する際
   任意の配列長に保つよう切り捨てる機能
findAndModify

-55 -
atomic操作

 MongoDBにはfindAndModifyがある
 findAndModify
  atomicにデータ取得と更新が出来る
  ≒ SELECT ~ FOR UPDATE
   +UPDATE
   +COMMIT or ROLLBACK
簡易MQ
インデックス
db.myMQ.ensureIndex({
tm: 1
});
投入(アプリ)側
db.myMQ.save({
 tm: 0,
 Jobデータ
});

ワーカー側
db.myMQ.findAndModify({
query: {
tm : 0 },
 update: { $set : {
tm : 1
}}
});

tm = 0 のドキュメントを拾うと同時にtm = 1 に更新してしまう。
他のワーカに拾われないという寸法!
-57 -
簡易Jobスケジューラ
インデックス
db.myMQ.ensureIndex({
tm:1
});
投入(アプリ)側
db.myMQ.save({
 tm: Number(ISODate())+3600,
 Jobデータ
});

ワーカー側
db.myMQ.findAndModify({
query: {
tm : { $lte :Number(ISODate())}},
 update: { $set : {
tm : Number.MAX_VALUE
}}
});

tm に時刻(3600秒後)を入れれば、狙った時間にFireできる。
$inc : 3600の様にすれば定期的なJobにも出来る。
結構自由自在!
-58 -
簡易MapReduce
■単純なJobキュー

■MapReduce

-59 -
Monmoちゃん

-60 -
Monmoちゃん

 findAndModifyを上手く使って
  MapReduce環境を作ってみた。
 V8 が優秀で思ったより使える!
 
 MongoDB 以外何も要らない
  (ロジックはDBの外で動作)
ついでに

-62 -
MapReduce
MongoDB付属のMapReduceは危険
Primaryで処理が走る

●

『DBでロジックが走る』ってどうなの?
並列化が出来ない

●

NaN等で下手打つとDBが死ぬ

●

原則noscriptが基本!!
-63 -
Joinが出来ない

-64 -
Join
あきらめよう・・・

-65 -
MongoDB
何に使おう?
-66 -
まとめ
 ・Readが非常に高速
 ・多機能なIndex
 ・高い並列性(&対障害性)
 ・高い拡張性
  WEBシステムのバックエンドDBに最適
   DBキャッシュ層を省略し
   システムを簡略化できる
まとめ
 ・多機能なIndex
   配列Index(タグそのもの)
  タグ機能
   DB自体に機能があるので
   特別なコードが必要ない
まとめ
 ・多機能なIndex
   geohash
:2次元座標Index
   3dsphere :球面座標Index
  地図機能
近隣の施設検索などがDBで完結
まとめ
 ・強力なAtomic操作機能
 ・対障害性
  MQなど非同期系のバックエンドにも良い
   システム間のセマフォ的な使い方ができる
   非Javaへの親和性も貴重
  
最後に地雷の話

-71 -
地雷の話
 ■必須オプション
  ・notablescan
  ・noscript

 ■難易度が高い機能
  ・Sharding

 ■地雷機能
  ・MapReduce
  ・Aggregate
  ・Textサーチ
  ・Background indexing

 ■チューニングポイント
  ・oplog
  ・migration (Sharding)
  ・コネクション数
地雷の話
 確かにMongoDBには幾つか地雷がある
  (そして踏み易い)
 巷にあるネガティブな情報は
  地雷の爆発した跡 
 
 正しい使い方をすれば機能的にも性能的にも
  非常に優秀なプロダクト
おしまい
 

有難う御座いました。

More Related Content

PDF
Db tech showcase2015 how to replicate between clusters
PDF
MongoDB〜その性質と利用場面〜
PPTX
がっつりMongoDB事例紹介
PDF
RDB経験者に送るMongoDBの勘所(db tech showcase tokyo 2013)
PPTX
初心者向けMongoDBのキホン!
PDF
Introduction to MongoDB
PDF
初めてのMongo db
Db tech showcase2015 how to replicate between clusters
MongoDB〜その性質と利用場面〜
がっつりMongoDB事例紹介
RDB経験者に送るMongoDBの勘所(db tech showcase tokyo 2013)
初心者向けMongoDBのキホン!
Introduction to MongoDB
初めてのMongo db

What's hot (20)

PDF
MongoDBざっくり解説
PPTX
MongoDB World 2014に行ってきた!
PDF
後悔しないもんごもんごの使い方 〜アプリ編〜
PPTX
Mongo dbを知ろう
PDF
Case study to use MongoDB in middle-class SIer / (中規模) SIerだってMongoDBできたよ!
PPTX
MongoDBの監視
PDF
MongoDB very basic (Japanese) / MongoDB基礎の基礎
PPTX
Mongo db勉強会の補足
PPTX
MongoDBが遅いときの切り分け方法
PPT
ザ・ドキュメント~うまくいかないNoSQL~
PPTX
日本語:Mongo dbに於けるシャーディングについて
PPTX
Node.js×mongo dbで3年間サービス運用してみた話
PDF
ソーシャルゲームにおけるMongoDB適用事例 - Animal Land
PDF
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
PDF
NoSQLデータベースと位置情報
PPTX
MongoDB3.2の紹介
ODP
Mongo dbを半年ちょっと運用してみた
PDF
MongoDBのはじめての運用テキスト
PPTX
MongoDB on EC2 #mongodbcasual
PDF
MongoDBのアレをアレする
MongoDBざっくり解説
MongoDB World 2014に行ってきた!
後悔しないもんごもんごの使い方 〜アプリ編〜
Mongo dbを知ろう
Case study to use MongoDB in middle-class SIer / (中規模) SIerだってMongoDBできたよ!
MongoDBの監視
MongoDB very basic (Japanese) / MongoDB基礎の基礎
Mongo db勉強会の補足
MongoDBが遅いときの切り分け方法
ザ・ドキュメント~うまくいかないNoSQL~
日本語:Mongo dbに於けるシャーディングについて
Node.js×mongo dbで3年間サービス運用してみた話
ソーシャルゲームにおけるMongoDB適用事例 - Animal Land
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
NoSQLデータベースと位置情報
MongoDB3.2の紹介
Mongo dbを半年ちょっと運用してみた
MongoDBのはじめての運用テキスト
MongoDB on EC2 #mongodbcasual
MongoDBのアレをアレする
Ad

Similar to DB tech showcase: 噂のMongoDBその用途は? (20)

PPT
Mongodb
PDF
Mongodb 紹介
PDF
はじめてのMongoDB
PPTX
PHPとMongoDBで学ぶ次世代データストア
ODP
Mongo db勉強会
PDF
mongodbの簡易ストレージ化
PDF
20120831 mongoid
PDF
2019年度 若手技術者向け講座 NoSQL
PDF
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
PDF
データベース勉強会 In 広島 mongodb
PDF
MongoDB勉強会資料
PDF
ソーシャルゲームにおけるAWS/MongoDB利用事例
PDF
Mongo dbを知ろう devlove関西
PPTX
MongoDB: システム可用性を拡張するインデクス戦略
DOC
20110301 Mongo Tokyo
DOC
20110302 Mongo Tokyo
PDF
MongoDBの使い方
PPT
mongoDB: OSC Tokyo2010 spring
PPTX
比べてみよう リレーショナル vs ドキュメント.pptx
PDF
StepInNosql
Mongodb
Mongodb 紹介
はじめてのMongoDB
PHPとMongoDBで学ぶ次世代データストア
Mongo db勉強会
mongodbの簡易ストレージ化
20120831 mongoid
2019年度 若手技術者向け講座 NoSQL
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
データベース勉強会 In 広島 mongodb
MongoDB勉強会資料
ソーシャルゲームにおけるAWS/MongoDB利用事例
Mongo dbを知ろう devlove関西
MongoDB: システム可用性を拡張するインデクス戦略
20110301 Mongo Tokyo
20110302 Mongo Tokyo
MongoDBの使い方
mongoDB: OSC Tokyo2010 spring
比べてみよう リレーショナル vs ドキュメント.pptx
StepInNosql
Ad

More from Hiroaki Kubota (9)

PDF
MongoDBで自然言語処理
PDF
MongoDBJP 納涼もんご祭り
PDF
Why mincore() returns different value of stat ?
PDF
Mongo ghostsync and slaveDelay (Japanease)
PDF
Mongo ghostsync and slaveDelay
PDF
C10K on Mongo's sharding
PPT
Cockatoo
PPT
MongoTokyo
PPT
Albatross
MongoDBで自然言語処理
MongoDBJP 納涼もんご祭り
Why mincore() returns different value of stat ?
Mongo ghostsync and slaveDelay (Japanease)
Mongo ghostsync and slaveDelay
C10K on Mongo's sharding
Cockatoo
MongoTokyo
Albatross

Recently uploaded (9)

PPTX
生成AIとモデルベース開発:実はとても相性が良いことを説明します。まあそうだろうなと思われる方はご覧ください。
PPTX
Cosense - 整えずして完全勝利!Cosenseが他のwikiツールと違う理由
PPTX
Vibe Codingを触って感じた現実について.pptx .
PDF
Geminiの出力崩壊 本レポートは、Googleの大規模言語モデル「Gemini 2.5」が、特定の画像と短文入力に対して、誤った地名を推定し、最終的に...
PDF
R-SCoRe: Revisiting Scene Coordinate Regression for Robust Large-Scale Visual...
PDF
Yamaha DT200WR Real Enduro ENGINE CYLINDER TRANSMISSION
PDF
20250826_Devinで切り拓く沖縄ITの未来_AI駆動開発勉強会 沖縄支部 第2回
PDF
20250823_IoTLT_vol126_kitazaki_v1___.pdf
PDF
ココロ分解帳|感情をやさしく分解し自分と他者を理解するためのモバイルノートアプリ
生成AIとモデルベース開発:実はとても相性が良いことを説明します。まあそうだろうなと思われる方はご覧ください。
Cosense - 整えずして完全勝利!Cosenseが他のwikiツールと違う理由
Vibe Codingを触って感じた現実について.pptx .
Geminiの出力崩壊 本レポートは、Googleの大規模言語モデル「Gemini 2.5」が、特定の画像と短文入力に対して、誤った地名を推定し、最終的に...
R-SCoRe: Revisiting Scene Coordinate Regression for Robust Large-Scale Visual...
Yamaha DT200WR Real Enduro ENGINE CYLINDER TRANSMISSION
20250826_Devinで切り拓く沖縄ITの未来_AI駆動開発勉強会 沖縄支部 第2回
20250823_IoTLT_vol126_kitazaki_v1___.pdf
ココロ分解帳|感情をやさしく分解し自分と他者を理解するためのモバイルノートアプリ

DB tech showcase: 噂のMongoDBその用途は?