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

 

TweetSqueezeからはaptでパッケージをとれるそうですが、Lennyではまだなので公式サイトにあるとおりにインストール。

あとはmongoというInteractive Shellがあるので、それで接続確認して終わり。パッケージあると便利だなぁ、やっぱ。

 

Tweet

ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜

• 2010/07/23(金)
• オプトさんの例のセミナー
• GREEのCTOの人
• ソーシャルアプリでNoSQL(KVS)の話
• KVSの利用者は少ない？ 2/3ぐらい
• 副題 : 如何にして5キーに耐えるか
• NoSQL = Not Only SQL
• 世にプロダクトはたくさんある
• それぞれさまざまな特性がある(オンメモリ、分散、性能、実績などなど)
• デファクトスタンダードがないので乱立？
• それ MySQL(Drizzle) でできるよ
• それでもいいんじゃないかと思ってます
• NoSQL と言い出すまでの歴史
• 1998 年ぐらいから言われ始めたらしい
• 第一期 : RDBMS でいいよね期
• 最初はポスギレが多かった
• 第二期 : memcached も便利だよね期
• まあセッションとかも使い始めたところ
• 第三期 : やっぱりスケーラビリティだよね期
• mixi などでの分散とか
• sharding
• JOIN できない＞＜
• トランザクションできない＞＜
• 複雑なSQL書いたら怒られた＞＜
• RDBMS の機能を余り使っていない
• Relationa じゃないよね
• 第四期 : 全部 RDBMS じゃなくてもいいよね期
• たぶんいまここ
• NoSQLのデータモデル
• 1 : 1
• ハッシュテーブル
• 一番シンプル
• kumofs / Flare / Voldemort とか
• パフォーマンス / 安定性 / sharding / replication / Failover
• サーバを追加すると自動で負荷が分散されたりする
• メソッドとか
• set / get / delete
• add / replace / cas の違いとか
• add -> INSERT
• replace -> UPDATE
• cas -> compare and swap (version 管理して意図しない上書きを抑制できる)
• incr / decr -> increment / decrement
• append /prepend
• vector clock
• consistency を確保するための仕組みらしい
• 何かしらの指標によって、replication の失敗を発見して、回復しようとする仕組み？
• consistency policy
• serialized object
• multi get problem
• disk i/o -> tmpfs
• sparse file problem
• 実例
• 複数のデータを一気にとるときに大変
• 100パラメータ x 100ユーザ x 100アクセスとか
• serialize する？
• get は1回
• 並列すると conflict -> CAS
• 更新合戦になると大変 -> ある程度であきらめる
• 値でのランキングとか
• 要するに集計したい
• 全データを dump する
• あんまりすぎる
• 適当なタイミングで RDBMS に flush
• 一番無難
• 集計系はリアルタイム性がなくても大丈夫だから
• あとでやってみよう
• だいたい in memory での運用
• MMORPG とか
• オンメモリでいろいろやって、レベルアップとかのタイミングでデータベースに flush するそうな
• 1 : n
• Redis / Casandra
• Redis
• 1 : 1
• List
• Set (Hash)
• 便利になるが、パフォーマンスリスクが高い
• さらに table っぽく
• Casandra
• Keyspace.ColumnFamiry.Key.Column
• 多重Hashのような
• バイナリログ + メモリテーブルのような感じ
• m : n
• Key の prefix search がしたい！
• 解決法？
• Index Server
• Ring w/ Sorted Key
• Skip Graph ?
• value で検索したい！
• DataStore でできてるよ？
• index をKVSに置いている
• MongoDB
• Power Play っぽい？
• 各ノードから検索してマージして持ってくる
• RDBMS との使い分けも考えてみるのがいいと思っているらしい
• Casandra / Redis の好きじゃないところ
• 自動分散ができない？
• master/slaveにはできるがslaveに書き込めたりする
• GREE では？
• Flare(1:1)のものだけ
• serializeに適切なフォーマットは？
• GREEはPHPなので…
• 多言語ならMessagePackとかいいんじゃないでしょうか