日本 oss 推進フォーラム mongodb 〜その性質と利用場面〜

日本 OSS 推進フォーラム

クラウド技術部会

MongoDB〜その性質と利用場面〜

2014年 2月 7日（金）

株式会社ミライト情報システムオープンソリューション技術本部

小笠原徳彦[email protected]

日本OSS推進フォーラムクラウド技術部会 2/61

内容

自己紹介

NoSQL と MongoDB

MongoDB の性質

ドキュメント指向

性能とインデックス

レプリカセット

オートシャーディング

レプリカセットによる可用性デモ

MongoDB の生きるケース、難しいケース


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








自己紹介

小笠原徳彦（株）ミライト情報システムオープンソリューション技術本部応用システム技術部所属

MongoDB 日本ユーザー会 MongoDB JP メンバー

MongoDB University Certified Engineer


ミライト情報システムについて

2012 年 7 月 1 日発足

「ミライト」は Mirai + IT の造語

IT と技術で作る未来の通信、未来の暮らし。

企業スローガン「 OPEN THE NEXT! 」

私たちは、オープンシステムでお客様の「次」を拓きます

ミライト・テクノロジーズ

株式会社ミライト情報システム

2012 年 7 月 1 日〜

2012 年 10 月 1 日〜

ミライト・ホールディングス


オープンソリューション技術本部

オープンスタンダード、オープンソースを活用して

低コストで高品位なソリューションを提供する

http://www.miraitsystems.jp/opensource/nosql.html

http://www.miraitsystems.jp/opensource/nosql.html


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








RDBMS と NoSQL(1)

RDBMS (Relational Database Management System)関係モデルに基づいたデータベース管理システム

SQL (Standard Query Language) による宣言的な操作オプティマイザにより「どうデータを格納し」「どうデータを得る」かは最適化されて高速に実行される

アトミックなデータ操作

データの一貫性保持が重要


RDBMS と NoSQL(2)しかしクラウド時代においては、データの一貫性保持はコストが高い……こともある

一貫性保持は常に必要なのか？例： EC サイトの在庫状況はリアルタイムでなくてもよい

決済時に一貫性が担保されていればよい

一貫性の完全な保持を諦めれば水平にスケールできる

DB

AppTokyo

US App

EU App EU AppDB

US AppDB

Tokyo AppDB


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


NoSQL の一つとしての MongoDB(1)ドキュメント指向データベース

バランスの良い NoSQL を目指す

https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144

スケ

ーラ

ビリ

ティ

＆パ

フォ

ーマ

ンス

機能の豊富さ

memcached

key/valuestore

MongoDB

RDBMS

https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144


MongoDB の強み


多彩なクエリー文字列としてのマッチ、範囲検索、正規表現など

論理演算で複数の条件の組み合わせも可

B-Tree インデックスによる検索・ソートも使える

ほぼオンメモリで動作するため非常に高速

{ "_id" : ObjectId("524406662caf1cab1f000001"), "title" : "MongoDB is fun!", "body" : "I love MongoDB very much.", "author" : "[email protected]", "created" : ISODate("2013-09-26T10:03:18.825Z"), "comment" : [ { "author" : "[email protected]", "content" : "I also love it!" } ]}


MongoDB の割り切り

トランザクションを持たない複数の操作をくるんで、途中で失敗したらロールバック……といった機能はない

一つ一つのデータ操作はアトミック

JOIN がない

複数のドキュメントを DB側で結合はできない

アプリケーションで結合する必要があるがアトミックな操作ではない

…… でも、なくても構わない状況は多いよね？　という割り切りがポイント


MongoDB/NoSQL と RDBMS

NoSQL とは一般に「使い方にクセがある」「どこか割り切ったことがある」「その代わりにとても得意なところがある」もの

事前に「不得意なところが許容できるか」を判断できないなら、素直に RDBMS を使ったほうが良い

速度

クエリーの種類

トランザクション

メモリ使用量

ディスク使用量

スケーラビリティ

0

50

100

RDBMS

MongoDB

このグラフは例であり

