#garagekidztweetz

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

とても勉強になった #mongotokyo のメモ

スポンサーリンク

ブログを書くまでが Conference ということで...
MongoDB Tokyo 2012に参加してきましたので、わたしがとってきたメモを share させていただきます。
※ スライドは Slide Share 等に公開していただけたものを随時はらせていただきます。


今日の MongoDB Tokyo 2012 は品川シーサイドの楽天タワーで開催されました。


MongoDB のステッカーと NAVER さんのストラップ、そしてパンフレットをいただきました。

先に感想を書いてしまいますが、
すべてのセッションが、大変有用でとてもためになりました。
とくに " mongo-hadoopで始める大規模ログ解析 〜低コストへの新たな道〜 (@muddydixon Daichi Morifuji) " が良かったと思います。
スライドが公開していただけるのであれば、必見かなと思います。
スライド、公開していただけましたね。本エントリにも埋め込みさせてもらいました。必見です。

では以降、わたしのとってきたメモです。

Opening

hashtag: #mongotokyo

1:00 pm - 1:45 pm Welcome to Mongo Tokyo and Overview of MongoDB (Max Schireson President, 10gen)

▶ Background

By Dwight Meriman(Double Click CTO) and Eliot Horowitz(Double Click Engineer)
Founded four years ago.
31 Million $

▶ RDBMS has been an important tech for a long time

from 1970
tech change a lot.

▶ Recent changes

Big data

  • Billions millions record
  • 100s of k/millions of queries per second

Cloud - economics

  • elasticity

Developer empowerment

  • Developer has a strong voice
    • democratic
▶ New DB Requirement

Horizontally scalable

  • Run in 100s or 1000s of commodity servers

Agile

  • smaller team respond more less time
▶ New req lead to new architecture

Horizontally scalable

  • Sharding
  • Replica sets for greater reliability

Document oriented

  • new data model required to avoid distributed joins and multi statement transactions
  • JSON for developer productivity
▶ MongoDB is the leading NoSQL Database

inspired by custom data stores created at double Click to handle 400,000 advertisement per second
Now the market leader
Over 1 Million download

▶ Partnership - some examples

Amazon
MS
Redhat
VMWare

▶ Leading customers Commercial Customers

Internet and Tech

  • Ebay, Intuit, SAP

Enterprise

  • Disney, Ericsson, MTV ...

Government

  • UK National Achieves, India National ID


and some Japanese users also

▶ Who Customers are Choosing MongoDB

Capability
Economics

  • servers, storage, SW
▶ MongoDB in Japan

DB tech know well 10gen
learning Japanese market
Thinking MongoDB may fit for Japanese market
Looking forward to find the good partnership in Japan

No QA

1:55 pm - 2:40 pm Basic Application and Schema Design with MongoDB (Alvin Richards, Senior Director of Service & Enterprise Engineering)

▶ Topics

Schema design is easy
Common Patterns

▶ Use MongoDB with your language

10gen support drivers

  • Ruby, Python, Perl ....

Object data mappers

  • Morphia - java
  • Mongoid, MongMapper - Ruby
▶ So todays example will use

Presenters favorite book

▶ Design your objects in your code (code sample)

Java using Driver

  • get a connection to the DB
  • Create the object
  • insert the object into MongoDB
▶ Java using object data mapper

use morphia create the data store
create the object
insert object into MongoDB

  • emphasizing MongoDBs simplicity.
▶ Terminology

Difference between RDBMS and mongoDB
Schema design relational database

  • ER diagram

MongoDB schema Design

  • alternative of same schema design
  • embedding, linking
▶ Design Session

Design documents that simply map to your application

  • ID must be unique, but can be anything you'd like
▶ Add and index, find via index

1 means ascending, -1 means descending

▶ Examine the query plan

B-tree cursor

▶ Query operatiors

Conditional operators
find posts with any tags
(like a like query)

▶ Extending the Schema

Schema less
MongoDB will not enforce schema
Not need to talk with DBA for painful conversation when you want to add the column
update statement

  • push command
  • inc command

