Not only SQL

今日のお題

● NoSQLというデータベースの話です● 前提知識

○ "NoSQL"というDBがあるわけではありません

○ 主にMySQLを始めとするリレーショナルデータベース管

理システム（RDBMS）以外のデータベース管理システム

（DBMS）が"NoSQL"と総称されています

○ NoSQLは"Not only SQL"の略称ですが、

実情はデータモデルにリレーショナルモデル（関係モデ

ル）を採用していないDBMSの総称です

まずはここだけおさえておいてください。

今日覚えてほしいこと

● データベース = MySQLではないということ

● MySQL以外にも様々なデータベースが存在するということ

注意事項

わかりやすく伝えるために（実際は時間がないことと私の貧弱なプレゼンテーション能力の影響が支配的なのですが・・・）

これからひどく極端な事例や説明

に直面することが予想されます。スピード感ですのでご了承ください。

今日はこんな感じで進めます● そもそもデータベースって何？

○ RDBMSと歴史の話○ NoSQLと呼ばれる

データベースの誕生● NoSQLの分類

○ データモデルと動作特性● で、NoSQLって使えるの？

そもそもデータベース

って何？

そもそもデータベースって何？

飽くまでもリレーショナルデータベース的な模範解答

そもそもデータベースって何？

● 極論を言えば都合のいいグローバル変数 NoSQLの成功は1:10問題にかかっている Kenn's Clairvoyance - CNET Japan http://japan.cnet.com/blog/kenn/2010/09/20/entry_27042323/

○ 「データベース」が提供するものは「プログラムから都合よく使えるグローバル変数」

○ 都合よく使えるグローバル変数（=データベース）を管理するシステムがデータベース管理システム（DBMS）

そもそもデータベースって何？

● さて、「都合がいい」とは？○ レイテンシ :0s○ スループット :∞○ 絶対にデータが壊れない○ 一貫性をもったデータ処理

理想的なDBMSに求められること

無理

http://jigokuno.img.jugem.jp/20110921_2258573.gif

そもそもデータベースって何？

● 現実的な路線で「都合がいい」を考えてみた

コッドさんがとても便利な関係モデルを作って、それはやがて純粋な形ではありませんが

RDBMSになりましたhttp://en.wikipedia.org/wiki/Edgar_F._Codd

関係モデルとは？

要はこういうものを実現できるデータモデル

関係モデルとは？

興味があればコッドの12規則（コッドさんが提唱したDBMSがRDBMSとして認められる基準）などを調べてみてください規則 0 システムは、「関係に基づく」「データベース」を「管理するシステム」としての条件を備えていなければならない規則 1 情報の規則 データベースに格納されるあらゆる情報は、ただ一つの方法で表現されなければならない。規則 2 アクセス保証の規則 あらゆるデータへのアクセスには曖昧さがあってはならない。規則 3 null値を体系的に扱う システムは、あらゆる列において null値（もしくは空値）を格納できなければならない。規則 4 関係モデルに基づいた動的なオンラインカタログ システムは、カタログ（データベースの構造の情報）を、関係モデルに基づいて提供しなければならない。規則 5 強力な、データを扱う言語の規則 システムは、少なくとも 1種類の、関係を扱う言語を提供しなければならない。規則 6 ビュー更新の規則 システムは、理論的に更新可能なビューを、更新できるようにしなければならない。 規則 7 高水準の挿入、更新、削除 システムは、集合（複数行）単位でのデータの挿入、更新、削除の演算機能を提供しなければならない。 規則 8 物理的データ独立 データベースの物理的な水準における変更（ハードウェアやデータの格納方法の変更）をしても、そのデータベースを使うアプリケーションを変更する必要がないようにしなければならない。 規則 9 論理的データ独立 ビューを使うことで、データベースの論理的な水準における変更（表や列などの変更）をしても、そのデータベースを使うアプリケーションを変更する必要がないようにすることができなければならない。 規則 10 整合性の独立 整合性制約を、アプリケーションが関与することなく、定義してカタログに制約情報を格納できなければならない。規則 11 分散の独立 データベースをいくつかの場所に分割して分散した形で構成する場合、データベースの利用者がデータベースの分散を意識せずに利用できなければならない。規則 12 破壊防止の規則 システムが低水準のインタフェース（行単位のアクセスなど）を提供している場合、そのインタフェースを通したアクセスによってシステムが破壊されることが無いようにしなければならない。

