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