Successfully reported this slideshow.

Not only sql _ 新卒エンジニア勉強会20130417

1,226 views

Published on

4月17日開催のエスキュービズム新卒エンジニア勉強会資料です。

  • Be the first to comment

Not only sql _ 新卒エンジニア勉強会20130417

  1. 1. Not only SQL
  2. 2. 今日のお題 ● NoSQLというデータベースの話です ● 前提知識 ○ "NoSQL"というDBがあるわけではありません ○ 主にMySQLを始めとするリレーショナルデータベース管 理システム(RDBMS)以外のデータベース管理システム (DBMS)が"NoSQL"と総称されています ○ NoSQLは"Not only SQL"の略称ですが、 実情はデータモデルにリレーショナルモデル(関係モデ ル)を採用していないDBMSの総称です まずはここだけおさえておいてください。
  3. 3. 今日覚えてほしいこと ● データベース = MySQL ではないということ ● MySQL以外にも 様々なデータベースが 存在するということ
  4. 4. 注意事項 わかりやすく伝えるために (実際は時間がないことと私の貧弱なプレゼンテーション能力の影響が支配的なのですが・・・) これからひどく 極端 な事例や説明 に直面することが予想されます。 スピード感ですのでご了承ください。
  5. 5. 今日はこんな感じで進めます ● そもそもデータベースって何? ○ RDBMSと歴史の話 ○ NoSQLと呼ばれる データベースの誕生 ● NoSQLの分類 ○ データモデルと動作特性 ● で、NoSQLって使えるの?
  6. 6. そもそも データベース って何?
  7. 7. そもそもデータベースって何? 飽くまでもリレーショナルデータベース的な模範解答
  8. 8. そもそもデータベースって何? ● 極論を言えば都合のいいグローバル変数 NoSQLの成功は1:10問題にかかっている Kenn's Clairvoyance - CNET Japan http://japan.cnet.com/blog/kenn/2010/09/20/entry_27042323/ ○ 「データベース」が提供するものは 「プログラムから都合よく使えるグローバル変数」 ○ 都合よく使えるグローバル変数(=データベース)を 管理するシステムが データベース管理システム(DBMS)
  9. 9. そもそもデータベースって何? ● さて、「都合がいい」とは? ○ レイテンシ :0s ○ スループット :∞ ○ 絶対にデータが壊れない ○ 一貫性をもったデータ処理 理想的なDBMSに 求められること
  10. 10. 無理 http://jigokuno.img.jugem.jp/20110921_2258573. gif
  11. 11. そもそもデータベースって何? ● 現実的な路線で「都合がいい」を考えてみた コッドさんが とても便利な 関係モデルを作って、 それはやがて 純粋な形ではありませんが RDBMSになりました http://en.wikipedia.org/wiki/Edgar_F._Codd
  12. 12. 関係モデルとは? 要はこういうものを実現できるデータモデル
  13. 13. 関係モデルとは? 興味があればコッドの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
  14. 14. そもそもデータベースって何? Q : そういえば、 これいつの話ですか? A : 1960年台から1970年台
  15. 15. コンピュータ史の時間 ● 1940年台 ○ コンピュータにプログラムが内蔵できるようになった ● 1950年台 ○ 商業用途で計算機が使われ始める ● 1960年代 ○ 初めてコンピュータがネットワークで繋がった ● 1970年台 ○ C言語の誕生 ● 1980年台 ○ WWWの登場 ここ ● 1990年台 ○ インターネットの商用利用開始
  16. 16. コンピュータ史の時間 ● 関係モデルが提唱された時期には インターネットはおろか、 コンピュータがようやくネットワークで つながり始めた時代 ● 一方その頃、現代では・・・ http://www.couchbase.com/why-nosql/nosql-database
  17. 17. コンピュータ史の時間 ● データベースへの新たな要求 ○ Webサービスが流行ったおかげでDBに 同時1000書き込みしなくちゃいけないんだけ ど、MySQLだと落ちちゃうんだよね ○ 冗長性と可用性を考えると、 分散コンピューティングシステムにDB乗せた いよね ● 関係モデルはモデルなので、 こんなことは考慮しません(´・_・`)
  18. 18. RDBMSじゃ歯がたたなかった事例 ECサイトをたちあげて おかげさまで大繁盛です 評判いいですねー ちょっと取材させてください _人人人人人人人人人人人_ > 突然の大量アクセス <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ 注文多すぎでDBが落ちて ECサイトも落ちた・・・ せっかくのチャンスが・・・ TVで 見ました! vipからきますた 俺も欲しい! 雑誌で読みまし た!ください!
  19. 19. RDBMSが直面した問題とは ● 大量の同時書き込みに応えられない ○ RDBMSではデータの一貫性は とても大事なこと ○ データの一貫性を担保するための排 他制御の機構は書き込みリクエスト を待たせてしまう ○ 待ち行列が発生して、 このまま待ち続けて死ぬ RDB開発者におくる NoSQLの常識(5):RDBとNoSQLのデータ書き込み法の違い (1/3) http://www.atmarkit.co.jp/ait/articles/1106/23/news117.html
  20. 20. RDBMSが直面した問題とは ● 分散システムと相性が悪い ○ 分散システムではマシンやデータを 分散配置によって、データの冗長性 やシステムの可用性を実現する ○ データが分散していると、データの原 子性、一貫性の保証は困難 ○ 分散システムに乗せにくいので、 RDBMSはスケールアウトさせにくい ※一応、MySQL Clusterなどはありますが・・・
  21. 21. スケールアップとスケールアウト :Mr.1人月 4人月の仕事があらわれた! 納期は1ヶ月! :Mr. 4人月 スケールアップ :Mr. 1人月 × 4 スケールアウト
  22. 22. スケールアップとスケールアウト :Mr.1人月 1000人月の仕事があらわれた! 納期は1ヶ月! そんな人 どこにいるの? スケールアップじゃ :Mr. 1000人月 無理だよね? 1000人を用意すれば いける・・・!(?) Mr. 1人月 : × 1000
  23. 23. ここまでのまとめ ● データベースとは極論を言えば プログラムから都合よく使えるグローバル変数 のようなもの ● 現実的な路線で「都合よく使える」DBMSとし て、関係モデルを採用したRDBMSが作られた ● しかし最近では関係モデルが作られた時代に は存在しなかった問題が現れてきた
  24. 24. これからの概要 ● RDBMSじゃ歯が立たないなぁー ハードウェアでがんばろう 関係モデルを捨てて、 ● インメモリDBなど 今直面している問題を 解決できるDBMSを作ろう ● Amazonが作った Dynamoが良い事例
  25. 25. 引き続きコンピュータ史の時間 ● 先ほどの歴史は歴史の1つの側面であって、 別の歴史の1側面ではハードウェアが格段に 進歩したりもしました メモリがすげー安くなったから 富豪的にメモリ使えるぞー メモリに全部乗っけちゃう インメモリDBという力技も
  26. 26. インメモリDBという回答 ● 乱暴に言えば 「メモリに全部のっけちゃえば ディスクI/Oのオーバーヘッド解消できるよね」 という方法論 ● インメモリDBというくくりでは、 データモデルは制限されない (関係モデルもキーバリューストアもあるんだよ) ● この界隈で最近イケてるのはVoltDB ○ インメモリでACID(←わからなかったら調べ よう)準拠のRDBMS ○ スケーラビリティも高可用性もあるんだよ
  27. 27. 関係モデルを捨てるという回答 Amazonの事例が わかりやすいので 紹介します
  28. 28. Amazon.comとDynamo ● 皆さんご存知Amazon.comは巨大EC サイト、ECサイトではシステムのダウン が大きな損失を招きます。 ● 巨大ECサイトのDBが RDBMSだった場合・・・ ○ DBが大量のリクエストに応えられない ○ DBが落ちると復旧が大変 ○ スケールアウトさせにくい
  29. 29. Amazon.comとDynamo ● Amazon.comが抱えるデータを考えてみる ○ ベストセラーリスト、ショッピングカート、カスタ マー設定、セッション管理、セールスランク、 製品カタログ・・・ ○ 「ここのデータって主キーから単一の値を引 ければ十分だし、RDBMS要らなくね・・・?」 「キーとバリューだけで十分ですよ! わかってくださいよ!」 ○ ※ただし在庫データは除く ○ むしろこのデータ扱うのにRDBMS使って パフォーマンス犠牲にしてるの著しく無駄?
  30. 30. Amazon.comとDynamo ● 巨大ECサイトに必要なDBの要件 ○ 低レイテンシ(リクエストの応答が超速い) ○ 関係モデルは不要 ■ むしろこの要件には邪魔なだけ ■ キーバリューストア(KVS)で十分 ○ スケールアウト可能な分散DB ■ つまりDBの能力が足りなくなったら、 サーバを付け足せば能力を増強できる ○ 高可用性を担保できる分散DB ■ 分散DBのサーバの一部が死んでもサー ビスは生き続ける⇒落ちないECサイト
  31. 31. Amazon.comとDynamo ● そんなDB"Dynamo"をAmazonは作っちゃった ● Dynamoが得たもの (Dynamoに必要だったもの) ○ ノードが死んでも動き続けるしぶとさ ■ 単一障害点がなく、クラスタが最後の1台 になるまで死に絶えても動く ○ 99.9%のread/writeを 300ms以内で実行するパフォーマンス ■ そもそもAmazonのパフォーマンス目標 ○ スケーラビリティ ■ 性能足りなくなったらノード追加すればおk
  32. 32. Amazon.comとDynamo ● Dynamoが捨てたもの (Dynamoには不要だったもの) ○ トランザクションやデータの原子性 ■ マスターが存在しないP2P型なので・・・ ■ 「結果整合性」で勘弁して下さい ○ 範囲検索など ■ データは複数のノードに一様に分散して いるので、DB側でデータがソートされてい ない。なのでソートされたデータをまるっと 持ってくるようなことは苦手
  33. 33. Amazon.comとDynamo ● Dynamoが捨てたもの (Dynamoには不要だったもの) ○ SQLのような問い合わせ言語 ■ そもそも関係モデルを採用していないの で、関係計算はできません ■ (関係演算っぽいことを自前で実装すれば 似たようなことができないわけでもない) ↑よく車輪の再発明とか言われますね・・・
  34. 34. モダンなNoSQLの誕生 ● 色々と切り捨てたので、 今まで出来なかったことが出来るようになった ● Dynamoに限らず、NoSQLなDBは特定用途に 特化して作られていたりもするので、 合わない用途ではExcelで方眼紙を描くように 合わない
  35. 35. モダンなNoSQLの誕生 ● Amazonが巨大ECサイトのためにDynamoを 作り上げたように、 様々な要件で関係モデルを切り捨ててRDBMS には不可能な要件を実現できるDBが生まれた ● たとえばGoogleの場合 ○ Googleは大量のデータを手早く解析した かったので、スループットとデータの一貫性を 担保したスケーラブル列指向DBとして BigTableを作った
  36. 36. モダンなNoSQLの誕生と進化 Memcached KVS Couchbase ドキュメント型 DB CouchDB Redis ドキュメント型 DB Voldemort Dynamoクローン Dynamo Amazon mongoDB Riak Dynamoベースのド キュメント型DB ドキュメント型 DB Cassandra Dynamoの動作特性と BigTableのデータモデル に基づく列指向 DB BigTable Google HyperTable ※独断と偏見に基づきます BigTable互換 プロジェクト HBase BigTableをモデルとする
  37. 37. NoSQLの分類
  38. 38. NoSQLの分類 ● さきほどたくさんのNoSQLなDBMSが色分けさ れて出て来ましたが・・・ ● NoSQLなDBMSは以下の観点で分類できます ○ データモデル ■ 関係モデルを採用していないといっても 代替のデータモデルはたくさんある ■ といっても基本はキーバリューストア ○ 動作特性 ■ 特に分散DBの場合は顕著な違いが ■ 乱暴に言えば、分散DBを構成するサーバ やネットワークが壊れた時に、どのような 動作をするかの違い
  39. 39. NoSQLの分類 ● NoSQLなDBMSをデータモデルで分類する ○ ざっとした感じ http://www.couchbase.com/why-nosql/nosql-database NoSQL的なデータの扱い (※図はドキュメント指向の場合) RDB的なデータの扱い
  40. 40. NoSQLの分類 ● NoSQLなDBMSをデータモデルで分類する ○ キーバリュー型 ■ キーとバリューのペアで構成されるデータモデル ■ phpの連想配列やPythonの辞書と思えば良い ○ 列指向 ■ ちょっとリッチなキーバリュー型 ■ 連想配列の中に連想配列が入っているような 入れ子構造のデータモデルをDBでサポートする ○ ドキュメント指向 ■ ドキュメントと呼ばれるJSONライクなデータ形式 ○ グラフ型 ■ グラフ構造のノードとリレーションにデータを格納
  41. 41. NoSQLの分類 有名所をデータモデルで分類してみると・・・ ● キーバリュー型 ○ Dynamo ○ Voldemort ○ Redis ○ Memcached ● ドキュメント指向 ○ mongoDB ○ Riak ○ CouchDB ○ Couchbase ● 列指向 ○ BigTable ○ HBase ○ Cassandra ● グラフ型 ○ Neo4j
  42. 42. NoSQLの分類 ● NoSQLなDBMSを動作特性で分類する ○ 分類の前にCAP定理のお勉強が必要です ○ CAP定理とは? ■ 分散コンピューティングシステムの あるあるネタ ■ 定理とか言ってるけどただの経験則 (たしかこれを証明したとかいう論文が出 たような)
  43. 43. NoSQLの分類 ● CAP定理 ○ 分散コンピューティングシステムは、 以下の3つの特性を2つ以上満たすことはでき ません(遅延の発生が許容されない場合) ■ Consistency:一貫性 ● 全てのノードにおいて同時に同じデータ が見える ■ Availability:可用性 ● ノードが壊れてもシステムが動き続ける ■ Partition tolerance:分断耐性 ● ネットワーク障害でノードが分断されても システムは動き続ける
  44. 44. NoSQLの分類 Consistency:一貫性 ノード1 {a:123} ノード2 {a:123} 一貫性が満たされている ノード1 {a:123} ノード2 {a:122} 一貫性が満たされていない Availability:可用性 可用性が満たされている 可用性が満たされていない Partition tolerance:分断耐性 分断耐性が満たされている 分断耐性が満たされていない
  45. 45. NoSQLの分類 ● CAP定理 ○ たとえばConsistencyを捨てれば・・・ ■ ノード間で通信できなくても、ノードの一部 がダウンしても動き続けるようなDBを作 れる ■ が、複数のノードに分散したデータの一部 は更新されずに古いデータのままになっ ているかもしれない
  46. 46. NoSQLの分類 ● CAP定理 ○ たとえばAbailabillityを捨てれば・・・ ■ ノード間で通信できなくても、データの一 貫性は確保されるようなDBを作れる ■ が、データの一貫性を保つために、通信 できないノードをクラスタから除外して、 DB全体の処理能力が落ちることもある
  47. 47. NoSQLの分類 有名所を動作特性で分類してみると・・・ ● 可用性友の会 ● 一貫性原理主義 (APを選択) (CPを選択) ○ Dynamo ○ BigTable ○ Voldemort ○ HyperTable ○ Riak ○ HBase ○ Cassandra ○ mongoDB ○ CouchDB ○ Memcached ○ Couchbase ○ Redis ● 分断はちょっとムリ派(CAを選択) ○ RDBMS
  48. 48. Visual Guide to NoSQL Systems | Beany | Beany http://blog.beany.co.kr/archives/275
  49. 49. NoSQLの分類 ● データモデルやCAP定理的分類以外の観点 ○ たとえばDBMSがサポートする機能 ■ 同じ動作特性でもREST APIがあったりな かったり ■ SQL的な問い合わせ言語がサポートされ ていたり ■ 行ロックができるかできないか ■ HBaseはHadoopファミリーの恩恵に預か れたり
  50. 50. NoSQLの分類 ● データモデルやCAP定理的分類以外の観点 ○ たとえばデータがディスクに書き込まれるタイ ミング、CassandraとCouchbaseは非常に似 ているが・・・ ■ Cassandraはデータを書き込むとき、 まずディスクに書き込んでからメモリにも 書き込む ■ Couchbaseはデータを書き込むとき、 まずメモリに書き込んでからディスクにも 書き込む ■ 「DBが落ちた瞬間に書き込まれたデータ
  51. 51. で、NoSQL って使えるの?
  52. 52. で、正直なところ NoSQLって使えるんすか? ● 用途と使い方による ○ 向いてない用途にNoSQL使うと、 「とりあえずデカいサーバでMySQL 使っとけ」 という状況以上にヤバい状況になる と思う
  53. 53. で、正直なところ NoSQLって使えるんすか? ● 向いてない用途にNoSQL使う事例 ○ Cassandraでアクセスカウンタ http://d.hatena.ne.jp/amanar/20110109/1294570753 カウント できてない
  54. 54. で、正直なところ NoSQLって使えるんすか? ● あと結構カネはかかるよ ○ 大量の書き込みリクエストに答えられ る能力もインフラが貧弱だとそもそも 無理だったりする ○ RDBMSに大量のカネをつぎこんでも 解決できない状況でも、NoSQLに大 量のカネをかければ別のやり方で解 決できます、と捉えていただければ
  55. 55. 金食い虫なNoSQL Cassandraの例 ● 6コアマシンを3台くらいの冗長構成にして おけば、 秒間で3000書き込み位いける ● あとは性能が足りなくなればノードを追加 すればDB全体の性能も向上する ○ 300ノードまで線形でスケールする事例 http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
  56. 56. 金食い虫なNoSQL ● 6コアマシンって1インスタンスあたり 月額数万円とかするんですが・・・ ○ ノードつけたせば性能上がるといって もねぇ・・・ ● ケチって1台でクラスタ組んでも冗長性 が得られないし・・・ ● でも他のDBじゃ無理だし・・・
  57. 57. 金食い虫なNoSQL 往々にしてNoSQLなDBMSは、 カネさえ用意すれば望みを叶えてくれる 「カネを積んでも解決できない」 という事態よりは大分マシ
  58. 58. で、正直なところ NoSQLって使えるんすか? ● 運用もそこまで楽じゃない ○ 「単一障害点無いヤッター」と思って も落とし穴はいたるところにある
  59. 59. なんで単一障害点ないのに死んでしまうん? またCassandraの事例ですが何か?        ____      /⌒  ⌒\    /( ●)  (●)\   /::::::⌒(__人__)⌒::::: \   マルチノードで3レプリカだから   |     |r┬-|     |    ノードの1台や2台ダウンしても平気だお!   \      `ー'´     /
  60. 60. なんで単一障害点ないのに死んでしまうん? ディスクストレージがすべてダウン ⇒すべてのノードでデータ書き込み不能        ____      /      \    /  _ノ  ヽ、_  \   / o゚((●)) ((●))゚o \  全部のノードが生きていてるのに   |     (__人__)    |   全部のノードでディスクに書き込めないんだお・・・   \     ` ⌒´     /
  61. 61. なんで単一障害点ないのに死んでしまうん? 【原因と結果】 すべてのノードで使用していた ディスクストレージが同じ物理リージョン に存在していたので、 単一の物理リージョンの障害がすべての ノードに影響し、 すべてのノードが事実上ダウンした
  62. 62. なんで単一障害点ないのに死んでしまうん? こうしておけばよかった :物理リージョンA :物理リージョンB  
  63. 63. なんで単一障害点ないのに死んでしまうん? レプリカ数は3 a データaのレプリカ a,b a,b, c c b,c 同じデータのコピーが 隣接する3ノードに存在する データbのレプリカ :物理リージョンA :物理リージョンB  
  64. 64. なんで単一障害点ないのに死んでしまうん? ここで物理リージョンBがダウンした場合 a データaのレプリカ a,b a,b, c c b,c 物理リージョンAのノードは 稼働を続け、 データのレプリカは最低1個存在 データbのレプリカ :物理リージョンA :物理リージョンB  
  65. 65. なんで単一障害点ないのに死んでしまうん? 説明をかなり省いたので、 ぶっちゃけわかりにくかったと思います そう、わかりにくいんです わかってる人がいないと マトモに運用できません
  66. 66. それはさておき NoSQLなDBMSの利用事例 ● 主に2通り LAMP構成のシステムの キャッシュやセッション管理 に使われる場合 ● 主にmemcachedや redisなどが利用される ● サービスごとに立てられ ていたmemcachedが、 全てのサービスで1つの Couchbaseクラスタにリ プレイスされる事例も RDBMSが不要、 もしくは邪魔な場合 ● いわゆるデータの 永続化を前提とした NoSQLの利用 ● たとえばAmazonの Dynamo
  67. 67. ウケがよさそうなNoSQL利用事例を ピックアップしてみました ● HBase ○ FacebookやLINEのメッセージング ● Cassandra ○ Twitterの一部機能(RT数のカウントなど) ○ 他にもDisneyやAdobe、NetFlixなどなど ● Riak ○ Bump, Yammer ● mongoDB ○ 4square
  68. 68. ウケがよさそうなNoSQL利用事例を ピックアップしてみました ● M2M界隈 ○ 聞きなれていないと思うが M2MとはMachine 2 Machine ○ スマートメーターとかスマートグリッドとか、 マシンの情報を集めたり分析する領域 ○ 日本中の電力メーターから送られたデータを DBに書き込まなければならないとしたら? ■ DBにスケーラビリティと高可用性は必須 ■ 同時に書き込みリクエストがたくさんくる ■ CassandraとかRiakが得意な領域 ■ トランザクションは要件と設計次第
  69. 69. NoSQLの利用事例も結構ある ので、NoSQL有りきの設計思 想も出てきています
  70. 70. Not only SQLな設計思想 Polyglot Persistence ● かいつまんで言うと、 「DBMSと言っても色々あるけ ど、それぞれに得手不得手が あるから向いている用途に向 いているDBMSを使おう」 という設計思想。
  71. 71. Not only SQLな設計思想 Polyglot Persistence 目的によって道具を使い分ける例 (あるいは道具が目的に応じて発達した例) モノを運ぶため 人を運ぶため 速く走るため http://en.wikipedia.org/wiki/File:Keiseibus-twinbus-20071013.jpg http://en.wikipedia.org/wiki/File:200_Ton_Truck.JPG http://en.wikipedia.org/wiki/File:Ayrton_Senna_1988_Canada.jpg
  72. 72. Not only SQLな設計思想 Polyglot Persistence DBの場合では・・・ http://martinfowler.com/bliki/PolyglotPersistence.html
  73. 73. Not only SQLな設計思想 Polyglot Persistence ● Polyglot Persistenceの欠点 http://jigokuno.img.jugem.jp/20111102_2307210. = 敷居が高い
  74. 74. Not only SQLな設計思想 Polyglot Persistence ● なぜPolyglot Persistenceの敷居が高いのか? ○ たくさんのDBMSについてデータの一貫性や 永続性、ネットワークが分断した時のクラスタ の挙動や単一障害点の存在などのインフラ 面の性質を理解した上で、アプリとしてレンジ クエリやインデキシングの可否や性能要件な どを満たす適切なDBMSを選択し、かつ真っ 当な設計が可能な上でそれらのDBMSの運 用が可能でなければ、あれその前にこの提 案って通るんですかね・・・? 真面目に考えると このくらいダルい
  75. 75. Not only SQLな設計思想 Polyglot Persistence ● 「DBMSと言っても色々ある」と言いまし たが「色々ある」の実情とは? ○ データの一貫性はどうなってるの? ○ データの永続性はどうなってるの? ○ ネットワークが分断した時の クラスタの挙動は? ココらへんを全部お ○ 単一障害点はある? さえていないと ○ レンジクエリできる? 適切なDBMSが 選択できない・・・ ○ インデックスはれる?
  76. 76. Not only SQLな設計思想 Polyglot Persistence Pinterestの事例 "Memcached and membase / redis for object- and logical-caching, respectively" "Persistent data storage using MySQL" Polyglot persistence at Pinterest: Redis, Membase, MySQL • myNoSQL : http://nosql. mypopescu.com/post/17658415847/polyglot-persistence-at-pinterest-redis-membase
  77. 77. Not only SQLな設計思想 Polyglot Persistence Amazon の事例 Service-oriented architecture システムを「サービス」 の集まりとして構築する 設計 Dynamoの 利用が最適 な箇所 Dynamo以外の データストアの 利用が最適な箇所 Amazon's Dynamo - All Things Distributed : http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
  78. 78. Not only SQLな設計思想 Polyglot Persistence どんなことでもそうですが、 Polyglot Persistenceは 正しく使えば非常に強力 正しく使いたい人向けに、 NoSQLの勉強ができる 参考文献集を用意しました
  79. 79. (抽象的なお話が多めの)参考文献集 ● 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-twelveyears-later-how-the-rules-have-changed いつ使うの?今でしょ!的なノリだが、 RDBMSとNoSQLの長短が歴史を踏まえて語られている記事 What is NoSQL Database & Why NoSQL | Couchbase : http://www.couchbase.com/whynosql/nosql-database ●
  80. 80. (具体的な文章が多めの)参考文献集 ● ● ● ● ● ● ● 「実際どのくらい性能出るのよ?」 ○ Cassandra, mongoDB, Couchbase, Aerospikeについての性能比較 http://www.aerospike.com/wp-content/uploads/2013/01/Ultra-High-Performance-NoSQLBenchmarking.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-cassandrascalability-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/couchbase16775489 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/
  81. 81. 課題 以下のクラスの課題を最低1つやってきてください 課題の解答形式は問いませんが、Yammer上で Toshikazu Nakamuraにリプってください ● ● ● ● たまごクラス ひこよクラス にわとりクラス(ひよこクラスの発展課題) フライドチキンクラス
  82. 82. ● たまごクラス(所要時間0.5hくらい・・・?) ○ CassandraとHBaseはどちらも複数のノードで データを分散して取り扱います。ですが特定の データをどのノードで取り扱うのかについての 規則は大きく異なります。 以下について調査して報告してください。 ■ CassandraとHBaseは、データを複数の ノードにどうのように分散(分割)させている のか ※どちらもデフォルトの設定が対象です ■ CassandraとHBaseのデータの分散のさせ 方の違いは、それぞれのDBMSが提供する 機能にどのように影響しているのか
  83. 83. ● ひよこクラス(構築に手間取らなければ1h) ○ 任意の環境にCouchbaseをインストールして、 サンプルのbeer-sampleデータ(ビールの銘柄と 醸造所のデータ)を眺めてみましょう ○ デフォルトで設定されているMap関数を走らせて、 データへの操作を行なってみましょう ● にわとりクラス(ひよこクラスができれば10min) ○ ひよこクラスの発展課題です ○ ひよこクラスでインストールしたCouchbaseの環境 で、任意のデータをリスティングするMap関数を作 成してください(デフォルトのMap関数を編集する だけですが、JSの関数を提出してください) 詳細は社内Wiki ( /tips/db/couchbase ) を参照
  84. 84. ● フライドチキンクラス (複数インスタンスの用意が大変だと思うので、 暇で暇でしょうがない時に気が向いたらやってみてください。 あとRiakにはREST API付いているので、やるならこっちの方が楽かも? Riakならメモリ少なくてもちゃんと起動しますし・・・) CassandraもしくはRiakのどちらかでマルチ ノードのクラスタを立ち上げ、複数のノードに データのレプリケーションが行われる状態に してください ○ 上記の状態で、マルチノードを構成する任意 の1ノードをダウンさせ、その状態でもデータ のread/writeが行えることを確認してください ○

×