SlideShare a Scribd company logo
1 of 52
Download to read offline
を知ろう
概要から動作原理まで

© CROOZ,Inc

1
アジェンダ
• mongoDBとは
• クラスタ構成概要
• 内部的動作原理

• その他の仕様と機能
• MySQLとのスピード比較
© CROOZ,Inc

2
特徴から説く

mongoDBとは

© CROOZ,Inc

3
mongoDB

オンメモリで動作する
スキーマフリーな
ドキュメンド指向
NOSQLデータベース。
© CROOZ,Inc

4
mongoDBの背景
• 2009年よりMongoDB社(元10gen)が提供。
• 累計調達資金2億3100万ドル。
• mongoDBのダウンロード数は500万回に達する。
• mongoDB技術者の求人数はredisやCassandraを抜いて
トップを君臨。
• キーワードの検索数はHTML5に次ぐ2番目に多い。
※一部情報はTechCrunchから引用
© CROOZ,Inc

5
MongoDBの特徴
• ドキュメンド指向
– レコードではなく、JSONオブジェクトが格納される。

• スキーマフリー
– 動的なスキーマ、リレーションの概念なし。

• Memory-Mapped File
– メモリ上で動作する前提の設計で高いパフォーマンスを叩き出す。

• レプリケーション、シャーディング構成
– クラスタ構成により、自動的なフェイルオーバー、シャーディングを
実現。

© CROOZ,Inc

6
ドキュメンド指向①

KVSではなくDB!
テーブルレベルまで、基本的な構造はRDBを踏襲。

RDB

mongoDB

Database (データベース)

Database (データベース)

Table (テーブル)

Collection (コレクション)

© CROOZ,Inc

7
ドキュメンド指向②
Profile collection:
{
name: “Alice”,
age: 20,
hobby: {
“outdoor”: [
“motorcycle”,
…
],
“indoor”: [
“reading”,
],
}
}

レコードの代わりに、JSONライクなオブジェクト
が格納される。
オブジェクトの構造は理解され、検索や参照に利
用できる。
この例でアウトドアの趣味にアクセスするときは、
hobby.outdoor
でアクセスできる。
こうしたサブオブジェクトやデータに対しイン
デックスの作成など、DBの機能がフルで利用でき
る。

NOTE:
内部的にはJSONがBSONというJSONのバイナリ版が格納され、
パフォーマンスの向上と容量削減に貢献している。

© CROOZ,Inc

8
スキーマフリー①

• 動的なスキーマデザイン
–
–
–
–

レコードのようにテーブルごとにカラムが決まることはない。
同じコレクションにあるドキュメンドの構造が違ってでも可。
更新ごとにドキュメンドの構造を変更できる。
create系APIが存在しない。

• リレーションの概念なし
– 集約出来る情報は関連テーブルに分散するのではなく、同じドキュメ
ンドのサブドキュメンドとして集約する。
– どうしても分割管理したい場合(例:マスター)はDBRefというドキュメ
ンド間のハイパーリンクを利用する。

© CROOZ,Inc

9
スキーマフリー②
RDBでのタグシステムの実装例

books
book_id
book_title

•
•

book_tag_m
ap
tag_id
book_id

book_tags
tag_id
tag_text

bookとtagに関連する操作は3つのテーブルを舐める必要がある。
ランダムアクセスは最低でも3回発生する。

© CROOZ,Inc

10
スキーマフリー③
MongoDBでのタグシステムの実装例
Books collection:
{
_id: 1,
title: “MongoDB”,
tags: [“10gen”, “database”, “open-source”],
…
}

•
•
•
•

tagsはbookのドキュメンドの一要素として格納。
tags配列に対してインデックスを作成し、検索に利用できる。
book自身のtagを参照する場合検索は必要ない。
同一ドキュメンドのためディスク上では連続なので、ランダムアクセスは1回。

© CROOZ,Inc

11
Memory-Mapped File