実際の評価ではありません


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








MongoDB = ドキュメント指向

RDBMS: 関係（表） MongoDB: ドキュメント

ID NAME EMAIL

1 Naruhiko Ogasawara

[email protected]

2 Ichiro Tanaka

[email protected]

3 Taro Yamada

[email protected]

Users

ID CONTENT A_ID

1 ぼくもお気に入り！ 2

2 使い所難しいですけどね。

3

... ... ...

Comments

ID ARTICLE_ID

COMMENT_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" : "[email protected]", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ " }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 " } ]}

↑JSON(JavaScript Object Notation)


DEMO: 文書挿入

mongo shell に接続して、 db test の collection fooに適当な値を突っ込みます

$ mongoMongoDB shell version: 2.4.6connecting to: test> use testswitched to db test> db.foo.find()> db.foo.insert({name: "Naruhiko Ogasawara", email : "[email protected]", city: "Sakura"})> db.foo.find(){ "_id" : ObjectId("52e20ebeb5b6beeb03b2074e"), "name" : "Naruhiko Ogasawara", "email" : "[email protected]", "city" : "Sakura" }

mailto:[email protected]


ドキュメント指向と動的スキーマ (1)

RDBMS: 表

各列の型は一致している必要あり

MongoDB: ドキュメント

それぞれの文書の構造は異なっていても構わない

検索その他では存在する部分だけが対象

ドキュメントの集まりを「コレクション」と呼ぶ

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ " }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 " }, ]}

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "created" : ISODate("2013-09-26T10:03:18.825Z"),}


ドキュメント指向と動的スキーマ (2)アプリケーションの設計の段階で、スキーマ定義を厳密に考えないでも大丈夫

すぐに開発に取り掛かれる

カジュアルにスキーマ定義を変更できる

スピード感のあるアプリ開発

パフォーマンスを得るにはスキーマに対する十分な理解が必要なので「スキーマレス」は厳密には NO

作りながらスキーマを定義していく

動的スキーマ


スキーマ定義の例：ブログ

大雑把な仕様記事が持つのはタイトル、内容、著者、記事が書かれた日時、コメント、 permalinkコメントが持つのは内容、著者

blog.example.com

もんごたん楽しい！by Naruhiko OgasawaraMongoDBいいですね！好きです！

2014/01/23 13:13comment (2)

ラーメン食べたいby Taro Yamadaなんだかラーメンな気分。どこかで食べていこうかな。

2014/01/22 20:13comment (2)

...

新着10 件

Click

blog.example.com/permalink

もんごたん楽しい！by Naruhiko OgasawaraMongoDBいいですね！好きです！

2014/01/23 13:13

ぼくもお気に入り！by Ichiro Tanaka

使い所難しいですけどね。by Taro Yamada コメ

ント


ブログのスキーマ例 (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" : "[email protected]", }{ "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "[email protected]", }{ "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "[email protected]", }

Collection: authors

{ "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : "ぼくもお気に入り！ ",}{ "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : "使い所難しいですけどね。 ",}

Collection: comments正規化のためにコレクションを分割● ちょっと煩雑● アプリケーション JOIN

が必要になる

正規化のためにコレクションを分割● ちょっと煩雑● アプリケーション JOIN

が必要になる


ブログのスキーマ例 (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" : "[email protected]", }{ "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "[email protected]", }{ "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "[email protected]", }

Collection: authors

動的スキーマの利点を用いる● 扱うコレクションが一個減ってスッ

キリした● アプリケーション JOIN が必要にな

る点は変わらない

動的スキーマの利点を用いる● 扱うコレクションが一個減ってスッ

キリした● アプリケーション JOIN が必要にな

る点は変わらない


ブログのスキーマ例 (3)いっそのこと全部埋め込んでしまおう！

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ ", }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 ", }, ]}

Collection: postsJSON においては配列の要素内には任意の JSON オブジェクトをとれるので、この中にコメントの情報を直接埋め込んでしまう（ embedded ）

● MongoDB の強力な文書操作機能により、配列内部にデータを押し込んでも柔軟に操作可能！

