Tweetと言うわけで、先週の11/01に楽天で開催されたNOSQL AFTERNOON JAPANに行ってきました。全体的に、もうRDBMSじゃなくてKVSなんだなぁと感じさせるような賑いでした。以下、当日のログを。
Hibari/NOSQL for BIGDATA @ Gemini Mobile Tech.
- Function programing world conference will hold at Japan
- About Gemini
- Products
- MMSC for Japanese mobile carriers
- 2010/07 Hibari open source
- @geminimobile
- @hibaridb
Hibari
- for GB mailbox webmail
- chain-replication
- good performance for read big data
- Linux distribusion supported
- Erlang/OTP R13B03
- supports Amazon S3, JSON, native Erlang client API
- “read-optimized”
- Admin server
- Why NoSQL?
- necessary to support TB data
- for webmail
- needs
- Durability, Strong Consistensy, Low Latency, High Avalilabirity
- Heavy READ
- Big DATA
- Features
- fsync()
- Chain Replication
- Chain order : Head -> Middle -> Tail
- Keys serves to Multi-servers
- Automatic rehashing (Fault Tolerance)
- Benchmarking
- Hibari Stub
- 150k ~ 30ms latency
- Hibari and Cassandra
- Hibari : 150k ~ 70ms
- Cassandra : 100k ~ 70ms
- Langurage Barrier
- Java <-> Erlang
- Roadmap
- Thrift API
- Hadoop API
Q&A
- Admin server’s availability
- hot stand-by
- CAP 定理でどれが重要か
- いまはいい答えができない
- Erlang にパッチを当てないといけないのか？
- ????
- Chain Replication はどの単位？
- key-value group
- Key, Value の最大値は？
- 特にないが、各値がサーバのメモリで処理できるかどうか
Summary
- 読み込みに特化した KVS
- 特に巨大なデータの読み込みに特化している
- 携帯ウェブメールとかSNSとか
- オンメモリで動作している模様
CAP 定理について
- どれに特化するかはもちろん場合によりけりなので、一概に言い答えを出すことはできない
Okuyama @ Kobe Digital Labo
- Name from Okuyama Drive-way
- made by Java
- for small data
- Persisitence, Network, Replication
- Master nodes -> Data Notes (x3)
- Persistence
- Memory, Disk, Disk+Memory
- Network
- Original Protocol, Memcached(not CAS), HTTP(get only)
- Redundancy / Avalilability
- Data stored by Multi servers
- Persisntent Mechanism
- Memory -> Fastest mode
- Disk -> Key and Value have saved in separeted files
- Diska and Memory
- Type 1 : Save to file
- Type 2 : Save to file, and keys stored in memory
- Network
- Queueing system
- Original Features
- Tagged value
- multi key?
- JavaScript run in Data Nodes
- Data locking
- Locking time
Q&A
- タグで指定する場合のスピードの差は？
- キーで指定するよりも倍程度かかる
- Disk mode の用途は？
- 低スペックで扱いたい場合に
- Master / Data Notes のスケーラビリティは
- Data note を増やせば上昇する
- Master node は stand-by のみでスケーラビリティはまだない
Summary
- 小さなデータを扱うことに特化している
- タグが特徴的で、それで性能劣化が低い状況下であれば良さそう
- 問題は scalability と availability で、その部分がまだ不十分というか、未検証かなという感じ
Introduction to Apache Cassandra
- by @zznate
- Casanndra -> Inbox Search -> Amazon Dynamo’s clustering infrastructure and BigTable’ data model
Cassandra
- Scaling
- Scaling up by adding data hosts, and separete keys into added and exist hosts
- Reliablitiy
- データはいくつかのホストに分散保存しているので、障害体制がある
- またホストが落ちたときも、すぐに再生できることができる
- Tunable Consistency
- Select consistency level
- Flexible Data Mode
- Not a Key/Value store
- Column famiries like BigTable or Dynamo
- Super columns
- column grouping
- apple -> colA, colFoo, fram in key “a”
- Supports secondary index in Version 7
- Analytics
- Hadoop Data Locality
- MapReduce runs each Data Note
- Monitoring
- Graphical UI interface
- Community: Clinet Library
- Pythin/Java/Ruby/.NET/PHP(new!)
- Add-ons
- Lucandra: Lucenne + Cassandra for full text search
- Munin configuration
- Chef recipes
- Riptano
- Supports and Training
- Clustering Visualizing Tools
- Administration Tools
Q&A
- Compaction Problem : More memory and CPU usage
- Need to configure and tuning parameters, so resolve such problem
- ???
- Range ???(25件取得するために10000件なめる必要があるときがある)
- 状況にによりけりだが、Secondary index で解決できるのではないだろうか
- Avro or Slate for searlization format
- Not Avro, but Slate
- ノードの障害時に、隣接するノードに対する負荷が上昇して、さらに障害が発生する、と言う連鎖に対する解決方法は？
- 適切な設計をすればいいのではないだろうか
- 適切な性能計画、サーバの選定などを行う必要がある
- Amazon EC2 2台で10万リクエストとか厳しいでしょ？
- I/O QPS に対応するかどうか
- Slate Priority in Version 0.7
Summary
- Hadoop 使うには良さそう
- 何が特徴かがこのプレゼンでは不明だったので、あとで調べる
- 書き込み性能重視にしている
ROMA – User-Customizable NoSQL Database in Ruby
- ROMA is development in Rakuten
- ROMA used by Rakuten services
- session data, personal page view history
- ex)
- Rakuten travel
- page view history
- ROMA features
- High Availability / Scalability
- Fault-tolerance
- Better throughput
- Plugin Architecture
- DSL
- Technology
- Consistency Hashing, Virtual Node, Chain-replication, lamport clock
- Access to data
- client -> some nodes
- returns node ID which stores such data
- Chain-Replication to N nodes
- Message Protocol
- Extended Memcached Protocol
- Failure Detection
- heartbeat/1 sec
- plugin features
Q&A
- Ruby の GC は気にならないか？
- ボトルネックは I/O なので、そこは気にならない
- 基本的な script は公開されていたりするのか？基本的な script をライブラリとして提供してはどうか？という提案
- Licence
- GPL v3
- Why Ruby ?
- Matz driven development
Tokyo Tech の Nakamura さん
- 飛び入り
- Cassandra = Dynamo + Bigtable
- Cassandra の SSTable を MySQL のストレージエンジンに変えてみた
- JDBC 経由で MySQL にアクセスするだけ
- Future Work
- MySQL と Cassandra のいいところ取りした NoSQL プラットフォームのようなものを作りたい
MongoDB @ 10gen
- @rogerb
MongoDB
- @mongodb
- 90000 downloads per month
- growing
- production usages
- forsquare
- Implemented by C++
- 32/64bit Windows, Linux, MacOS X, FreeBSD, Solaris
- Ruby/Rails/Java/C#/JavaScript/C/C++/Erlang/Pythin/Perl/etc.
- NoSQL
- non-relational, next-generation operational datastores and databases
- no joins + no complex transcations
- Horizontally Scalable Architectures
- New Data Model
- Terminology
- Table -> Collection
- Row -> JSON Document
- Index -> Index
- Join -> Embedding & Linking
- Partition -> Shared
- Partition key -> Shared key
- API
- db.posts.save(JSON Document)
- db.posts.find #=> JSON Document
- _id : unique ID
- Index
- db.posts.ensureIndex({autho: 1}) # 1 -> ASC, -1 -> DESC
- db.posts.find({author: ‘roger’}) #=> JSON document
- Query operators
- conditional operators : $exists, $size, $type, $lt, $gt, …
- Regexp search
- db.posts.find({author: /^k/})
- Extending the Schema
- update = {‘$push’ : {comments: comments JSON Document}}
- db.posts.update(JSON document, update)
- posts.comments -> Array of comment JSON Document
- Secondary Index
- db.posts.ensureIndex({“comments.author” : 1})
- Generate sub-model’s index
- Deploying MongoDB
- 1st step
- Read/Write <-> Primary
- 2nd step
- Primary -> Secondary replication
- Read <- Secondary
- 3rd step
- Secondary -> Secondary for Backup
- Read/Write Scalability
- ReplicaSet
- Primary / Secondary / Secondary for Backup
- Key Shading on some ReplicaSet
- Monitoring
- Munin plugins
- MongoDB makes building applications easy
- Map/Reduce, Capped Collections, Tail-able Cursors, Geo indexing
Q&A
- どのようにRepicaSetを見つけるのか？
- 各Shadeがキーに対応するshadeを知っている？
- Shadingを追加したときの負荷は？ベンチマークは？
- 当初はshadingをしないで実装する
- shade を追加するのは簡単
- 日本での展開は？
- サポート体制を立ち上げる
- MongoDB Conference を2月に行うかも？
- Availability について
- データセンター障害の用無い場合でも Primary が落ちても自動的にどれが Primary に適切かを判断して切り替わる
Summary
- 後発だけあってかなり負荷とかデータモデルを頑張ってる感じ
- ReplicaSet の追加で shading が勝手に行われるというのはいい感じ
- データモデルを設計しなくてもいいので、スタートアップ的に作るのに向いている
- Ruby/Rails との相性がいい
Kumofs and The MessagePack Project
- kumofs and MessagePack
kumofs
- Distributed key-value store
- Get, Set, Delete, CAS
- Dymanic Re-balancing
- Not automatically, but dynamic
- Needs
- Manage heavy random reads and writes
- Low latency
- Archtectures
- kumo-manager : node manager
- kumo-gateway : installed in application server
- kumo-server : data-store
- Local Database : TokyoCabine
MessagePack / MessagePack-RPC
- MessagePack
- binary-based object serialization format
- MessagePack-RPC
- Cross-langurate RPC format
- Event-driven I/O
- server
- clients
- shared event loop
- shared server and client
- Production users
- Ameba now
- Apache SoIr + MessagePack
- Sedue
Q&A
- TokyoCabinet のように一つのキーに複数の値を保存するなどは？
- 厳しいです。用途が違うのかな？
- どういうきっかけでこういうプロジェクトを始めたのか
- えとらぼの例のあれで作った
Summary
- kumo-gateway がサーバ群の構造を隠して分散してくれるのはありがたい
- バックエンドに TokyoCabinet を使っている
RELAXING WITH COUTHDB
- for beginner
- schema-free database management sysytem
- Erlang
- Top-level Apache project
- Robust, concurrent, fault-tolerant
- RESTful JSON API
- Bi-directional replication
CouchDB
- JSON Document
- MVCC
- RESTful
- CRUD
- Suddenly server restarting does’t affect CouchDB
- VIEWS
- Secondary Index
- INCREMENTAL INDEXES
- REPLICATION
- peer-based, bi-directional replication using normal HTTP
- “ground computing” : offline replication
- MULTI-COUCH SETUPS
- Master-slave
- Master-Master
- Rubust Multi-Master
- CONFLICTS
- リビジョン管理により、コンフリクトが発生したときのデータをすべて保存しておける
BigCouch
- “Without the clustering, it’s just OuchDB”
- What is ‘Scaling’
- Horizontal Scaling
- Transparent to the application
- NO SPOF
- BigCouch -> Couch + Scaling
- Inspired from Dynamo
- on github
- Best Practice for BigCouch
- Fractral Scaling
- Paraphasing the crowd
- Many cons will be improved, improving
- External Indexers : CouchDB-Lucene
- ad-hoc query
- Mobile Couch by CouchOne
- 2GB free account on cloudant
Q&A
- Differences between MongoDB and CouchDB
- CouchDB : MVCC
- MongoDB : Update
- How about Ad hoc query in CouchDB ?
- CouchDB-Lucene
- Views
- pre-processing query
Summary
- RESTful APIであるところが特徴
- HTTP でアクセスするという点が他と違う
- “ground computing”が革新的かも
- BigCouch を使えばクラスタリングができるのかな
- Clustering はまだまだという感じ
- RESTful アクセス以外に弱いのかもしれない
Apache Hadoop and HBase @ cloudera
- Data is everywhere / Data is important
- Data analytics is important
- Are you throwing away data?
- Log/SQL log/etc. are throwed out?
Hadoop
- HDFS, Map/Reduce
- A Typical Look
- 5-4000 comodity servers
- 8-core, 24GB RAM, 4-12TB, gigabit-E)
- Cluster nodes
- Master nodes
- NameNode for metadata server and database
- JobTracker for scheduler
- Slave nodes
- Saving file -> Nama node splits a file -> Save each of splitted file data to 3 DataNodes
Map/Reduce
- map, reduce function
- map
- (k, v) -> (k’, v’)
- reduce
- (k, v1) , (k, v2) -> (k, v1+v2)
Hive
- Add SQL support to Hadoop
HBase
- open source, distributed, map
- like BigTable
- HBase = HDFS + random read/write
- MVCC of row/colun
- Consistency over Availability
- Great Hadoop integration
- Ordered range partitions
- Automatically shareds/scales
- Sparse column storage
Q&A
- HBase はリアルタイムウェブで使える？
- 使える。Facebook でもそのうちリリースされる
- Switch について
- ???
Summary
- Hadoop は大量のデータ処理に向いている
- Hive は Map/Reduce をSQLでやる試み
- HBase は BigTable のような NoSQL
世田谷区在住のエンジニア。主に Ruby on Rails でのサービス開発とインフラ設計とか負荷分散とか、いろいろやってます。