http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%83%E3%83%89%E3%81%AE12%E3%81%AE%E8%A6%8F%E5%89%87

そもそもデータベースって何？

Q : そういえば、 これいつの話ですか？

A : 1960年台から1970年台

コンピュータ史の時間● 1940年台

○ コンピュータにプログラムが内蔵できるようになった

● 1950年台○ 商業用途で計算機が使われ始める

● 1960年代○ 初めてコンピュータがネットワークで繋がった

● 1970年台○ C言語の誕生

● 1980年台○ WWWの登場

● 1990年台○ インターネットの商用利用開始

ここ

コンピュータ史の時間

● 関係モデルが提唱された時期にはインターネットはおろか、コンピュータがようやくネットワークでつながり始めた時代

● 一方その頃、現代では・・・

http://www.couchbase.com/why-nosql/nosql-database

コンピュータ史の時間

● データベースへの新たな要求○ Webサービスが流行ったおかげでDBに

同時1000書き込みしなくちゃいけないんだけど、MySQLだと落ちちゃうんだよね

○ 冗長性と可用性を考えると、分散コンピューティングシステムにDB乗せたいよね

● 関係モデルはモデルなので、こんなことは考慮しません(´・_・｀)

RDBMSじゃ歯がたたなかった事例

ECサイトをたちあげておかげさまで大繁盛です

評判いいですねーちょっと取材させてください

注文多すぎでDBが落ちてECサイトも落ちた・・・せっかくのチャンスが・・・

＿人人人人人人人人人人人＿

＞　突然の大量アクセス　＜

￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

TVで見ました！

vipからきますた

俺も欲しい！

雑誌で読みました！ください！

RDBMSが直面した問題とは

● 大量の同時書き込みに応えられない○ RDBMSではデータの一貫性は

とても大事なこと○ データの一貫性を担保するための排

他制御の機構は書き込みリクエストを待たせてしまう

○ 待ち行列が発生して、このまま待ち続けて死ぬRDB開発者におくるNoSQLの常識（5）：RDBとNoSQLのデータ書き込み法の違い (1/3) http://www.atmarkit.co.jp/ait/articles/1106/23/news117.html

RDBMSが直面した問題とは

● 分散システムと相性が悪い○ 分散システムではマシンやデータを

分散配置によって、データの冗長性やシステムの可用性を実現する

○ データが分散していると、データの原子性、一貫性の保証は困難

○ 分散システムに乗せにくいので、RDBMSはスケールアウトさせにくい※一応、MySQL Clusterなどはありますが・・・

スケールアップとスケールアウト

:Mr.1人月

:Mr. 4人月

4人月の仕事があらわれた！納期は1ヶ月！

:Mr. 1人月 × 4

スケールアップ スケールアウト

スケールアップとスケールアウト

:Mr.1人月

:Mr. 1000人月

1000人月の仕事があらわれた！納期は1ヶ月！

Mr. 1人月: × 1000

1000人を用意すればいける・・・！（？）そんな人

どこにいるの？スケールアップじゃ無理だよね？

ここまでのまとめ

● データベースとは極論を言えばプログラムから都合よく使えるグローバル変数のようなもの

● 現実的な路線で「都合よく使える」DBMSとして、関係モデルを採用したRDBMSが作られた

● しかし最近では関係モデルが作られた時代には存在しなかった問題が現れてきた

これからの概要

