Mongodb x business

MongoDB x Businessdb tech showcase Tokyo 2015

Yuji Isobe

ProfileYuji Isobe

Play fiddle/violin

Engineer

Contribute to socket.io

Startup member of emin

emin = Emotion Intelligence 気持ちを解するテクノロジーの探究

Emotion Intelligenceは、「無意識の行動から、

人の気持ちの機微を解する知性」を、人工知能および機械学習の応用技術を用いて

開発し、ビジネスに応用しています。

ZenClerk 当社が開発した予測エンジン「Emotion I/O」が、ウェブサイト上のユーザーの無意識の行動をリアルタイムで検知、解析します。ユーザーの購買行動における迷いを察知し、最適なタイミングでオファーを提示する「コンバージョン・オプティマイザー」が、ECサイトのCVRを最適化します。

なぜdb tech showcaseでビジネスがテーマなのか？

正しい技術はビジネスの要件を満たす

よく受ける相談

□□使わないの？

△△がつらい

××使ってるけどこのままでいいのかな

○○ってどう思う？

技術なんて何使っても一緒でしょ？って言われた

んだけどどうすれば…

正しい技術はビジネスの要件を満たすBusiness

Tech

正しい技術

Business

間違った技術

Tech間違った技術を選択するとビジネスは成功しない

BusinessTech

スケールしない技術

スケールしない技術はビジネスの足かせになる

BusinessTech

コストが高い技術

コストが高すぎる技術はビジネスを食いつぶす

BusinessTech

スケールする正しい技術

スケールする技術はビジネスを加速させる

特にDBは後から変更がなかなかできません

NoSQLは適材適所

それはMongoDBも例外ではありません

Depth of Functionality

Scal

abili

ty &

Per

form

ance

memcached

RDBMS

key/value store MongoDB

MongoDBの立ち位置

Relational Databases Fight NoSQL Gravity https://www.mongodb.com/blog/post/relational-databases-nosql-gravity

https://www.mongodb.com/blog/post/relational-databases-nosql-gravity

この図にはないことが現実では問題になります

ビジネスの視点がますます重要になってきています

一つのユースケースを紹介するだけではなく新たな問題に直面した時にも解決に役立てられる

Goal

Topics

なぜMongoDBを選んだのか

ビジネスが急速に成長する裏で、どのような問題に直面し、解決してきたか


その前に

私たちは目的に応じてDBを使い分けています

redis : リアルタイムデータ

MongoDB : 分析用ログデータ

MySQL : マスターデータ＆レポート

使用しているDB

redis : リアルタイムデータ

MongoDB : 分析用ログデータ

MySQL : マスターデータ＆レポート

使用しているDB

CouchDBHBASEcassandra

3年前に比較検討したDB

今なら Amazon DynamoDBあたりも検討に入りそう


構造化データ

スキーマレス

スケーラビリティ

ビジネスプロセス

ビジネスプロセスリアルタイム分析

キャンペーン配信

データマイニング

モデル構築

本番投入

データ蓄積

Garbage In,Garbage Out

ゴミを分析してもゴミが返ってくるだけ

データの価値を高めるプロセスを作る

構造化データ

db.events.insert({ event: “touch”, touches: [ {pageX: 150, pageY: 100, …}, {pageX: 47, pageY: 171, …} ], touchCount: 2 });

db.events.createIndex({ event: 1});

行列に縛られないデータ構造を表現できる

検索したいフィールドに

自由にインデックスが貼れることが大きな強み

Point!

MongoDBはRDBMSと似たインデックス構造を

持っているので、RDBの知識を生かすことができます

B-Tree, Compound Index, Covered Index, etc.

スキーマレス