• Mongoではディスク上のリソースをMemory-Mapped
Fileの仕組みを利用して、メモリ上にマッピングする。
• クライアントは通常メモリ上のデータを操作する。

• Memcacheなどのメモリキャッシュシステムの機能を原
理的に併せ持つ。
NOTE:詳細は後述

© CROOZ,Inc

12
MongoDBとは②
上述の特徴を踏まえて、Mongoの運用思想とは。

Table
Table

ORマッピン
グ

オブジェクト

Memcach
e

Table

RDBMSではデータの集約、整形を経て、プログラムが扱いやすい形にし上で、
キャッシュシステムに格納しクライアントに提供する。
Mongoの設計思想でははじめからプログラムと親和性の高いオブジェクトをそのまま格
納する。メモリ上で動作するという特徴上、キャッシュシステムも基本的には必要ない。

© CROOZ,Inc

13
レプリケーションとシャーディング

クラスタ構成

© CROOZ,Inc

14
クラスタ構成
• Mongoではレプリケーション、シャーディングの機能をそれぞれ提
供している。
• レプリケーション構成において、一般的な条件下では障害からの自
動フェイルオーバーが可能。
• シャーディング構成において、自動バランシング機能を備え、動的
にノードの追加や除去に対応。

• 両者を組み合わせることで負荷分散された冗長構成のクラスタが出
来上がる。
• クライアントからはクラスタ全体を一つの論理DBにみなすことが
できる。
© CROOZ,Inc

15
クラスタ構成図

Mongos
Server

Config
Servers

プライマリサーバー (Primary)
セカンダリサーバー (Secondary)
Data Servers

仲裁サーバー (Arbiter)
メタデータ―サーバー (Config)
ルーティングサーバー (Mongos)
Replica Set

© CROOZ,Inc

Replica Set

16
クラスタ構成要素
• primaryサーバ―
–
–

アクセスを一手に受けて、セカンダリに同期していく。
フェイルオーバー時はセカンダリサーバーの中から投票によって選ばれる。

• secondaryサーバ―
–
–

•

arbiterサーバー
–
–

•

データを保持しないので同期もしないが、レプリカセット全体の同期状況を追跡していく。
障害時に保持している同期状況で投票するために存在する。

configサーバー
–
–

•

デフォルトではデータに対して参照を含めアクセス不可。
フェイルオーバー時は投票によって最も同期が進んでると判断すれば、プライマリになる。

シャーディング構成の構成情報やシャード状況を保持する。
構成が変更された時に、情報の提供と周知を担当する。

mongosサーバー
–
–
–
–

© CROOZ,Inc

クライアントにとっての窓口で、シャーディング構成のルーターのようなサーバー。
接続時にconfigサーバーにシャーディング構成を問い合わせてキャッシュし、
この情報を手掛かりにデータをルーティングしていく。
Mongosサーバーはバックエンドを持たないただのプロセス。

17
レプリケーションと自動フェイルオーバー
同期
同期

primary

•
•
•

secondary

一つのレプリケーション構成はレプリカセットと呼ぶ。
レプリカセットは一つのprimaryと複数のsecondaryで構成される。
クライアントが操作できるのはprimaryのみで、primaryからoplogというオペレーションログで
secondaryに同期していく。

同期

障害

primary

•
•
•

secondary

primary

secondary

primaryが障害の場合、secondaryの中から投票で新しいprimaryが選ばれる。
障害発生したprimaryが復帰後はsecondaryとして新primaryから同期を受ける。
oplog内にスタックされたオペレーションで最新まで同期できない場合、自動フェイルオーバー
は失敗となって、手動フォローが必要になる。

© CROOZ,Inc

18
Primary選挙と過半数票
レプリカセットのprimaryが障害した場合、レプリカセット内の残りの構成要素がそれぞれ同期が進
んでいると判断したsecondaryに投票する。
障害要素を含む全構成要素の過半数票を獲得したsecondaryが晴れて新しいprimaryになる。

同期