create index on nested documents
find last 5 post
most commented post

▶ Common Patterns

Inheritance
how to implement in the RDBMS - sample
When use MongoDB - sample

  • missing values not stored. ( because dont need to store )

how to find the data sample.
find shapes where radius > 0

  • index only values present
    • index are very small
▶ One to many relationship

One to many relatiionship can specify

  • degree of association between objects
  • containment
  • ...

Embedded Array

  • $slice operator to return subset of comments
  • some queries harder
    • e.g. find latest comments across all blogs
  • > alternatives

Normalized (2 collections)
now can collect latest 3 record among all blogs

  • most flexible
  • more queries


Summarize
One to many - patterns
Embedded array / array keys

▶ Many - Many

Example - products and categories Original design
Alternative design
talking about each pros and cons.

▶ Tree Pattern

Hierarchical information
Blog - Comments <- Reply

Full tree in Document
Pros. Single Document , Performance , intuitive
Cons. Hard to search , Partial result, 16MB limits

▶ Array of Ancestors

A
B, E
C, D, F

Alternative
Store all Ancestors of a node
find all threads where "b" is in.
find all direct message "b" reply to

▶ Tree as Paths

Store hierarchy as a path expression

  • Separate each node by a delimiter , e..g. ","
  • ...
▶ Queue

Need to maintain order and state
Ensure that updates are atomic

find highest priority job and mark as in-progress

▶ Summary

Schema design is different in MongoDB
Basic data design principals stay the same
Focus on how the application manipulates data
Rapidly evolve schema to meet your requirement
...

▶ QA
1. 複数のClientが1レコードをみにきたときはどうなるか

Version number を比べる

2. Write management

several client
1 collection
several collection
at the same time.

Blocking system mongoDB has.
Blocking serialize the system

3. permission for different collection
4. all of the writes are managed by a single lock system

but the lock is not so work in a long time
per collection or per db locking are now expecting.

5. How to embedding

Owe to your application how to implement

6. Transaction

MongoDB guarantee only 1 single document writing atomic
When you fail writing, before failing data can write but after fail can't write.
if you need rollback, you need to implement rollback function in your application by yourself.

2:50 pm - 3:35 pm Effective MongoDB Deployment Architecture (Alvin Richards, Senior Director of Service and Enterprise Engineering)

▶ Five things to think about

Data protection
Machin sizing
Load testiong and monitoring
Back up restore
Handbook

▶ Types of outage

Planned

  • HW upgrade
  • OS or FS tuing
  • rellocation


Unplanned

  • HW failure
  • Data center failure
▶ Replication features

a cluster of N servers
any single node can be primary
consensus election of primary
automatic FO
automatic recovery
all writes to primary
reads can be to primary or secondary

▶ How mongoDB replication works

3 nodes cluster
contact each other
Election establishes the primary

When primary fails
surviving members contact each other
and choose the next primary

member2 become primary automatically

when the previous primary back
it automatically recovery
and replication re-established.
the previous primary is no longer become primary in this moment

▶ Typical COnfiguration

Single MongoDB
if it failed
cant read data, cant write data

Replica set two nodes
when one node dies
application can read read
but cannnot write
# majority must be exit for electing the leader

Three member replica set
one node dies
Application can read and write

Replica set
2 in London
2 in SF
1 in NYC
if London failed
application can read and write

All of these happen automatically

▶ HW sizing

How many machine need to order?

Collection1
index1
Virtual address Space1

  • > mapped to Physical RAM
  • > Physical RAM is mapped to Physical Disks
▶ Sizing RAM and Disk

Woking set
Document size
Memory versus Disk
Data lifecycle patterns
# important to un

  • Long tail
  • Pure randum
  • Bulk remove
▶ Figuring out working set

Can easily know from stats.
db.blogs.stats
Size of data
Average document size
size on disk (and in memory)
Size of all indexes
Size of each index

▶ Data configurations

Comparing Single disk,
RAID0 configuration
RAID10 configuration ( n number of striping )