● あれ、 author 正規化しなくていいの？

● 考えてみれば、ユーザー名とかパスワードのたぐいはブログアプリ側でセッションで管理しているはずなので、 DB側でユニーク性を保証する必要はない！と割り切れる

● 迷ったら埋め込み文書、がMongoDB 的スキーマ設計

JSON においては配列の要素内には任意の JSON オブジェクトをとれるので、この中にコメントの情報を直接埋め込んでしまう（ embedded ）

● MongoDB の強力な文書操作機能により、配列内部にデータを押し込んでも柔軟に操作可能！

● あれ、 author 正規化しなくていいの？

● 考えてみれば、ユーザー名とかパスワードのたぐいはブログアプリ側でセッションで管理しているはずなので、 DB側でユニーク性を保証する必要はない！と割り切れる

● 迷ったら埋め込み文書、がMongoDB 的スキーマ設計


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








●MongoDB の性能の秘密

MongoDB はファイルシステムに展開されているコレクションを mmap している

ローカリティがある READ アクセスについてはオンメモリでアクセスするので高速

要は「ディスクにスワップアウトできるオンメモリ DB 」

逆に言うと全データアクセスをするような処理はpage in/out が多発するので性能が出ない

Storage

V. mem

P. mem


データアクセスとインデックス

MongoDB のデータアクセスはとても素朴

頭から順に舐めているだけ（線形探索）＝検索 O(n)ついでにいうとドキュメントの順序は保証されない

インデックス

あるキーに着目した B-Tree インデックス＝検索 O(log n)検索・ソートに利用可

Doc1 Doc2 Doc3 … DocNupdate Doc2 （サイズ拡大）

Doc1 Doc2Doc3 … DocN（隙間）


インデックス詳細

インデックスはコレクション自体と同じファイルどんどん張っているとデータサイズが肥大化する

インデックスを後から張るとデータ量に比例した時間がかかる（当然）

昇順・降順でインデックスは張れる

複数キーのインデックスも利用可能db.posts.ensureIndex({created_at:-1, author:1})部分的に使うことも可能

キーの存在はドキュメントによるが、それでもインデックスは張れる


インデックス _id の節約

先ほどのブログのスキーマを少し改良

{ "_id" : "mongo_tan_is_fun", "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ ", }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 ", }, ]}

Collection: posts_id は必ずインデックスが張られるので、メモリ・ストレージを余計に消費する● 文書作成時に指定しない場合は

自動的に生成される（ 12 バイトのバイト列）

● インデックスを張ったほうが良く、一意性が保証される値が別にあるなら、それを _id にするとよい

● ブログにおいては permalink は当然リンクとしてユニークなものだというアプリ要件があるから、これを_id にすると便利

_id は必ずインデックスが張られるので、メモリ・ストレージを余計に消費する● 文書作成時に指定しない場合は

自動的に生成される（ 12 バイトのバイト列）

● インデックスを張ったほうが良く、一意性が保証される値が別にあるなら、それを _id にするとよい

● ブログにおいては permalink は当然リンクとしてユニークなものだというアプリ要件があるから、これを_id にすると便利


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








レプリカセット基礎 (1)レプリカセット：簡単な仕組みで高可用性を実現

最低 3台のノードをセットにして動かす

アプリケーションに応答するプライマリノードは自動的に決定される（明示的なマスターノードは存在しない）

Secondary 1

Secondary 2Primary

Application

Driver

Read

Write

Heartbeat

Replication

Replication


レプリカセット基礎 (2)プライマリノードがダウンした場合残ったノード間で投票を行い次のプライマリを決める

この場合は「どこまでレプリケーションが終わっているか」で決まる

Secondary 1

Secondary 2Primary

Application

Driver

Heartbeat

ぼくは 5分前の処理まで

レプリカもらったよ

ぼくは 10分前までだなぁ


レプリカセット基礎 (3)選ばれたノードが次のプライマリになる

この時点でノードがダウンすると、 1台では投票ができないためレプリカセットがダウンする