primary

secondary

上記primary、secondary各1の構成では、primary障害後残りのsecondaryが自分自身の1票しかもら
えず、1票より多い票数(過半数票)を獲得できず、primary選抜が失敗し自動フェイルオーバーも失敗
となる。
複数のsecondaryを用意し対処しても、障害サーバーの数が合計数の半分になった時点で、同様に残
りのサーバーが過半数票を獲得できない。
同期

primary

監視

secondary

arbiter

この現象を解決するのがarbiterサーバー。
レプリカセット内の同期状況を監視し、障害時は投票するだけの人。
原理的に負荷やトラフィックが小さい。
© CROOZ,Inc

19
優先読み込み(ReadPreference)
レプリカセットに対して参照リクエスト投げるとき、参照先をある程
度指定することができる。
• プライマリ
– すべての読み込みはプライマリに対して行う。(default)

• プライマリ優先
– プライマリが接続不可などの状況でのみセカンダリを選択する。

• セカンダリ
– 全セカンダリ中ping返答が15ms秒以内のメンバーからランダムに選択する。

• セカンダリ優先
– 「セカンダリ」で使えるメンバーがなかった場合にのみプライマリを選択する。

• 最も近い
– Ping返答が一番近いメンバーを選択。メンバーの種類は気にしない。

• タグセット絞込み
– 上記中「プライマリ」以外、タグセットで候補の選択範囲を絞る事ができる。
© CROOZ,Inc

20
レプリケーションまとめ

• Primary, Secondary, Arbiterサーバーで構成する。
• データサーバーの数に応じてArbiterを用意し無駄をなす。
• 障害時は自動的にシステムの可動性を維持する。
• システム動作状態での復旧が可能。
• レプリカセットに対する読み込み先は細かく制御できる。

© CROOZ,Inc

21
シャーディングの概要

• シャードは全自動で行われる。シャードアルゴリズムの
変更やカスタマイズは不可。
• システム動作状態でのシャード構成の変更が可能。

• 基本的にアプリケーションレベルでシャードを意識する
必要がない。

© CROOZ,Inc

22
シャーディングの仕組み
mongos
{key: 150}

Primary shard
chunk0
chunk3

•
•
•
•
•

0 ~ 100
301 ~

Shard

Shard
chunk
1

101 ~ 200

chunk
2

201 ~ 301

データはドキュメンド単位ではなく、chunkというデータの箱単位でシャー
ドされる。
インデックス作成と同じ要領でコレクション別のシャードキーを作成。こ
のキーは変更不可。
シャードキーに対してはRangeBasedPaginationのアルゴリズムでchunkに
分割し、このchunkを各シャードに分散する。
振り分けられないデータは全部プライマリシャードサーバーでに行く。
プライマリシャードはコレクション別でシステムが勝手に割り振る。

© CROOZ,Inc

23
Chunckの分割と移動
mongos

Primary shard
chunk
0
chunk
3
chunk
4
chunk
5

•
•
•
•

0 ~ 100
301 ~ 400

Shard

Shard
chunk
1

101 ~ 200

chunk
2

201 ~ 301

401 ~ 500
501 ~

大きくなりすぎたchunkは分割される。
Chunkが特定のサーバーに偏った場合は移動される。
Chunkの移動と分割はパフォーマンスに与えるインパクトは大きい。
Chunkの移動や分割中には一部リクエストは正しい情報を返せなくなる。
(count等)

© CROOZ,Inc

24
シャーディングの偏り対策
• ランダム性のあるデータをシャードキーにする。
• 複合キーをシャードキーにする。
• Chunkを事前に分割しておく。
• Chunkのサイズを小さく設定する。
• 定期的に手動でchunkを作成、分割してやる。
• Hashベースのシャードキーを利用する。
© CROOZ,Inc

25
Hashベースシャードキー

シャーディングのために作られた特殊なインデックス。
• 利点:
– シャードのアルゴリズムにあわせているので、非常にうまい具
合に分散される。
– 自動で事前chunk分割してくれる。