▶ SSD?

Seek time of 0.1ms vs 5ms
But expensive

Can see mixture of SSD and HDD
the data need performance move to SSD and not need performance remained on HDD

▶ Key Points

Know how important page faults are

  • if you want to latency avoid page faults

Size memory appropriately

  • to avoid page faults fit everything in RAM
  • Collection data + index data

Provision disk appropriately

  • RAID10 is recommended
  • SSD are fast if you can afford them
▶ Monitoring is your friend

To understand MongoDB deeply, you need to concern monitoring in a first statge.

▶ Monitoring Tools

mongostat
MMS! - 10gens tool
munum, cacti, nagios, zabix

▶ Load testing understand what you think the system should be

load and test your hypothesis

  • use the DB profiler
    • Trend

use a trending monitoring tool to analyze - MMS, munin, etc...

▶ Backups

mongodump versus snapshot
Restore a member versus whole rep set versus whole cluster
Don't forget your config dbs in a sharded system

▶ Plan for the worst

Not everything will go to plan
Have a operation handbook
Practice basic procedure
backup & restore failing over node
rolling upgrade

Nevetthless your boss calling you something wrong happen to your system.

▶ QA
1. when contain propaganda data primary down
2. memory map file, size limitation (2GB)
3. maximum number of nodes

OSS so what people doing they can't know more than hundreds
2PB, 260nodes
MongoDB is CPU intensive system, so if you put MongoDB on the same machine previously woking Oracle or MySQL, you can see the CPU bound.
But you can also see good access to the memory

4. if you auto sharding

heard the bug of count the number of nodes are incorrect is it fixed?
not so optimized counting nodes in this moment.

5. master fails write operation

Mongo asyncronous write

6. multiple replica set

all reads are going to primary (default)

3:45 pm - 4:30 pm KVSの性能、RDBMSのインデックス、更にMapReduceを併せ持つAll-in-One NoSQL: MongoDB (@crumbjp Hiroaki Kubota)

Rakuten MongoDBの特徴、それを活かした使い方などを楽天・インフォシークニュースの事例などを通じて紹介します。また機能、性能の検証結果、運用ノウハウの共有。PHPドライバのパッチなども公開します。

▶ introduction
▶ MongoDB characteristics

Read intensive.
Write is not so much good
To read data immediately after its written is not good

▶ Our new system Cockatoo

ニュースの配信サービス
LayoutとComponent
Sessionはmemcachedに変えた(後述)

▶ Cockatoo system diagram(image)

VM(1Core)を5node
developer

CMS

ContentsDB(mongo)

▶ MapReduce

楽天では使えていない
記事を消すときなど少しは使っている
ソーシャルに展開する際にもっと使って行きたい

▶ ベンチマークテスト

計算式
C = number of core
DD = dd command performance (byte/sec)
S = document size (byte)

  • Get qps = 4500 x number of core
  • Set bytes/s = 0.05 x DD / S
  • Set (nsync) qps = 4500


AWS のインスタンスサイズの共有
ノード追加のコスト
性能評価時のクエリの紹介
Group by x 6,000万件 →52min

▶ MongoDB の落とし穴

図解
Indexing

  • Lock operation
  • work firstly on primary
  • next work on secondary →結果、サービス止まってしまう

バックグランドで実行してもダメ

Manual index
Primary でのindexing が終わっても自動的に secondary には自分でindex つくる
(提案してみようとおもっていたが)
→すでに実装予定がある 10gen

Staleという問題
replica set の問題
oplog をみて同期をしていく
oplog は再起的に使っているので、あまり忙しいと古いデータが同期されるまえに消してしまう
oplog size はMongoDBを最初に起動したときのサイズで固定されてしまう
初期設計が重要ということ
oplog あふれがおこると他の secondary をみにいく

Disk Space
データの更新(追加、削除)を大量にしていると、フラグメンテーションが起こる

PostgreSQLのバキュームのような処理
Compaction
セッションデータの格納に使っていた
→Workaroundの共有(step down の応用)