1/3冗長

Primary

Secondary 2Primary

Application

Driver

Heartbeat

じゃあぼくがプライマリーやるね

ReplicationREAD

WRITE


レプリカセット基礎 (4)ダウンしていたノードが復活するとセカンダリノードに復帰

ただしダウンタイムが長いと自動復帰は不可

動いているセカンダリノードからリストアするのが無難

Primary

Secondary 2Secondary 2

Application

Driver

Heartbeat

ReplicationREAD

WRITE


レプリカセット基礎 (5)

Heartbeat:ノード間の死活監視

OPLOG:プライマリノードの操作をセカンダリにレプリケーションするために、操作を保存するコレクション

有限サイズのコレクション（ Capped collection ）セカンダリが長時間停止していると溢れてレプリカセットが機能不全を起こす


レプリカセット応用 (1)

Arbiter: 投票権のみ持ち、データを持たないノード

システム構成のコストを下げることが可能

ただし冗長性は下がる（トレードオフ）

Primary

Secondary Arbiter



Delayed Node: オペレーションミス対策

レプリケーションを意図的に遅らせたノード

オペミスしてデータを失ったときにすぐに Delayed Nodeから巻き戻せば復帰可能

Primary

Secondary Secondary DelayedSecondary

30分遅れ

slaveDelay=1800priority=0hidden=true


レプリカセット応用 (3)セカンダリノードに対するアクセス

Write Concernデータの書き込みがどこまで波及するまで待つかを設定する値

基本は即座に戻る

セカンダリノードの数も指定可

Read Prefenceセカンダリノードからの読み込みを許可してプライマリの負荷を下げる

レプリケーション前の値を掴んでも大丈夫なときに用いる

P

S S

j : 1w : 2

P

S S

PRIMARYSECONDARY



Disaster Recovery （災害復旧）対策

データセンタをまたいでレプリカセットを構築することで、DC がまるごと死んだとしてもサービス提供可能

Primary

Secondary Secondary Secondary

Secondary

Arbiter

Datacenter 1 Datacenter 2


レプリカセットの魅力

仕組み自体はとてもシンプル

高可用性を容易に実現できる

高いシステム構成の自由度

DR対策やバックアップ対策などにも対応可能

水平展開、 DC をまたいだ運用が容易なクラウド時代にふさわしい仕組み


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








シャーディングとは

sharding: 一般的なデータベース用語

DB負荷を分散させるためにスケールアウトさせること

RDBMS の場合、同時にアクセスする必要のあるデータは一つのサーバで処理するように注意深く配置する

非常に難しい

スケ

ール

アッ

プ

DBMS

DBMS

DBMS

スケールアウト

DBMS DBMS DBMS DBMS

DBMS

DBMS DBMS

DBMS DBMS


MongoDB のオートシャーディング

MongoDB はスケールアウト（＝シャーディング）でパフォーマンスを稼ぐ戦略

シャーディングを簡単に行う仕組みが組み込まれている

＝オートシャーディング


オートシャーディングの仕組み (1)シャードキー

オートシャーディングの動作を規定するキー（複合可）

シャードキーの範囲によってコレクションを塊（チャンク）に分割する

チャンクサイズは 64MB （標準）

DB の操作によりサイズ超過した場合は分割される

naruhiko

Shard key: username

< 64MBakio rakutaro-∞ +∞

Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B







naruhiko

Shard key: username


Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B

db.foo.insert({username: "osamu", ....})







naruhiko

Shard key: username


Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B

db.foo.insert({username: "osamu", ....})

naruhiko

Shard key: username


Shard 1A

B から分割

< 64MB

C

< 64MB

B

osamu< 64MB

D


オートシャーディングの仕組み (2)リバランシング各シャードにおいて、最大のチャンク数を持つシャードと最小のチャンク数を持つシャードの差が規定値を超えた場合、バランスを取るためチャンクが移動する

新規にシャードを追加した場合も同様にリバランシングが起きる

A

Shard 1 Shard 2




A

Shard 1 Shard 2A

Shard 1 Shard 2

B