db.events.insert({ event: “touch”, touches: [ {pageX: 150, pageY: 100, …}, {pageX: 47, pageY: 171, …} ], // delete touchCount: 2, // new orientation: -90, touchStart: new Date(), … });

取得したいデータは日々変化していきます

RDBの強みであるはずの

スキーマが、ビジネスの足かせになってしまう

Point!

『スキーマレス≠スキーマ定義が不要』ではありません

むしろ、スキーマレスであるからこそ、スキーマ定義がとても重要です

https://www.mongodb.com/presentations/schema-design-scale-1

https://www.mongodb.com/presentations/schema-design-scale-1

レプリカセット: 冗長性の確保とReadの分散

シャーディング: ReadとWriteの水平分散

スケーラビリティ

シングルノード

mogngod

レプリカセット

delayed replica

replica set

レプリカセット＆シャーディング

replica set shard

mongos

replica set shard

replica set shard

delayed replica

delayed replica

delayed replica

mongoc

ここまでコードの変更はほとんど必要ありません

Point!

はじめから大規模なDBを構成する必要はありません

まずはミニマムに始めて、ビジネスの成長に合わせてMongoDBもスケールさせることができます

現実の制約

Node.js との相性

➡双方向通信のために socket.ioが必須だった

ホスティングサービスの有無

➡少数精鋭でサービスに集中したかった

営業とデータサイエンティストも扱える

サービスに集中するためにホスティングサービスを利用するという選択は検討の価値あり

http://www.slideshare.net/yujiosaka/starting-mongo-db-on-hosting-services

http://www.slideshare.net/yujiosaka/starting-mongo-db-on-hosting-services

MongoDBが適さなかったケース

コレクションのジョインができない

コレクションをまたがるトランザクションを管理できない

ドキュメントサイズが予測できない場合にディスク効率が悪い

MongoDBの苦手分野

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

http://blog.scrapinghub.com/2013/05/13/mongo-bad-for-scraped-data/

http://blog.scrapinghub.com/2013/05/13/mongo-bad-for-scraped-data/

スキーマデザインに失敗している

複雑なトランザクションが必要なデータを扱っている

ドキュメントサイズが予測できない

適さなかった理由

DB単位でロックがかかり、CPUを効率良く使えない

ホットデータがないようなデータの管理が苦手

MongoDB 2.6以前の問題

少し怖がらせて

しまいました…

しかし、DBの選択は本来慎重であるべきです

Point!

MongoDB 3.0ではMMAPv1のCollection LevelやPluggable Storage Engineが実装され、少しずつ

苦手分野を克服しつつあります

Topics




Customer Count

Tota

l Cos

tsOptimizationMore

hardwareCosts too

high! optimize

Changing the Growth Formula https://www.compose.io/articles/changing-the-growth-formula/

Low totalcosts

https://www.compose.io/articles/changing-the-growth-formula/

Low total costs コスト・パフォーマンスの問題もなくサービスを提供できている

More hardwareビジネスの成長を支えるために投資をする時期

Costs too high! optimizeコストへの警告が上がり、アーキテクチャの見直しが求められる

Optimizationアーキテクチャが経済的にもパフォーマンス的にも最適化される

フェーズ



Customer Count

Tota

l Cos

tsOptimizationMore

hardwareCosts too

high! optimize


Low totalcosts


月間10億PV

同時接続数5万

月間10TB保存

db. ZenClerk .stats()

Economy Of Scale

ビジネスの成長につれてスケールメリットがきく

クライアント1社あたりのコストは自然と下がっていく

必要なことはスケールするシステムを構築すること

Problem

現実の世界は思った通りにいかないのが常である

効率化しなければコストは増え続ける一方

Solution

モニタリング

ボトルネック解消仮説検証

MMS

遅いクエリの監視

ボトルネックを見つけて、一つ一つ解消していく

https://speakerdeck.com/yujiosaka/yue-jian-10yi-pvkaraxue-ndamongodbantipatan


インデックスをチューニングしたり…



インデックスをさらにチューニングしたり…



常にホットデータを使うように意識したり…



クエリをチューニングしたり…



セカンダリへのクエリが向くようにしたり…



アップデートをチューニングしたり…



Redisを使ってバッファリングしたり…



目的に応じてDBを分けたり…



Point!

MongoDBは {“key”:”value”} の形式でデータを格納するため、データの増加も無視できない

定期的なバックアップ＆削除も大切

地道なチューニングが必要

銀の弾丸は存在しない（あるいはお高い）

To Shard-First, Or Not to?

まずはシャーディングに頼らないという提案

Inefficiency

非効率なままだと

非効率性も水平分散する

Inefficiency Inefficiency Inefficiency

システム全体を効率化させる

でも、それ以上に大切なこと

正しい技術はビジネスの要件を満たすBusiness

Tech

正しい技術

Throw Garbage Away, Discover New Gold

ビジネスに価値のないデータは捨ててしまう

価値のあるデータのためにコストを払う

Customer Count

Tota

l Cos

ts

1バイトの価値

1バイトの価値効率化

Technology scales business

We are hiring ;)

Engineering

Mongodb x business