NOSQLの基礎知識（講義資料）

7. CloudianKK • Cloudian S3完全準拠クラウドストレージ • Hibari DB GBクラスのウェブメール • NOSQL afternoon in Japanを主催 • グローバル開発リーダー Gary Ogasawara • InktomiでCAP定理のE. Brewer氏の弟子 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

12. Bigtable や Dynamo の論文発表が契機となり、ソフトウェアによる大規模分散技術は俄かに脚光を浴びました。ビッグデータに直面していたビッグデータに対応するための新技術 Web サービスのエンジニア達がこれに触発され、Bigtable や Dynamo の図0-2 Google Bigtableと Amazon Dynamo の発表論文（表紙の一部） Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

13. いてメッセージを保存しているIn-Box サーチのために開発され、オープンソースとしてリリースされました。その後 Cassandra は、大規模な大手Webサービスが利用を開始ニュース関連 SNS であるDigg （ディッグ）クラウドサービスの大手や、図1-2 代表的なNOSQL の利用企業の例 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

15. なってしまいます。その場合、ハードディスクをより大きなもうひとつの対策は、新たにサーバーを追加し、各サー一般的なNOSQL製品の特徴ることがひとつの対策となります。つまり、ハードウェアの分割して保存するという方法です。ップしていくのです。そうしてデータを全て移し替え、またデータが増えた場合、ら、 • スケールアウトと追加することで、データの保存容量を拡張していくといさらに大きなハードディスクに置換するというサイクルす。こうした対策方法を「スケールアップ」の方法を 2 「スケールアウト」（図と呼びますと呼んでいます • 汎用的なハードウェアが利用できる（図 2-7） NO 。第考え方は、スケールアップではなくこちらの方です。 2 章 N O ップのイメージ S 図2-7 スケールアウトのイメージ Q L のデータモデルスケールアップスケールアウト Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

24. RDB では、行と列で構成されるテーブル（表）の形でデータ構造の設計をし、そのうえでテーブル間の関係性を定義します。図にすると図 2-1 RDBのデータモデル 2-1 RDB のデータモデルのイメージ • 行と列で構成されるテーブルを定義 • テーブル間の関係性を定義 • 正規化により冗長生と不整合を排除 _責.indd 050 2012/04/06 10:59:32 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

25. キー・バリュー型型データモデルのイメージす。新しいデータが追加されるごとに、行が加えられてが増えるに従って、表が縦の方向に伸びていくイメージ • 辞書のようなデータ形式ー型に該当する NOSQL データベースには、Dynamo、、Hibari、Redis、Scalaris スカラリス） Tokyo Cabi- （、あります。 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

27. キー・バリュー型におけるデータ分散・バリュー型におけるデータ分割のイメージサーバー 1 サーバー 2 2 テーブル間の関連やトラン第ザクションがないため、 2 章容易にスケールアウト N O S させられる Q L のデータモデルサーバー 3 サーバー 4 複数のサーバーに複数のバリューを複製する © 2012 Cloudian Inc. & KK Copyright All Rights Reserved.

29. ドキュメント指向型 • キー・バリュー型のバリエーション • バリュー部分に構造を持ったデータを格納 • データ内の各項目にインデックスが付く { author: 'joe', created: new Date('03/28/2009'), title: 'Yet another blog post', text: 'Here is the text...', tags: [ 'example', 'joe' ], comments : [ { author: 'jim', comment: 'I disagree'}, { author: 'nancy', comment: 'Good post' }] } Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