PHP の問題
1.1.4
Connection pool がっこわれたときに捨ててくれない
1.2.2
Socket Handle leak
etc ..
1.2 系を使うのを推奨
→PHPの patch on github

▶ Summary

High read performance
Good durability
Sharding is very challenging

  • operation is hard

Can work on a cheap environment
Need to consider high write throughput

▶ QA
1. session 情報にMongoDBを使わないのは

oplog が溢れるから

2. fsync=true の理由

staleになるのを防ぐため
あまりレスポンスが早いと oplog を使い切ってしまう、古いデータが消える

3. oplog の内容の確認
4. oplog のリサイズ

より大きな oplog のセカンダリをつくって置き換えていく

5. Read 主体のサービスで使っているように思うが、大きな write が発生するサービスでも使うことを薦められるか

write の内容によります。

6. indexing

アプリ変更などのタイミングなどでは、index は新たにつけたりしないよね。それはRDBMSと同じ

4:40 pm - 5:25 pm 事例:とある写真共有アプリでの MongoDB (@just_do_neet Tetsuya Ohira)

NHN Japan 事例:とある写真共有アプリでの MongoDB
事例紹介におもきをおく

▶ self intro
▶ Intro of NHN Japan

Korean Company
Japan Subcidiery

  • search (NAVER)
  • mobile app
▶ Position talk

使いやすいストレージ
スキーマレス、ドキュメント志向
なかなかひとつのスキーマに決めにくいデータ

MongoDB
スケールするDB
Big Data に使うのはきびしい
まだまだMongoDBのエキスパートは少ない

大規模運用は難しい

企業DBには3種類
Mongoは3つ目のDBだ
カジュアルな実験の場
いままでできなかったことができる

▶ introduction of examples of using MongoDB
▶ NAVER photo album

iOS and Android app also.
social 系の機能、TLなど
MongoDBはまさにTLに使っている

その課題
複雑さ
アクティビティの種類、それぞれに違う情報
ユーザとの関係性、それもいくつかの種類
過去のアクティビティを検索して消す

DBでやろうとすると、アクティビティごとにスキーマをきめないといけない

それはできるよMongoDBなら
オペレーションはシンプル
★実際に発行しているQueryのサンプル

▶ とあるメッセンジャーアプリの話(LINE)

検討したが、MongoDBは使えなかったという話

どんなアプリなのかという説明
ベッキーのCMで有名
中東地域でなぜか人気
半年で1000万ダウンロード
: やたら謙虚…

要求する要件
スケーラブル

MongoDBとHBaseと比較

MongoDB
Auto sharding, 設定簡単
データの肥大化がこわい
HBase
実績があるFacebookなど
チューニングが細かくできる(メモリ、compaction)
SPOF
: これはすでにないと思うが

検証→内容は、スライドを。
15台で検証。最終的にはもうすこし台数を。(さばけなかったから)
NAVERの use case ではHBaseがいい結果に。
HBaseのほうが書き込みでいい結果
Readは同程度できるという結果( id 指定の単純なもの)
NWの使い方が違うっぽい
Mongo はキャップがかかっているかのように上限があるようにみえた
HBaseは定期的にsync しているよう
HBaseは圧縮ができるところも好感

最終的にはHBaseを使った
Data Size
NW
がネックになった MongoDB
※大規模で使えないといいたいわけではない
★HBaseは現状、100TBクラス

▶ とあるWebサービスのデータ解析

準リアルタイム分析をやりたい

fluentd, node.js + MongoDB

fluentd の説明

plugin 機能があることが大きな売りという印象をもっていると。
過剰に負荷をかけないでMongoDBに書き込める

real time analytics system architecture
使っているもの
apache
fluentd
Hadoop
MongoDB
jubatus
node.js

▶ Demos

(1) NAVER まとめ
ユーザがどの国と地域から見にきているか世界地図にプロットする
maptail.js を拡張
1分程度の時差
(2) 今、サービスを見にきている人の情報

教訓
MongoDB も素晴らしいが、fluentd や node.js などを組み合わせるとよりよいものがつくれる
java script の文脈で一貫してシステムをつくれる