A

Shard 1 Shard 2A

Shard 1 Shard 2

B

A

Shard 1 Shard 2

B

C




A

Shard 1 Shard 2A

Shard 1 Shard 2

B

A

Shard 1 Shard 2

B

C

A

Shard 1 Shard 2

B

C

C


シャードキーに求められる性質

適度なランダムネスある程度チャンク分割が進んだあとは、シャード内にまんべんなくチャンクが分配されるようになること

シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配置されること

適度なローカリティあるひとまとまりの処理が数個のチャンク内で完結する

シャーディングでは mmap がチャンク単位になるため、うまくいくと各シャードでオンメモリで処理が可能になる


オートシャーディングは万能か？

シャードキーをうまく選定できるか？が肝シャードキーの選定ミスはパフォーマンスの劣化（と、場合によっては OPLOG溢れによるデータ喪失）を招く

シャードキーは一度決めたら変更は不可能なので、パイロットプロジェクトなどで慎重にデータの性質を見極める必要がある

最初から超大規模なデータを扱うことだけが分かっており、データの性質が不明確な案件だとリスクがある


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








デモの内容

AWS に構築したレプリカセットに Ruby スクリプトからデータを投入

AWS上でプライマリノード A をダウンさせる

自動フェイルオーバで別のノード B がプライマリに昇格し、書き込みが継続することを確認

A を再度起動する

A がセカンダリノードとして復旧することを確認


内容

自己紹介

NoSQL と MongoDB

MongoDB の性質








MongoDB が生きるケース

アプリケーションを作りながらスキーマ設計やサイジング設計を行うことができるケース

ダウンタイムレスの可用性が求められ、そのための投資が許容されるケース

パブリッククラウドなどで、水平スケールが容易に可能なケース

アプリケーションサイドに

自由度を与えたいケース


MongoDB が難しいケース

一番最初にシステム構築、予算割り当てを明確に求められるケース

データの総量だけ分かっており、データの構造その他について情報が一切ないケース

処理能力に応じた水平スケールが難しいケース

事前見積もり・構築・運用について

制限が強いケース


MongoDB が難しいケース

一番最初にシステム構築、予算割り当てを明確に求められるケース

データの総量だけ分かっており、データの構造その他について情報が一切ないケース

処理能力に応じた水平スケールが難しいケース

事前見積もり・構築・運用について

制限が強いケース言い換えれば、 SIer 的案件では MongoDB は難しいところもある


まとめ

MongoDB はクラウド時代に必要な種々の要素を備えた、 RDBMS を補完する優れた DB である

ただし嵌まりパターンに使った場合

これは MongoDB に限らず NoSQL に共通

アプリケーションを開発しながらスキーマをデザインしていく動的スキーマ

シンプルな仕組みで高可用性を実現し、なおかつさまざまなバリエーションを作れるレプリカセット

同じマシンを並べてパフォーマンスを稼ぐ水平スケーリングを支援するオートシャーディング


参考図書

MongoDB イン・アクションhttp://www.amazon.co.jp/dp/4873115906

Kyle Banker (著 ), Sky 株式会社玉川竜司 (翻訳 )オライリー・ジャパン

データベースエンジニア養成読本 [DB を自由自在に活用するための知識とノウハウ満載 !] http://www.amazon.co.jp/dp/4774158062

データベースエンジニア養成読本編集部技術評論社

http://www.amazon.co.jp/dp/4873115906

http://www.amazon.co.jp/dp/4774158062


著作権とライセンス・免責事項

本スライドの著作者は（株）ミライト情報システムといたします。

本スライドはクリエイティブコモンズ表示継承 4.0国際ライセンスのもとに提供されています。http://creativecommons.org/licenses/by-sa/4.0/deed.ja

本スライドの内容は小笠原徳彦の個人的見解によるものであり、（株）ミライト情報システムその他所属組織などの見解を代表するものではありません。

http://creativecommons.org/licenses/by-sa/4.0/deed.ja



日本 oss 推進フォーラム mongodb 〜その性質と利用場面〜

Documents