30. タモそして、RDB 等との決定的な違いとして、カラムの数を後から増やすことデルができます。RDB の行（レコード）のように、データの発生に応じて動的に、ソート済みカラム指向型かつほぼ無限に、カラムを追加していくことが可能なのです。図2-13 カラムの名前を固定しなくてよいユーザーライン・カラムファミリーこの SNS がサービスを開始すると、ランダムにツィートが登録されます。カラム行キータイムスタンプそれを管理するために、ツィートID を行キーとする「ツィート・カラムキー（ユーザー ID） 1234567 1234568 1234569 その中でツィートID は、 2-14 のように、図新 2 ファミリー」を定義します。 u2415 t342 しいツィートが発生するごとに、 t353 t389 行として縦方向に追加されていきます。ツィート ID 第新しいツィートごとに新しい行を加える 2 章図2-14 カラム指向型における行の追加 N ツィート・カラムファミリー O で、カラムの名前が固定ではないことに注意してください。カラム S Q このタイムスタンプの例のように、行キーカラム指向型では、行キーに連なる L のキーィートID）（ツユーザー ID ユーザーネームボディタイムスタンプデカラムの名前を、時間とともに変化する性質のものとすることができます。ー t342 u2415 gemini NOSQL is fun 1234567 タモそして、RDB 等との決定的な違いとして、カラムの数を後から増やすことデ新しいツィートごとに新しい行を加えるルができます。RDB の行（レコード）のように、データの発生に応じて動的に、かつほぼ無限に、カラムを追加していくことが可能なのです。 Inc. & KK Copyright © 2012 Cloudian All Rights Reserved.

31. ように、個々のカラムは内部ではキー・バリューとして格納されています。たとえば、 2-14 のツィートID 図「t342」の行は、Bigtable 系の HBase では、ソート済みカラム指向型（続き）表 2-1に示す 4 つのキー・バリューに分解されて格納されます。表2-1 HBase において行をキーとバリューに分解する例キーバリュー行キーカラムファリー名ミカラム名 t342 ツーィト・カラムファリミーユーザー ID u2415 t342 ツーィト・カラムファリミーユーザーネーム gemini t342 ツーィト・カラムファリミーボディ NOSQL is fun t342 ツーィト・カラムファリミータイムスタンプ 1234567 • そのためカラム指向型は、キー・バリューと同様にスケールアウトに適キー・バリュー型のバリエーションしています。複数のサーバー間にデータを分割して配置し、かつデータを • 各カラムが独立したキー・バリューになるため複製することが、データ間の関係性を維持するRDBよりも容易に行えるからです。ドキュメント指向型よりも書き込み性能の面で有利カラム指向型の NOSQL データベースは、名前が似ていることかなお、ら、カラムナ（columnar）両者データベースと混同されがちです、Inc. & KK All Rights Reserved. Copyright © 2012 Cloudianしかし、

33. Bigtable 系と、Amazon の Dynamo 系の 2 種です。 Bigtable 系の基本的なアーキテクチャは、「マスタ型」と呼ばれます。ひすマスタ型／P2P ピア・ツゥ・ピア型とつのマスタノードが、（図 3-1）。配下にある多数のノードを管理するという構造で図3-1 マスタ型のアーキテクチャ Dynamo 系は P2P （ピア・ツゥ・ピア）と呼ばれる構造です。マスタノードに相当するものは存在せず、全てのノードが対等にお互いを管理し合います（図 3-2）。マスタ型の NOSQL データベースには、Bigtable、CouchDB、HBase、 Hibari、MongoDB 等があります。これらの製品では、マスタノードがシステム全体の状況を把握しており、止まってしまいます。マスタがダウンするとシステム全体がそのためマスタを冗長化したり、他のノードがマス 3第タの役割を代行するなどして、そのような障害に備えます。章 3 基ア本ー＊ 1 アーキテクチャとは、システムの設計方法、設計思想、およびその設計思想に基づいて構築された概キ図3-2 ピア・ツゥ・ピア（P2P）型のアーキテクチャシステムの構造といった意味合いで一般的に使われますが、本書ではシステムの構造を意味します。念テとク技チ術ャの 74 117_第3章_責.indd 074 2012/04/06 11:06:27 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

34. 3-19 のように Bigtable では、辞書配列に従ってキーの値がソートさデータ分割シャーディング Bigtable のデータ割当てタブレット（リージョン）行キー：［ Arkansas ， California ）タブレット（リージョン）行キー：サーバー 1 ［ California ， California-LosAngeles ）行キー：［ California-LosAngeles ， Colorado ）タブレット（リージョン）行キー：サーバー 2 ［ Colorado ， Florida ）ベージコレクショ（Garbage Collection：GC）ンとは、プログラムが実行の際に確保したメモリ域のう不要になった領域を解放する処理です。同様に、2012 ドディ & KK All Rights Reserved. ち、 Copyright ©ハーCloudian スク上で不要になった領域 Inc.