● RDBMSじゃ歯が立たないなぁー

関係モデルを捨てて、

今直面している問題を解決できるDBMSを作ろう

● Amazonが作ったDynamoが良い事例

ハードウェアでがんばろう

● インメモリDBなど

引き続きコンピュータ史の時間

● 先ほどの歴史は歴史の1つの側面であって、別の歴史の1側面ではハードウェアが格段に進歩したりもしました

メモリがすげー安くなったから

富豪的にメモリ使えるぞー

メモリに全部乗っけちゃうインメモリDBという力技も

インメモリDBという回答

● 乱暴に言えば「メモリに全部のっけちゃえばディスクI/Oのオーバーヘッド解消できるよね」という方法論

● インメモリDBというくくりでは、データモデルは制限されない（関係モデルもキーバリューストアもあるんだよ）

● この界隈で最近イケてるのはVoltDB○ インメモリでACID（←わからなかったら調べ

よう）準拠のRDBMS○ スケーラビリティも高可用性もあるんだよ

関係モデルを捨てるという回答

Amazonの事例がわかりやすいので

紹介します

Amazon.comとDynamo

● 皆さんご存知Amazon.comは巨大ECサイト、ECサイトではシステムのダウンが大きな損失を招きます。

● 巨大ECサイトのDBがRDBMSだった場合・・・○ DBが大量のリクエストに応えられない

○ DBが落ちると復旧が大変

○ スケールアウトさせにくい

Amazon.comとDynamo

● Amazon.comが抱えるデータを考えてみる○ ベストセラーリスト、ショッピングカート、カスタ

マー設定、セッション管理、セールスランク、製品カタログ・・・

○ 「ここのデータって主キーから単一の値を引ければ十分だし、RDBMS要らなくね・・・？」「キーとバリューだけで十分ですよ！わかってくださいよ！」

○ ※ただし在庫データは除く○ むしろこのデータ扱うのにRDBMS使って

パフォーマンス犠牲にしてるの著しく無駄？

Amazon.comとDynamo

● 巨大ECサイトに必要なDBの要件○ 低レイテンシ（リクエストの応答が超速い）○ 関係モデルは不要

■ むしろこの要件には邪魔なだけ■ キーバリューストア（KVS）で十分

○ スケールアウト可能な分散DB■ つまりDBの能力が足りなくなったら、

サーバを付け足せば能力を増強できる○ 高可用性を担保できる分散DB

■ 分散DBのサーバの一部が死んでもサービスは生き続ける⇒落ちないECサイト

Amazon.comとDynamo

● そんなDB"Dynamo"をAmazonは作っちゃった● Dynamoが得たもの

（Dynamoに必要だったもの）○ ノードが死んでも動き続けるしぶとさ

■ 単一障害点がなく、クラスタが最後の1台になるまで死に絶えても動く

○ 99.9%のread/writeを300ms以内で実行するパフォーマンス■ そもそもAmazonのパフォーマンス目標

○ スケーラビリティ■ 性能足りなくなったらノード追加すればおk

Amazon.comとDynamo

● Dynamoが捨てたもの（Dynamoには不要だったもの）○ トランザクションやデータの原子性

■ マスターが存在しないP2P型なので・・・■ 「結果整合性」で勘弁して下さい

○ 範囲検索など■ データは複数のノードに一様に分散して

いるので、DB側でデータがソートされていない。なのでソートされたデータをまるっと持ってくるようなことは苦手

Amazon.comとDynamo

● Dynamoが捨てたもの（Dynamoには不要だったもの）○ SQLのような問い合わせ言語

■ そもそも関係モデルを採用していないので、関係計算はできません

■ （関係演算っぽいことを自前で実装すれば似たようなことができないわけでもない）↑よく車輪の再発明とか言われますね・・・

モダンなNoSQLの誕生

● 色々と切り捨てたので、今まで出来なかったことが出来るようになった

