MongoDBを導入する前に検討した7つのこと · 2. 伝統的なビジネスインテリジェンス(bi) 伝統的なビジネスインテリジェンス(BI) • MongoDBはバッチ処理が不可能でこそないですが，リアルタイム処理のほうが得意

1

NRIオープンソースソリューションセンター Copyright© Nomura Research Institute, Ltd. All rights reserved.

MongoDBを導入する前に検討した7つのこと

OSSCセミナー@丸の内

株式会社野村総合研究所 OpenStandia 藤崎祥見

2


自己紹介

• 藤崎祥見（フジサキショウケン）

• 研究室でLinuxを使用したことをきっかけにオープンソースに興味を持ち、Debian/Ubuntuのコミュニティで活動を始め、Ubuntu 5.04 の翻訳に関わる。

• 2008年野村総合研究所（NRI）入社 OpenStandiaへ配属。以後、オープンソースを使用したシステム開発に携わる。

• 2009年オープンソースであるLiferayの日本コミュニティ、日本Liferayユーザグループを共同設立。

• 2012年 MongoDBの翻訳に関わる。

• 丸の内MongoDB勉強会やってます。次回は第6回 2013年1月23日開催

• 技術評論社 gihyo.jpで連載しています。「MongoDBでゆるふわDB体験」 http://gihyo.jp/dev/serial/01/mongodb

http://gihyo.jp/dev/serial/01/mongodb

3


• OSSの運用・構築をワンストップでサポート

• 対象OSSは50種類

• MongoDBのサポートも準備中、お問い合わせください

• http://openstandia.jp/

NRI OpenStandia

http://openstandia.jp/

4


丸の内mongodb

丸の内MongoDB勉強会

• 一ヶ月に1回開催、次回で6回目

• 特徴

• 無料

• ハンズオン式

• 過去の資料は全てGithubで公開. http://github.com/syokenz/marunouchi-mongodb

http://github.com/syokenz/marunouchi-mongodb




5


• テーマ第1回 – 第5回

• #1. SQLと比較して学ぶMongoDBクエリ

• #2. みんなでシャーディングしてみよう

• #3. “v2.2 の新機能” と ”レプリケーションハンズオン”

• #4. “REST I/Fを使ったサンプルアプリ” と“設定ファイル全解説”

• #5. “ソースコードリーディング”と“カスタムビルド”

• 次回以降

• GridFS, 地理空間インデックス, パフォーマンスチューニング, 事例紹介など

丸の内MongoDB勉強会

6


目次

１．NoSQLとMongoDB

２．MongoDBを導入する前に検討した7つのこと

３．事例紹介：Hybrid MySQL and MongoDB

４．まとめ

7




４．まとめ


8


• 「No! SQL」ではなく、「Not only SQL」

• RDBが得意なことはRDBで、得意でないことは無理にRDBにこだわらず、用途に合ったデータストアを使おう、というのが最近のコンセンサス

• 競合関係ではなく、補完関係という考え方が浸透してきている

• RDBの強み

• トランザクションによってデータの一貫性を保証できる

• 正規化を前提としているため、更新時のコストが小さい

• JOINや複雑な検索条件での検索が可能

• RDBが得意ではないこと

• 大量データの書き込み/更新処理（特にindexがあるテーブル）

• 更新系のスケールアウト

• DR（ディザスタリカバリ）対応

RDBが得意でないことを、NoSQLで補完する

Not only SQL

9


• Web 1.0

• 通信回数は1回

• DB性能はスケールアップで対応

• データは1つのデータセンター内で完結

• Strong Consistency（強い一貫性）は必須

データストアに求められるものが変わってきている

• Web 2.0

• AJAXを利用した複数通信、随時通信

• DB性能はスケールアウトで対応

• データは複数拠点のデータセンターに配置

• Eventual Consistency（結果整合性）という考え方

• 軽い大量のRead/Write処理できること

• ノード数に比例したスケーラビリティ

• DR対応可能なこと

• Consistencyは柔軟に、システムによってはEventualで良い

NoSQLへの流れ

10


• NoSQLと呼ばれている代表的なものは大きく分けて３つに分類される

出所: http://openstandia.jp/oss_info/mongodb/

NoSQLの種類

11


• KVS（Key-Value ストア）

• 最も一般的なNoSQL。データをkeyとvalueの形で持つ。

• 基本的にはkeyでの完全一致検索でしかデータを取得できない制限があるが、高速に動作する。

• シンプルな方式なので気軽に使用することが可能。

• Valueを条件とした検索、KeyでのLike検索はできない。

• 代表的なプロダクト

• Memcashed, Redis, Tokyo Tyrant, ROMA,