35. して、その整理番号に従って、リングの各スペースにキーを割り当て 0.45 。キーが割り当てられたスペースを時計回りで進み、そこで最初に配キーのハッシュ値データ分割コンシステント・ハッシングれているノードにデータを書き込むというルールのアルゴリズムです。が取り除かれた場合ノード C コンシステント・ハッシングの概念図図3-16 コンシステント・ハッシングにおける負荷割り当ての調整ノードノード A A キーのハッシュ値 0.0 0.0 0.20 ノード 0.75 0.25 ノードノードノード D B 0.75 0.25 D B 0.70 ノード 0.5 C データ複製ノードデータ複製 C ノード C にデータの割り当てを増やすグレーのノードにデータの複製を割り当て 3-13 では、ハッシュ値を 0.0 から1.0 の間で設定しています。つの 4 ドがリング状に配置され、ノード Aには 0.0、ノード B には 0.25、 © 2012 Cloudian Inc. & KK ノー Copyright All Rights Reserved.

36. ACM（Association for Computing Machinery）が主催した PODC （Prin- ciple Of Distributed Computing）シンポジウムにおける「Towards Ro- Eric BrewerのCAP定理 bust Distributed Systems」と題した基調講演の中でのことでした。図3-6 Eric Brewer の CAP 定理 • 注意 3 • C or Aはクエリの都度第 3 調整可能 Consistency Availability 章基ア整合性可用性 • 証明されておらず本ー概キ念テとク厳密には定理ではない技チ術ャの「分散システムにおいては、 Tolerance to network これら 3 つのうち最大 2 つ Partitions しか満たすことができない」分断耐性（2000 年 7 月 19 日 PODC 基調講演） Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

37. 通常のケース：（1）クライアントはデータの更新要求を A または B のいずれか一方に送る。データ複製時の整合性（2）と B はデータが更新されたことを他方に通知する。（3） A 通知を受けた側は、自分のデータにその更新を反映する。クライアント 1 クライアント 2 リクエストデータデータ A B レプリケーション（複製） ①クライアント1が Aに対して更新要求を出し、Aは自身の持つデータを更新する。 ② A はデータが更新されたことを B に伝え、は自身の持つデータ B Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

39. ョンや業務上の要求条件次第です。ンライアント 1 クライアント 2 ア 3 第トが 3A B CPとAP ネットワーク分割が発生書章生じた場合き基ア込本ー CP （整合性と分断耐性）の場合：み AP 概キ（可用性と分断耐性）の場合：念テリクエストは片方のグループ（仮に A）リリクエストは全てのグループが受けとククだけが受け付け、他のグループはエ付けるが、A と B のデータは不整合技チ A B 術ャ自主的に停止する。スとなる。トのをクライアント 1 クライアント 2 送クライアント 1 クライアント 2 るクライアンデータデータトが A B A B 書き込み AP （可用性と分断耐性）の場合：リリクエストは全てのグループが受けク付けるが、A と B のデータは不整合 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

40. R ＋ W ＞N の場合には、整合性が保証できる整合性と性能のトレードオフ -10 Quorum の概念図［R ＋ W ＜N］ R＋W＜N の場合書き込み（W＝1）読み出し（R＝1）？？？複製（N＝3）ノード 1 ノード 2 ノード 3 書き込みが 1 つのノードに行われているが、ノード 1.2.3 のどのノードから 1 つだけデータを読み出すかはわからない。 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

41. 果的にデータの整合性を保証できることになります。整合性と性能のトレードオフ（続き）図3-11 Quorum の概念図＋ W ＞N］［R R＋W＞N の場合書き込み（W＝2）読み出し（R＝2）複製（N＝3）ノード 1 ノード 2 ノード 3 書き込みが 2 つのノードに行われ、読み出しが 2 つのノードに行われれば、必ず書き込みが行われた 2 つのノードのうちの 1 つに行きつく。 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