● Dynamoに限らず、NoSQLなDBは特定用途に特化して作られていたりもするので、合わない用途ではExcelで方眼紙を描くように合わない

モダンなNoSQLの誕生

● Amazonが巨大ECサイトのためにDynamoを作り上げたように、様々な要件で関係モデルを切り捨ててRDBMSには不可能な要件を実現できるDBが生まれた

● たとえばGoogleの場合○ Googleは大量のデータを手早く解析した

かったので、スループットとデータの一貫性を担保したスケーラブル列指向DBとしてBigTableを作った

モダンなNoSQLの誕生と進化

Dynamo

BigTable

Cassandra

Voldemort

Riak

HBase

mongoDB

HyperTable

Redis

Google

Amazon

Dynamoの動作特性とBigTableのデータモデルに基づく列指向DB

Dynamoベースのドキュメント型DB

Dynamoクローン

ドキュメント型DB

BigTable互換プロジェクト

BigTableをモデルとする

CouchDB

CouchbaseMemcached

ドキュメント型DB

ドキュメント型DBKVS

※独断と偏見に基づきます

NoSQLの分類

NoSQLの分類

● さきほどたくさんのNoSQLなDBMSが色分けされて出て来ましたが・・・

● NoSQLなDBMSは以下の観点で分類できます○ データモデル

■ 関係モデルを採用していないといっても代替のデータモデルはたくさんある

■ といっても基本はキーバリューストア○ 動作特性

■ 特に分散DBの場合は顕著な違いが■ 乱暴に言えば、分散DBを構成するサーバ

やネットワークが壊れた時に、どのような動作をするかの違い

NoSQLの分類

● NoSQLなDBMSをデータモデルで分類する○ ざっとした感じ

RDB的なデータの扱いNoSQL的なデータの扱い(※図はドキュメント指向の場合)

http://www.couchbase.com/why-nosql/nosql-database

NoSQLの分類

● NoSQLなDBMSをデータモデルで分類する○ キーバリュー型

■ キーとバリューのペアで構成されるデータモデル■ phpの連想配列やPythonの辞書と思えば良い

○ 列指向■ ちょっとリッチなキーバリュー型

■ 連想配列の中に連想配列が入っているような

入れ子構造のデータモデルをDBでサポートする○ ドキュメント指向

■ ドキュメントと呼ばれるJSONライクなデータ形式○ グラフ型

■ グラフ構造のノードとリレーションにデータを格納

NoSQLの分類

● キーバリュー型○ Dynamo○ Voldemort○ Redis○ Memcached

● 列指向○ BigTable○ HBase○ Cassandra

● グラフ型○ Neo4j

● ドキュメント指向○ mongoDB○ Riak○ CouchDB○ Couchbase

有名所をデータモデルで分類してみると・・・

NoSQLの分類

● NoSQLなDBMSを動作特性で分類する○ 分類の前にCAP定理のお勉強が必要です

○ CAP定理とは？■ 分散コンピューティングシステムの

あるあるネタ■ 定理とか言ってるけどただの経験則

（たしかこれを証明したとかいう論文が出たような）

NoSQLの分類● CAP定理

○ 分散コンピューティングシステムは、以下の3つの特性を2つ以上満たすことはできません（遅延の発生が許容されない場合）■ Consistency:一貫性

● 全てのノードにおいて同時に同じデータが見える

■ Availability:可用性● ノードが壊れてもシステムが動き続ける

■ Partition tolerance:分断耐性● ネットワーク障害でノードが分断されても

システムは動き続ける

NoSQLの分類

{a:123} {a:123}ノード1 ノード2 {a:123} {a:122}ノード1 ノード2

一貫性が満たされている 一貫性が満たされていない

可用性が満たされている 可用性が満たされていない

分断耐性が満たされている 分断耐性が満たされていない

Availability:可用性

Partition tolerance:分断耐性

Consistency:一貫性

NoSQLの分類