• 欠点:
– 複合キーは利用不可。ピンポイント検索では不利。

© CROOZ,Inc

26
シャーディング構成要素の障害時の挙動
• configサーバー障害
– 一部障害の場合
• configサーバーのメタデータが読み取り専用になる。
• DBに対する通常操作、mongosの立ち上げができるが、シャーディング構成
の変更やChunkの移動や分割ができなくなる。
• データの大量インサードがあった場合、偏ったシャーディング結果になる
か、インサード失敗になる。

– 全部障害の場合
• 一部障害の挙動に加え、mongosの追加や再起動ができなくなる。(精確に
は立ち上げ後落ちる)
• 一部シャーディング構成状態を確認するコマンドが利用できなくなる。

• Mongosサーバー障害
– 単一mongosの障害はシステム自体にインパクトを与えない。
– クライアントにとってはシングルポイントになるため、プロセスの自動再起動
や、接続先切り替えの仕組みで回避できる。
© CROOZ,Inc

27
シャーディングのまとめ

• 全自動なため、アプリケーションで面倒を見る必要がな
い。
• シャード構成にのみ存在する問題や仕様がいろいろある
ので、ある程度意識してリクエストを投げる必要がある。
• 適切なシャードキーの選択が肝、慣れるまでチューニン
グで苦労する可能性大。

© CROOZ,Inc

28
クラスタの物理構成例
とりあえず、クラスタ構成要素の特徴をまとめよう。

• Primary, Secondaryサーバー
– 高負荷、高ディスクIO、高トラフィック。
– 実運用レベルではすべて物理サーバーが無難。

• Arbiterサーバー
– 低負荷、低ディスクIO、低トラフィック。
– データサーバーと分けていれば相乗り可。

• Configサーバー
– 低負荷、低ディスクIO、低トラフィック。
– config同士が分けていれば相乗り可だが。

• Mongosサーバー
– 低負荷?、ディスクIOなし、高トラフィック。
– トラフィックが気にしなければどこでもいい。
© CROOZ,Inc

29
クラスタ内でケチる構成

Arbiter1
Config1

Config2
Mongos

•
•
•
•
•

Shard1

Arbiter2

Mongos

Shard1

Shard2
Shard2
Config3

メインのデータサーバーはそれぞれ物理サーバーを用意。
残り負荷の低いサーバーは一プロセスごとまとめて物理サーバーを用意。
Arbiterサーバーは複数プロセス相乗りでも可。
あまり勧めないが、Configをデータサーバーに相乗りさせても可。
基本的にArbiter, Config, Mongosが一プロセスずつ同時に止まっても、シス
テムに直ちに影響を与えない。

© CROOZ,Inc

30
クラスタ外でケチる構成
AppServer
AppServer
AppServer
Mongos
Mongos
Mongos

SomeServer
Arbiter1
Config1

AppServer

Mongos

•
•
•

Arbiter2

Shard1

Shard2

Shard2

SomeServer

Config1

Shard1

Config2

mongosはAppサーバーに置いて、localhostから接続する。
その他の低負荷サーバーは一プロセスずつ適当なサーバーに相乗りさせる。
Appサーバーに余裕が有る場合、mongos以外の低負荷プロセスに相乗りさ
せても可。

© CROOZ,Inc

31
mmap()を利用した実装とジャーナリング

内部的な動作原理

© CROOZ,Inc

32
内部的動作原理
Mongoのコアはmmap()で実装している。
60秒ごとの更新
ディスク

•
•
•
•

メモリ

マッピング

Mongoプロセス起動時にディスクにあるリソースを全部仮想メモリにマッ
ピングする。
マッピング時点ではデータはメモリに乗らない。
一旦マッピングするとOSの機能でメモリとディスクが関連付けられて、メ
モリへの更新は任意のタイミングでディスクにフラッシュできる。
Mongoではデフォルトで60秒ごとディスクにフラッシュする。

