NOSQL AFTERNOON JAPAN in Rakuten

と言うわけで、先週の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>
 
comments powered by Disqus