● CAP定理○ たとえばConsistencyを捨てれば・・・

■ ノード間で通信できなくても、ノードの一部がダウンしても動き続けるようなDBを作れる

■ が、複数のノードに分散したデータの一部は更新されずに古いデータのままになっているかもしれない

NoSQLの分類

● CAP定理○ たとえばAbailabillityを捨てれば・・・

■ ノード間で通信できなくても、データの一貫性は確保されるようなDBを作れる

■ が、データの一貫性を保つために、通信できないノードをクラスタから除外して、DB全体の処理能力が落ちることもある

NoSQLの分類

● 可用性友の会（APを選択）○ Dynamo○ Voldemort○ Riak○ Cassandra○ CouchDB○ Couchbase

● 一貫性原理主義（CPを選択）○ BigTable○ HyperTable○ HBase○ mongoDB○ Memcached○ Redis

● 分断はちょっとムリ派（CAを選択）○ RDBMS

有名所を動作特性で分類してみると・・・

Visual Guide to NoSQL Systems | Beany | Beanyhttp://blog.beany.co.kr/archives/275

NoSQLの分類

● データモデルやCAP定理的分類以外の観点○ たとえばDBMSがサポートする機能

■ 同じ動作特性でもREST APIがあったりなかったり

■ SQL的な問い合わせ言語がサポートされていたり

■ 行ロックができるかできないか■ HBaseはHadoopファミリーの恩恵に預か

れたり

NoSQLの分類

● データモデルやCAP定理的分類以外の観点○ たとえばデータがディスクに書き込まれるタイ

ミング、CassandraとCouchbaseは非常に似ているが・・・■ Cassandraはデータを書き込むとき、

まずディスクに書き込んでからメモリにも書き込む

■ Couchbaseはデータを書き込むとき、まずメモリに書き込んでからディスクにも書き込む

■ 「DBが落ちた瞬間に書き込まれたデータは？」

で、NoSQLって使えるの？

で、正直なところNoSQLって使えるんすか？

● 用途と使い方による○ 向いてない用途にNoSQL使うと、

「とりあえずデカいサーバでMySQL使っとけ」という状況以上にヤバい状況になると思う

で、正直なところNoSQLって使えるんすか？

● 向いてない用途にNoSQL使う事例○ Cassandraでアクセスカウンタ

http://d.hatena.ne.jp/amanar/20110109/1294570753

カウントできてない

で、正直なところNoSQLって使えるんすか？

● あと結構カネはかかるよ○ 大量の書き込みリクエストに答えられ

る能力もインフラが貧弱だとそもそも無理だったりする

○ RDBMSに大量のカネをつぎこんでも解決できない状況でも、NoSQLに大量のカネをかければ別のやり方で解決できます、と捉えていただければ

金食い虫なNoSQL

Cassandraの例● 6コアマシンを3台くらいの冗長構成にして

おけば、秒間で3000書き込み位いける

● あとは性能が足りなくなればノードを追加すればDB全体の性能も向上する○ 300ノードまで線形でスケールする事例

http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

金食い虫なNoSQL

● 6コアマシンって1インスタンスあたり月額数万円とかするんですが・・・○ ノードつけたせば性能上がるといって

もねぇ・・・● ケチって1台でクラスタ組んでも冗長性

が得られないし・・・● でも他のDBじゃ無理だし・・・

金食い虫なNoSQL

往々にしてNoSQLなDBMSは、カネさえ用意すれば望みを叶えてくれる

「カネを積んでも解決できない」という事態よりは大分マシ

で、正直なところNoSQLって使えるんすか？

● 運用もそこまで楽じゃない○ 「単一障害点無いヤッター」と思って

も落とし穴はいたるところにある

なんで単一障害点ないのに死んでしまうん？

またCassandraの事例ですが何か？

　 　 　　　＿＿＿_

　 　　　／⌒　　⌒＼

　　　／（ ●） 　（●）＼