© CROOZ,Inc

33
Memory-Mapped Fileから見るMongoの特性
• 利点:
– 通常はメモリ上で動作するため、動作が早い。(特に書き込み)
– よく利用するデータは自然と物理メモリに来るので、メモリ
キャッシュシステムのような役割もこなす。
– 大量な書き込みでも相対的にディスクIOが小さい。

• 欠点:
– 32bitシステムでは使いものにならない。
– 仮想メモリ扱いなので、ページアウトが発生する。(page fault)
– Mongoがアクティブに動く環境では他のプロセスをガンガンス
ワップアウトさせてしまう。
– 永続化は60秒ごとの更新なので、最悪60秒のデータが飛ぶ。

• 結論:
– メモリをいっぱい積みましょう!
© CROOZ,Inc

34
ジャーナリングシステム概要

消える60秒間のデータのために!

• 単一プロセスの対障害能力を向上する目的で作られたシ
ステム。
• 先行書き込みログの仕組みでパフォーマンスを維持しな
がら実現。

© CROOZ,Inc

35
ジャーナリングシステムの動作原理①
ディスク

メモリ
60sごとの更新

DB Data

Shared
View

Memory-Mapped File

map
100msごとの書き込み
Journaling
File

•
•
•

Write OP

Private
View

DBのデータはSharedViewというビューにマッピングされた後、
SharedViewをPrivateViewに第二のマッピングを行う。
リクエストに対しライトオペレーションはSharedViewではなくPrivateView
に送られ、書き込み終了後SharedViewに反映する。
100msごとにPrivateViewに送られたライトオペレーションだけをディスク
のジャーナリングファイルに書き込む。

© CROOZ,Inc

36
ジャーナリングシステムの動作原理②
ディスク

メモリ
データをフラッシュ

DB Data

Shared
View

Memory-Mapped File

remap

Journaling
File

•
•
•
•

Private
View

障害復帰後、JournalingFileからSharedView宛にライトオペレーションを再
生し、メモリ上のデータを復旧させる。
SharedViewからディスクに最新データをフラッシュする。
SharedViewからPrivateViewに最新データをにリマップする。
これで復旧完了、リクエストを受け付ける。

© CROOZ,Inc

37
クラスタ構成でのジャーナリング
Mongoではレプリケーション構成でもジャーナリングの利
用を推奨している。理由は以下:
• レプリケーション全体の障害に対応できる。
• より素早く確実なリカバリが出来る。
• 障害後はmongoプロセスを単純に再起動することで対応
できる。

© CROOZ,Inc

38
ジャーナリングシステムのまとめ
• 利点:
– 障害耐性向上。最大60sのデータロスが100msにできる。
– レプリケーション構成での自動フェイルオーバー能力向上。
– 永続性保証書き込みの敷居が下がる。(詳細後述)

• 欠点:
– 同じビューがメモリ上2つ存在するため、メモリ消費量が倍!
– 一回の更新で2回のメモリ操作が発生する。
– ジャーナリングファイル書き込み分のディスクIOが発生する。

• 結論:
– 特別な理由がなければ利用した方がいい。

© CROOZ,Inc

39
特徴的な仕様とその他の機能を紹介

その他の仕様と機能

© CROOZ,Inc

40
特徴的な仕様①: Fire-and-Forgetの精神

• 書き込みリクエストに対し、mongoは実際のディスク書
き込みを確認しない。
• この仕様でメモリ動作の優位性を保ち高いパフォーマン
スを維持する。
• ディスク書き込みを保証してほしい場合、多くのドライ
バはfsyncパラメータをサポートする。

© CROOZ,Inc

41
特徴的な仕様②: fsync
• Mongoではfsyncは管理コマンド。メモリをディスクに
直ちにフラッシュさせる。
• 各言語のドライバでは書き込み系APIのオプション。
– 指定すると該当オペレーションのディスク書き込みを保証する。
– ただし、ジャーナリングありとなしで挙動が違う。
– ジャーナリングなし:
• メモリへの書き込み後、直ちにディスク書き込みが行われる