Infinispan(JBoss Cache) key value

app2020120420 ‘www.xxx.com’

app2020120421 ‘ [552.9565,N,1401]’

app2020120423 {Javaオブジェクト}

KeyとValueしか無く、Keyでの完全一致でしかデータを取得できない。

代表的なNoSQL：KVS

12


• ドキュメント指向データベース

• スキーマを定義しなくても使用できるスキーマレスである。

• ドキュメント内でネストが可能。

• 複雑な検索条件でデータを取得することが可能。

• 一部の機能はRDBライクに使用することができる。

• MongoDB, CouchDB

MongoDBの例。ドキュメント内でのネストが可能。

{ "_id" : ObjectId("4f769ba675c676"), "created_info" : { “owner” : “本田”, “date" : 2012/07/07, “grope”:{ “id”:10, “name”:”営業本部” } }, "title" : "test title", "body" : "test body", }

代表的なNoSQL：ドキュメント指向データベース

13


• 列指向データベース

• RDBMSのような行単位では無く、列単位での処理に特化している。

• 全行に対する特定列の一括更新や、指定した範囲の大量行に対する複数列の取得に向いている。

• 強力なスケーラビリティを備えており、データが増えても処理速度がそれほど低下しない。

• RDBのデータストアとは考え方が大きく異なっているので、扱いが難しい。

• Cassandra, HBase

Hbaseの例。Column単位で処理を行う。

代表的なNoSQL：列指向データベース

14


• 共通点

• Join、Transactionなど一部のRDBMSの機能をサポートしないことによりハイパフォーマンスを実現している

• スケールアウト、分散管理を前提に設計されている

• KVS（Key-Value ストア）

• データをkeyとvalueで持つHash形式。

• 基本的にはkeyでの完全一致検索でしかデータを取得できない制限があるが、高速に動作する。

• ドキュメント指向データベース

• スキーマを定義しなくても使用できるスキーマレスである。

• 複雑な検索条件でデータを取得することが可能。

• 一部の機能はRDBライクに使用することができる。

• 列指向データベース

• 行単位では無く、列単位での処理に特化している。

• 書き込みに対して強力なスケーラビリティを発揮する。

• NoSQLと呼ばれているものは３つに大きく分けられ、MongoDBはその中で「ドキュメント指向データベース」に当てはまる

NoSQLの種類：まとめ

15


MongoDB memcached HBase Cassandra

SQLライクな検索 ○ × × ×

性能 ○ ◎ ○ ○

分散/スケーラビリティ ○ △ ◎ ◎

開発のしやすさ ◎ ◎ × ×

日本語ドキュメント ○ ○ ○ ○

商用サポート ○ × ○ ○

MongoDBは、 KVSや列指向DBほど特化していないが、RDBライクに開発できる。

MongoDBとその他NoSQLとの比較

16


MongoDBの思想

トランザクション/JOINを実装しないことにより、KVSに近い性能を出している。一方で、トランザクション/JOIN以外はRDBに近い機能を持っている。

17


ドキュメント指向データベースで、NoSQLの一つに分類される

スキーマレス

高パフォーマンス・スケーラビリティを保持しつつRDBライクな機能をバランスよく組み込むことを目指して開発されている。

軽いRead/Write処理のパフォーマンスが高い

スケールアウトが容易

MongoDBとは

任意のIndexが作成可能で、SQLライクな検索が可能

集計処理用のコマンド集を実装

18


データフォーマットの柔軟性が求められるものや非常に更新頻度が高システムに向いている

1. Webサイトの操作データログの蓄積

• 多くの事例がある

• Capped Collection（サイズの制限付きコレクション）やTTL Collection（期限付きコレクション）が使える

• アプリによって出力フォーマットの違うログを一括して扱える

2. アドホックなフィールドを検索対象とするようなコンテンツ

• ユーザによって独自項目を定義できるようなシステムや、拡張要件のあるシステム

• 独自項目を検索対象にすることも可能

3. スマートフォンゲーム、ソーシャルゲーム

• 小規模なRead/Writesが大量にある場合

※出所 [Mongo] Use Cases http://www.mongodb.org/pages/viewpage.action?pageId=21266728 http://www.mongodb.org/display/DOCS/Use+Cases http://www.mongodb.org/display/DOCS/Production+Deployments

MongoDBが向いているケース

19


1. 銀行系のように複雑なトランザクションに重点を置くシステム • 複数のトランザクションを必要としたクエリが必要になる場合，MongoDBは向いていません。ただし，1つのドキュメントに対するAtomicな操作はサポートしていますので，ネストしたドキュメントを使用して設計を工夫することにより対応可能になります。

2. 伝統的なビジネスインテリジェンス(BI) • MongoDBはバッチ処理が不可能でこそないですが，リアルタイム処理のほうが得意です。

3. SQLを必要とする問題 • MongoDBはSQLをサポートしていません。

※出所 [Mongo] Use Cases http://www.mongodb.org/pages/viewpage.action?pageId=21266728 http://www.mongodb.org/display/DOCS/Use+Cases http://www.mongodb.org/display/DOCS/Production+Deployments

MongoDBがあまり向いないケース

20




４．まとめ


21


検討１

KVSでは実現できないか

22


検討２

本当にスケールアウトが必要か

23


検討３

メモリ/ディスクのコントロールは必要ないか

24


検討４

マルチトランザクションは必要ないか

25


検討５

本番環境にリリース後、バージョンアップできるか

26


検討６

データ暗号化、ユーザ権限は必要ないか

27


検討７

顧客/開発メンバーがリスクとメリットを理解しているか

28


MongoDBを導入する前に検討した7つのこと

1. KVSでは実現できないか

2. 本当にスケールアウトが必要か

3. メモリ/ディスクのコントロールは必要ないか

4. マルチトランザクションは必要ないか

5. 本番環境にリリース後、バージョンアップできるか

6. データ暗号化、ユーザ権限は必要ないか

7. 顧客/開発メンバーがリスクとメリットを理解しているか

29




４．まとめ


30


Hybrid MySQL and MongoDB

• 事例紹介

• 金融業界/投資家向けのSNSサービス

• 2012年4月リリース、本番稼働中

• MySQL (and Java)

SNS サービス

MySQL

31


Hybrid MySQL and MongoDB

• 事例紹介

• 金融業界/投資家向けのSNSサービス

• 2012年4月リリース、本番稼働中

• MySQL (and Java)

• CRM機能を追加、データストアはMongoDBを採用

SNS サービス

CRM

MongoDB MySQL

32


ユーザごとの独自項目定義

• 要件

• ユーザが顧客管理のための独自項目を定義できること

• 独自項目はテキスト型、リスト型、チェックボックス型で定義できること

• 独自項目を検索できること

SNS サービス

Customer Fields -name -email -address -sales_level -industry -…

Customer Fields -name -email -address -interests -assets -…

Extended fields depents on the user

User B

User A CRM

MongoDB MySQL

Search salses_level = 3

Customers

33


スキーマ設計

CRM

extended_definition collection

extended_values collection

user collection

user collection

user collection

MongoDB

34


スキーマ設計

CRM



user collection

user collection

user collection

MongoDB

35


スキーマ設計

{ “_id”:ObjectID(“50ad9b3976c25eb2096dd1da”), “userId”: 12233, “extendedItems”:[ {“name” : “sales_level”, “type”: 1,“selectValues” : [1,2,3,4,5]}, {“name” : “industry”, “type”: 2,“selectValues” : [“food”,“IT”,“vendor”,“retail”]} ] } …

{ “_id”:ObjectID(“50ad9b3976c27eb2096dd100”), “userId”: 12233, “name”:”Atsushi Sato”, “email”:”[email protected]”, “extendedValues”:[ {“name” : “sales_level”, “value”: [ 3 ]}, {“name” : “industry”, “value”: [“1”,”3”,“5”]} ] } { “_id”:ObjectID(“50ad9b3976c26eb2096dd101”), “userId”: 12233, “name”:”Bunta Suzuki”, “email”:”[email protected]”, “extendedValues”:[ {“name” : “sales_level”, “value”: [ 2 ]}, {“name” : “industry”, “value”: [“1”]} ] } …



type =0 : text =1 : list =2 : check box

Defined for each user

36





４．まとめ

37


まとめ

• MongoDBは顧客の要件に柔軟に対応できる機能を持つ

• スキーマレス

• SQLライクな検索

• スケーラブル

• MySQLで稼働しているシステムへのMongoDBの導入

• Hybrid MySQL and MongoDB

• データ特性に応じて適切なデータストアを選択

38


[email protected] http://openstandia.jp/

本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。

Documents

MongoDBを導入する前に 検討した7つのこと · 2. 伝統的なビジネスインテリジェンス(bi) 伝統的なビジネスインテリジェンス(BI) • MongoDBはバッチ処理が不可能でこそないですが，リアルタイム処理のほうが得意

MongoDBを導入する前に検討した7つのこと · 2. 伝統的なビジネスインテリジェンス(bi) 伝統的なビジネスインテリジェンス(BI) • MongoDBはバッチ処理が不可能でこそないですが，リアルタイム処理のほうが得意