▶ まとめ

MongoDBはいいよ
適切な現場があれば、カジュアルにつかってみてはどうか

▶ QA
1. MongoDBのスキーマデザインの話

embedded

2. Cassandra という選択肢はなかったのか

MyCassandra をつくった人が中にいる。
Cassandra にしたいという話はある。
そのときは対象にあがらなかったという話

3. MongoDB の非同期

5:35 pm - 6:20 pm mongo-hadoopで始める大規模ログ解析 〜低コストへの新たな道〜 (@muddydixon Daichi Morifuji)

Nifty mongo-hadoop https://github.com/mongodb/mongo-hadoop を利用することで、「Hadoop始めました」の次のHDFSの管理や冗長化などをmongoに肩代わりさせることで、一番つらい運用フェイズの習熟コストを落とし、少人数で大規模ログ解析を実現する手法について紹介します。

Hadoop の input ソースとしての MongoDB という話
Hadoopの管理は大変
HDFSの管理
HBaseならばZookeeperも

▶ self intro.

@muddydixon
去年、部ができた
2人のエンジニア

▶ log解析

大企業じゃないときびしい
リソース足りない

▶ Requirement

Adhoc Query
OLAP for survay
Distributed processing for non-holiday works

▶ MongoDB

Cons

  • OOM occures in MR
  • rich resources (memory/disc)

Pros

  • HA
  • Full index
  • Schemaless
  • AutoSharding
▶ Hadoop

Cons

  • Operation Difficulty
  • Many daemons
  • HBase needs more daemons
  • Hive spends much times

Pros

  • Scaleout
  • Calculate large data by MR
  • Scalabule HDFS
▶ Cons

Mongoは解析にむいてない

Hadoopはデーモン多すぎる
管理たいへん

▶ mongo-hadoop

図解
Javaの Adapter
Hadoopの読み書きがMongoでできる
it enables Hadoop to access MongoDB data
mongo-hadoop supports shards and chunks environments

HadoopのHDFSの部分が、MongoDBになったイメージをしてほしいとのこと

▶ Sample

これはスライドを見るのがよい
BSON の返ってきた型は知っていないといけない

▶ Hadoop と MongoDBの Consがいれかわる

Easy Calculate Large data
Limited deamons
Replica set and sharding
Can find data in a moment

▶ Advance

★ Hadongo

  • use BSON writable
  • use Common Mapper
  • use Reducer class for combinator
  • merge multiple put resources *now pull requesting)

同じKeyのものはおなじReducerで受け取ることができる

why use BSONwritable?
we can use schemaless objects consisted of stiring number boolean object list
we should handle them such as check existence, type validation

use common mapper
In hadongo
we create common MR for distinct processiong logics and use it to analyze manay validations

▶ why not publish hadongo

まだ、完成してないから。

▶ まとめ

データを解析したい人にご自身でどうぞを実現できる
新年会 cross
Data Miner、Data Scientist 募集中

▶ QA
1.Reduce 後の書き込みが Mongoの不安


書き込み先を変える、たとえばHDFS
Reduceでより小さくのチューニング
などで回避

2.Hadoop とMongoの Cluster は別

同梱させて動かすことは考えてなかったのでSourceをそこまでみていない
Data Localiy を確保できたら省エネ

3. hadongo はいずれリリース

いかに楽にデータ解析しようかを実現したくてつくっている
MongoDBには何も手に入れていないところが売り

4. Sqoop は Mongo に対応してないか

してないという記憶

6:30 pm - 7:15 pm ソーシャルゲームにおけるMongoDB適用事例 (@matsukaz Masakazu Matsushita)

CyberAgent Americaで開発したFacebook向けソーシャルゲーム「AnimalLand」におけるMongoDB利用事例を紹介します。

パイプ椅子でお尻が限界だったため、離脱しました。
後ほど資料を読みます。

以上です。
みなさん、今日はお疲れ様でしたmm

こちらもあわせてどうぞ