– ジャーナリングあり:
• メモリへの書き込み後、ジャーナリングファイル書き出しの最大
100ms間隔を待つ。

– ジャーナリングありではより低負荷で永続保証書き込みできる。
– でも、用法用量を守って正しく使うべき。
© CROOZ,Inc

42
特徴的な仕様②: 書き込み確認(WriteConcern)
送り出したリクエストが心配で心配で仕方ない方に
• Fire-And-Forgetの精神をより細かくコントロールするための機能が
書き込み確認。
• リクエストに対しどの段階まで成功とみなすかを表すリクエストの
オプション。
• 主な確認レベル:
–
–
–
–
–

© CROOZ,Inc

{w:-1} 完全に確認なし。
{w: 0} インフラレベルのエラー(ネットワークやMongoの死活など)のみ確認。
{w: 1} SharedViewへの書き込みを確認。不正データなどが検出できる。(default)
{w:$n} ($n>1) レプリカセット内で$n個のノードへの書き込みを確認。
{w:$tags} $tagsで指定した特定のレプリカセットへの書き込みを確認。

43
その他の機能
• MapReduce
– ビッグ・データの解析機能をデフォルトで搭載。

• 固定長コレクション(Capped)
– サイズやドキュメンド数が予め決まった特殊なコレクション。
– 挿入に対して非常に高いパフォーマンスを持つ。
– シャードできない。

• 二次元地理空間インデックス
– 2D座標インデックスによる距離的な検索ができる。
– 平面モデルと球面モデルをサポート。
– このインデックスはシャードキーに指定できない。

© CROOZ,Inc

44
参考程度に

MYSQLとのスピード比較

© CROOZ,Inc

45
MySQLとのスピード比較
パフォーマンスのスケール感をつかむために、
簡単にMySQLとベンチを取ってみた。
•

マシーンはその辺にあるノートPC。

•

MySQLはデフォルト状態。MongoDBはシャード構成上にシャードしない
コレクションを作成し利用。

•

両方PHPドライバを利用。

•

比較用の値は平均値。

•

書き込み系でメモリベースは20万回計測、ディスクベースは1万回計測。

•

Selectは20万件中ランダム1件を1万回計測。

•

適当なベンチなため、参考程度。

© CROOZ,Inc

46
MySQLとのスピード比較

Insert

Update

Select(key
)

Select

Delete

MongoDB

0.00024

0.00044

0.00014

0.03283

0.00068

MySQL

0.03839

0.04059

0.00009

0.03236

0.04127

• 書き込み系のスピードが圧倒的であることがわかる。

• Selectではインデックスなしは同じ程度、インデックスありは遅い
結果となり、おそらく搭載メモリ量の影響でしょう。

© CROOZ,Inc

47
書き込み確認別の比較

w:1

fsync

Journaling

0.00024

0.04499

noJournaling

0.00020

0.10565

• デフォルト設定でもジャーナリングがもたらすパフォーマンス低下
が思ったより小さい。
• ジャーナルあり状態のfsyncは仕組み上比較的に早い。

© CROOZ,Inc

48
導入側の観点から

まとめ

© CROOZ,Inc

49
管理者の観点から

• クラスタ構成の完成度が高いため、大きなシステムでも
相対的に構築、運営しやすい。
• 真新しいシステムなので、当然相応の導入コストがかか
る。
• シャーディング関連のノウハウが蓄積されるまで苦労す
る可能性大。

© CROOZ,Inc

50
開発者の観点から
• 早い。
• レプリケーションとシャーディングはアプリレベルで面
倒を見る必要がない。
• データが取り回しやすくなり、実装が単純になる。
• スキーマの設計思想がまるっきり違うので、発想の転換
が必要。

• シャーディングでは実装レベルで注意すべきことが多い。
© CROOZ,Inc