45. Apache Cassandra • Amazon DynamoとGoogle Bigtableを参考に設計 • 採用事例 Twitter（分析系）、Digg、Cloudian • ソート済みカラム指向型 • 緩い整合性（調整可能AP→CP） • スケールアウト型（コンシステント・ハッシング） • P2P型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

56. Cloudian™の論論理理アーキテクチャ Admin 認証情報サーバー (Redis) HTTPS ログイン HTTP QoS DB アカウント設定/ HTTPS 管理理コンソール S3サーバーセキュリティキー Servlets (Redis) HTTP レポート HTTP Data Explorer データサーバーユーザーデータ (Cassandra) ウェブUI アカウント情報 (Cassandra) HTTP or HTTPS (S3) レポートアプリケーション (Cassandra) 56

57. オブジェクトストアとしてのCassandra • BLOBストレージ • グループごとに column family を作成 • ⾏行行キー　<バケットID>/<オブジェクトID> • オブジェクトのメタデータ • ACL (アクセスコントロールリスト)、オブジェクトのサイズ・・・ • Cassandra ⾏行行キャッシュを活⽤用 • 巨⼤大なS3オブジェクトのサポート • マルチパート　Amazon S3 multi-‐‑‒part APIを使ってアップロード • チャンキング　⼤大きなオブジェクトを⼩小さなチャンク（例例 10MB）に分割して保存 • HTTPレンジヘッダー　ダウンロード時は HEAD リクエストでオブジェクトのサイズを取得してから、スタートのバイト位置と⻑⾧長さを指定してダウンロード • HyperStore™ 　巨⼤大なオブジェクトをネイティブなファイルシステムに保存

58. ⼤大きなデータの扱いで性能が劣劣化遅延時間の遅延時間の中央値 30分間でバリューサイズ 95パーセンタイル値スループット (ミリ秒) 処理理した (ミリ秒) 100KB (件/秒) 件数 Get Put Get Put Hibari 0.1.8 9.268 12.299 61.914 75.934 2,073 3,733,136 Cassandra 1.0 28.551 9.992 379.745 155.680 1,699 3,060,198 Cassandra 0.8.6 34.099 8.402 1,015.888 333.048 1,336 2,406,446 バリューサイズ 1KB Hibari 0.1.8 1.027 1.676 3.069 2.881 8,775 15,804,196 Cassandra 1.0 1.016 0.949 2.476 4.789 8,748 15,755,306 Cassandra 0.8.6 1.282 0.948 5.729 2.243 8,700 15,668,017 出典:「NOSQLの基礎知識識」　リックテレコム、2012年年4⽉月出版

59. HyperStore™（特許出願中） Admin 認証情報 HyperStore サーバー (Redis) • ストレージのハイブリッド化により S3 QoS サーバー (Redis) 処理性能とディスク利用効率の向上を実現 • オブジェクトの大きさに応じてデータストア最適なストレージを自動選択 HyperStore™ • メタデータは引き続きCassandraに格納 Manager Data Store • パーティショニング、レプリケーション、ノード (Cassandra) の死活監視は、Cassandraの分散機能を使用 Cloudian® • Cassandraのソースをフォークしてカスタマイサーバー Accounting (Cassandra) ズ Reporting (Cassandra)

60. HyperStore: レイテンシーの測定 50.0 37.5 >30% faster ms 25.0 PUT-Cass PUT-HS 12.5 0 0 1 10 100 1000 KB 60.0 45.0 >400% faster ms 30.0 GET-Cass GET-HS 15.0 0 0 1 10 100 1000 KB

63. NoSQLプログラミング実践活用技法 Shashank Tiwari (著) 中村泰久 (監修) 長尾高弘 (翻訳) HBase、Cassandra、 MongoDB、Redis 407ページ出版社: 翔泳社 (2012/5/18) ISBN-10: 4798126055 ISBN-13: 978-4798126050 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

NOSQLの基礎知識（講義資料）

NOSQLの基礎知識（講義資料）

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Destaque

Destaque(6)

Similar a NOSQLの基礎知識（講義資料）

Similar a NOSQLの基礎知識（講義資料）(20)

Mais de CLOUDIAN KK

Mais de CLOUDIAN KK(20)

Último

Último(13)

NOSQLの基礎知識（講義資料）