　 ／::::::⌒（__人__）⌒::::: ＼ 　　マルチノードで3レプリカだから

　 |　　　　　|r┬-|　　　　　| 　　　ノードの1台や2台ダウンしても平気だお！

　 ＼ 　　 　 `ー'´ 　 　 ／

なんで単一障害点ないのに死んでしまうん？

ディスクストレージがすべてダウン⇒すべてのノードでデータ書き込み不能

　 　 　　　＿＿＿_

　 　　　／　　 　 　＼

　　　／　 _ノ 　ヽ､_　 ＼

　 ／ oﾟ(（●）) (（●）)ﾟo ＼ 　全部のノードが生きていてるのに

　 |　　　　 （__人__）　　　　| 　 全部のノードでディスクに書き込めないんだお・・・

　 ＼　　 　 ｀ ⌒´ 　 　 ／

なんで単一障害点ないのに死んでしまうん？

【原因と結果】すべてのノードで使用していたディスクストレージが同じ物理リージョンに存在していたので、単一の物理リージョンの障害がすべてのノードに影響し、すべてのノードが事実上ダウンした

なんで単一障害点ないのに死んでしまうん？

こうしておけばよかった

:物理リージョンA　

:物理リージョンB

なんで単一障害点ないのに死んでしまうん？

レプリカ数は3

:物理リージョンA　

:物理リージョンB

同じデータのコピーが隣接する3ノードに存在する

a

a,b

a,b,c

b,cc

データaのレプリカ

データbのレプリカ

なんで単一障害点ないのに死んでしまうん？

ここで物理リージョンBがダウンした場合

:物理リージョンA　

:物理リージョンB

物理リージョンAのノードは稼働を続け、データのレプリカは最低1個存在

a

a,b

a,b,c

b,cc

データaのレプリカ

データbのレプリカ

なんで単一障害点ないのに死んでしまうん？

説明をかなり省いたので、ぶっちゃけわかりにくかったと思います

そう、わかりにくいんです

わかってる人がいないとマトモに運用できません

それはさておきNoSQLなDBMSの利用事例

● 主に2通り

LAMP構成のシステムのキャッシュやセッション管理に使われる場合● 主にmemcachedや

redisなどが利用される● サービスごとに立てられ

ていたmemcachedが、全てのサービスで1つのCouchbaseクラスタにリプレイスされる事例も

RDBMSが不要、もしくは邪魔な場合● いわゆるデータの

永続化を前提としたNoSQLの利用

● たとえばAmazonのDynamo

ウケがよさそうなNoSQL利用事例をピックアップしてみました

● HBase○ FacebookやLINEのメッセージング

● Cassandra○ Twitterの一部機能（RT数のカウントなど）○ 他にもDisneyやAdobe、NetFlixなどなど

● Riak○ Bump, Yammer

● mongoDB○ 4square

ウケがよさそうなNoSQL利用事例をピックアップしてみました

● M2M界隈○ 聞きなれていないと思うが

M2MとはMachine 2 Machine○ スマートメーターとかスマートグリッドとか、

マシンの情報を集めたり分析する領域○ 日本中の電力メーターから送られたデータを

DBに書き込まなければならないとしたら？■ DBにスケーラビリティと高可用性は必須■ 同時に書き込みリクエストがたくさんくる■ CassandraとかRiakが得意な領域■ トランザクションは要件と設計次第

NoSQLの利用事例も結構あるので、NoSQL有りきの設計思想も出てきています

Not only SQLな設計思想Polyglot Persistence

● かいつまんで言うと、「DBMSと言っても色々あるけど、それぞれに得手不得手があるから向いている用途に向いているDBMSを使おう」という設計思想。

Not only SQLな設計思想Polyglot Persistence目的によって道具を使い分ける例（あるいは道具が目的に応じて発達した例）

人を運ぶため

速く走るため

モノを運ぶため

http://en.wikipedia.org/wiki/File:Keiseibus-twinbus-20071013.jpg

http://en.wikipedia.org/wiki/File:Ayrton_Senna_1988_Canada.jpg

http://en.wikipedia.org/wiki/File:200_Ton_Truck.JPG

Not only SQLな設計思想Polyglot Persistence

http://martinfowler.com/bliki/PolyglotPersistence.html

DBの場合では・・・

Not only SQLな設計思想Polyglot Persistence

● Polyglot Persistenceの欠点 = 敷居が高い

http://jigokuno.img.jugem.jp/20111102_2307210.gif

Not only SQLな設計思想Polyglot Persistence

● なぜPolyglot Persistenceの敷居が高いのか？○ たくさんのDBMSについてデータの一貫性や

永続性、ネットワークが分断した時のクラスタの挙動や単一障害点の存在などのインフラ面の性質を理解した上で、アプリとしてレンジクエリやインデキシングの可否や性能要件などを満たす適切なDBMSを選択し、かつ真っ当な設計が可能な上でそれらのDBMSの運用が可能でなければ、あれその前にこの提案って通るんですかね・・・？真面目に考えると

このくらいダルい

Not only SQLな設計思想Polyglot Persistence

● 「DBMSと言っても色々ある」と言いましたが「色々ある」の実情とは？○ データの一貫性はどうなってるの？○ データの永続性はどうなってるの？○ ネットワークが分断した時の

クラスタの挙動は？○ 単一障害点はある？○ レンジクエリできる？○ インデックスはれる？

ココらへんを全部おさえていないと適切なDBMSが選択できない・・・

Not only SQLな設計思想Polyglot Persistence

Pinterestの事例

Polyglot persistence at Pinterest: Redis, Membase, MySQL • myNoSQL : http://nosql.mypopescu.com/post/17658415847/polyglot-persistence-at-pinterest-redis-membase

"Memcached and membase / redis for object- and logical-caching, respectively"

"Persistent data storage using MySQL"

Not only SQLな設計思想Polyglot Persistence

Dynamoの利用が最適な箇所

Dynamo以外のデータストアの利用が最適な箇所

Service-oriented architectureシステムを「サービス」の集まりとして構築する設計

Amazonの事例

Amazon's Dynamo - All Things Distributed : http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

Not only SQLな設計思想Polyglot Persistence

どんなことでもそうですが、Polyglot Persistenceは正しく使えば非常に強力

正しく使いたい人向けに、NoSQLの勉強ができる参考文献集を用意しました

（抽象的なお話が多めの）参考文献集

● AmazonのCTOが書いたDynamo論文をまとめた記事AmazonがRDBMSからDynamoへ移行した経緯から Dynamoの特性、サービス指向アーキテクチャまでまるっと味わえる良記事　 オススメ！All Things Distributed - All Things Distributed : http://www.allthingsdistributed.com/

○ 有志による日本語訳もあるでよ■ Dynamo: Amazonの高可用性Key-value Store[和訳] : https://gist.github.

com/matope/2657692■ Amazon Dynamo論文 - LunaBiblos : http://lunarium.info/arc/index.

php/Amazon_Dynamo%E8%AB%96%E6%96%87

● Polyglot Persistenceについての（Webで読める実質唯一の）まとまった文章PolyglotPersistence : http://martinfowler.com/bliki/PolyglotPersistence.html

● NoSQL系の記事が充実している海外ブログ（ NoSQLの動作を勉強したかったらココ）Highly Scalable Blog | Articles on Big Data, HPC, and Highly Scalable Software Engineering : http://highlyscalable.wordpress.com/

● 現実的なCAP定理についての総論12年後のCAP定理: "法則"はどのように変わったか : http://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed

● いつ使うの？今でしょ！的なノリだが、 RDBMSとNoSQLの長短が歴史を踏まえて語られている記事What is NoSQL Database & Why NoSQL | Couchbase : http://www.couchbase.com/why-nosql/nosql-database

（具体的な文章が多めの）参考文献集

● 「実際どのくらい性能出るのよ？」○ Cassandra, mongoDB, Couchbase, Aerospikeについての性能比較

http://www.aerospike.com/wp-content/uploads/2013/01/Ultra-High-Performance-NoSQL-Benchmarking.pdf

○ Cassandraノードを約300台までスケールさせた場合の性能についてThe Netflix Tech Blog: Benchmarking Cassandra Scalability on AWS - Over a million writes per second : http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

● Cassandraを例に、どのようにデータの read/writeが行われるのか、一貫性レベルによる挙動の違いなどについて（ちょっとバージョンは古いが）まとめられている資料Cassandraのしくみ データの読み書き編 : http://www.slideshare.net/yukim/cassandra-3885571

● YammerでのRiak利用事例http://basho.co.jp/assets/Yammer-Case-Study.pdf

● デンマークの医療系システムでの Rak利用事例http://basho.co.jp/assets/Trifork-Case-Study.pdf

● 忍者ツールズのCouchbase導入事例 : http://www.slideshare.net/tsunokawa/couchbase-16775489

● HBase at LINE : http://www.slideshare.net/sunsuk7tp/hbase-at-line● facebookがメッセージングアプリの基盤に HBaseを採用した経緯の日本語訳

Facebook の HBase は、毎月 1350億 メッセージを処理する！ | Agile Cat --- in the cloud : http://agilecatcloud.com/2010/11/18/facebook-%E3%81%AE-hbase-%E3%81%AF%E3%80%81%E6%AF%8E%E6%9C%88-1350%E5%84%84-%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%92%E5%87%A6%E7%90%86%E3%81%99%E3%82%8B%EF%BC%81-cloud-cloudcomputing/

課題

以下のクラスの課題を最低1つやってきてください課題の解答形式は問いませんが、Yammer上でToshikazu Nakamuraにリプってください

● たまごクラス● ひこよクラス● にわとりクラス（ひよこクラスの発展課題）● フライドチキンクラス

● たまごクラス（所要時間0.5hくらい・・・？）○ CassandraとHBaseはどちらも複数のノードで

データを分散して取り扱います。ですが特定のデータをどのノードで取り扱うのかについての規則は大きく異なります。以下について調査して報告してください。■ CassandraとHBaseは、データを複数の

ノードにどうのように分散（分割）させているのか※どちらもデフォルトの設定が対象です

■ CassandraとHBaseのデータの分散のさせ方の違いは、それぞれのDBMSが提供する機能にどのように影響しているのか※両者のメリット、デメリットとかでもいいです

● ひよこクラス（構築に手間取らなければ1h）○ 任意の環境にCouchbaseをインストールして、

サンプルのbeer-sampleデータ（ビールの銘柄と醸造所のデータ）を眺めてみましょう

○ デフォルトで設定されているMap関数を走らせて、データへの操作を行なってみましょう

● にわとりクラス（ひよこクラスができれば10min）○ ひよこクラスの発展課題です○ ひよこクラスでインストールしたCouchbaseの環境

で、任意のデータをリスティングするMap関数を作成してください（デフォルトのMap関数を編集するだけですが、JSの関数を提出してください）

詳細は社内Wiki ( /tips/db/couchbase ) を参照

● フライドチキンクラス（複数インスタンスの用意が大変だと思うので、暇で暇でしょうがない時に気が向いたらやってみてください。あとRiakにはREST API付いているので、やるならこっちの方が楽かも？Riakならメモリ少なくてもちゃんと起動しますし・・・）

○ CassandraもしくはRiakのどちらかでマルチノードのクラスタを立ち上げ、複数のノードにデータのレプリケーションが行われる状態にしてください

○ 上記の状態で、マルチノードを構成する任意の1ノードをダウンさせ、その状態でもデータのread/writeが行えることを確認してください