51
使ってみましょう!

© CROOZ,Inc

52

More Related Content

What's hot

PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~Miki Shimogai
 
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけRDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけRecruit Technologies
 
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説MongoDB Configパラメータ解説
MongoDB Configパラメータ解説Shoken Fujisaki
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersSeiya Mizuno
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!kwatch
 
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsugJava ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsugMasatoshi Tada
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
MongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDBMongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDBippei_suzuki
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことAmazon Web Services Japan
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報Masahiko Sawada
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例Akihiro Kuwano
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話Koichiro Matsuoka
 
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話Shohei Kobayashi
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話Yuta Shimada
 
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜Masakazu Matsushita
 

What's hot (20)

PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
 
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけRDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
 
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説MongoDB Configパラメータ解説
MongoDB Configパラメータ解説
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!
 
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsugJava ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
MongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDBMongoDB概要:金融業界でのMongoDB
MongoDB概要:金融業界でのMongoDB
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
AmebaのMongoDB活用事例
AmebaのMongoDB活用事例AmebaのMongoDB活用事例
AmebaのMongoDB活用事例
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
RDBNoSQLの基礎と組み合わせDB構成をちょっとよくする話
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
 
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
 

Similar to Mongo dbを知ろう

Mongo db勉強会の補足
Mongo db勉強会の補足Mongo db勉強会の補足
Mongo db勉強会の補足CROOZ, inc.
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?Hiroaki Kubota
 
Mongo dbを知ろう devlove関西
Mongo dbを知ろう   devlove関西Mongo dbを知ろう   devlove関西
Mongo dbを知ろう devlove関西Ryuji Tamagawa
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~じゅん なかざ
 
Casual Compression on MongoDB
Casual Compression on MongoDBCasual Compression on MongoDB
Casual Compression on MongoDBmoai kids
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門じゅん なかざ
 
mongoDB: OSC Tokyo2010 spring
mongoDB: OSC Tokyo2010 springmongoDB: OSC Tokyo2010 spring
mongoDB: OSC Tokyo2010 springichikaway
 
Osc2012.dbに行ってきました
Osc2012.dbに行ってきましたOsc2012.dbに行ってきました
Osc2012.dbに行ってきましたMasaru Kobashigawa
 
20140924 mt cloud_handson_seminar
20140924 mt cloud_handson_seminar20140924 mt cloud_handson_seminar
20140924 mt cloud_handson_seminarSix Apart
 
比べてみよう リレーショナル vs ドキュメント.pptx
比べてみよう リレーショナル vs ドキュメント.pptx比べてみよう リレーショナル vs ドキュメント.pptx
比べてみよう リレーショナル vs ドキュメント.pptxMariMurotani
 
データベース勉強会 In 広島 mongodb
データベース勉強会 In 広島  mongodbデータベース勉強会 In 広島  mongodb
データベース勉強会 In 広島 mongodbRyuji Tamagawa
 
小規模アプリ開発者が中から見るモンスターストライク
小規模アプリ開発者が中から見るモンスターストライク小規模アプリ開発者が中から見るモンスターストライク
小規模アプリ開発者が中から見るモンスターストライクyoshiteru kawamata
 
MongoDBCSharp
MongoDBCSharpMongoDBCSharp
MongoDBCSharpytanno
 
Db tech showcase2015
Db tech showcase2015Db tech showcase2015
Db tech showcase2015emin_press
 
Db tech showcase2015 how to replicate between clusters
Db tech showcase2015 how to replicate between clustersDb tech showcase2015 how to replicate between clusters
Db tech showcase2015 how to replicate between clustersHiroaki Kubota
 

Similar to Mongo dbを知ろう (20)

Mongo db勉強会の補足
Mongo db勉強会の補足Mongo db勉強会の補足
Mongo db勉強会の補足
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
 
Mongo dbを知ろう devlove関西
Mongo dbを知ろう   devlove関西Mongo dbを知ろう   devlove関西
Mongo dbを知ろう devlove関西
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
 
MongoDB勉強会資料
MongoDB勉強会資料MongoDB勉強会資料
MongoDB勉強会資料
 
Casual Compression on MongoDB
Casual Compression on MongoDBCasual Compression on MongoDB
Casual Compression on MongoDB
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
 
Mongo db world 2018
Mongo db world 2018Mongo db world 2018
Mongo db world 2018
 
mongoDB: OSC Tokyo2010 spring
mongoDB: OSC Tokyo2010 springmongoDB: OSC Tokyo2010 spring
mongoDB: OSC Tokyo2010 spring
 
Osc2012.dbに行ってきました
Osc2012.dbに行ってきましたOsc2012.dbに行ってきました
Osc2012.dbに行ってきました
 
Mongoざっくり紹介
Mongoざっくり紹介Mongoざっくり紹介
Mongoざっくり紹介
 
20140924 mt cloud_handson_seminar
20140924 mt cloud_handson_seminar20140924 mt cloud_handson_seminar
20140924 mt cloud_handson_seminar
 
比べてみよう リレーショナル vs ドキュメント.pptx
比べてみよう リレーショナル vs ドキュメント.pptx比べてみよう リレーショナル vs ドキュメント.pptx
比べてみよう リレーショナル vs ドキュメント.pptx
 
データベース勉強会 In 広島 mongodb
データベース勉強会 In 広島  mongodbデータベース勉強会 In 広島  mongodb
データベース勉強会 In 広島 mongodb
 
小規模アプリ開発者が中から見るモンスターストライク
小規模アプリ開発者が中から見るモンスターストライク小規模アプリ開発者が中から見るモンスターストライク
小規模アプリ開発者が中から見るモンスターストライク
 
Ceilometer苦労話
Ceilometer苦労話Ceilometer苦労話
Ceilometer苦労話
 
MongoDBCSharp
MongoDBCSharpMongoDBCSharp
MongoDBCSharp
 
Db tech showcase2015
Db tech showcase2015Db tech showcase2015
Db tech showcase2015
 
Db tech showcase2015 how to replicate between clusters
Db tech showcase2015 how to replicate between clustersDb tech showcase2015 how to replicate between clusters
Db tech showcase2015 how to replicate between clusters
 
初めてのMongo db
初めてのMongo db初めてのMongo db
初めてのMongo db
 

More from CROOZ, inc.

CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料CROOZ, inc.
 
【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料CROOZ, inc.
 
【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料CROOZ, inc.
 
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察するモバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察するCROOZ, inc.
 
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築についてCROOZ, inc.
 
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築CROOZ, inc.
 
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料CROOZ, inc.
 
リソースディレクトリの管理
リソースディレクトリの管理リソースディレクトリの管理
リソースディレクトリの管理CROOZ, inc.
 
楽しいGit外部公開用
楽しいGit外部公開用楽しいGit外部公開用
楽しいGit外部公開用CROOZ, inc.
 
Git extensions ws外部公開用
Git extensions ws外部公開用Git extensions ws外部公開用
Git extensions ws外部公開用CROOZ, inc.
 
Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用CROOZ, inc.
 
MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用CROOZ, inc.
 
怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用CROOZ, inc.
 
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02CROOZ, inc.
 
MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09CROOZ, inc.
 

More from CROOZ, inc. (15)

CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
 
【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料
 
【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料
 
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察するモバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
 
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
 
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
 
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
 
リソースディレクトリの管理
リソースディレクトリの管理リソースディレクトリの管理
リソースディレクトリの管理
 
楽しいGit外部公開用
楽しいGit外部公開用楽しいGit外部公開用
楽しいGit外部公開用
 
Git extensions ws外部公開用
Git extensions ws外部公開用Git extensions ws外部公開用
Git extensions ws外部公開用
 
Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用
 
MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用
 
怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用
 
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02
 
MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09
 

Mongo dbを知ろう