OSS Forum - What is NOSQL? (Japanese)
Upcoming SlideShare
Loading in...5
×
 

OSS Forum - What is NOSQL? (Japanese)

on

  • 1,455 views

2012年8月24日

2012年8月24日

Statistics

Views

Total Views
1,455
Views on SlideShare
1,455
Embed Views
0

Actions

Likes
1
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OSS Forum - What is NOSQL? (Japanese) OSS Forum - What is NOSQL? (Japanese) Presentation Transcript

  • NOSQLについて河野 達也 / Tatsuya KawanoCloudianKK2012年8月24日日本OSS推進フォーラム勉強会 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 本日の内容• NOSQLの特徴• 分類法 • データモデルによる分類 • アーキテクチャによる分類• 主要な製品(5+1製品)の紹介• 日本での事例(2件)の紹介 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • この勉強会を終えると• NOSQL製品を分類するための キーワードが理解できる• 主要な5+1製品の特徴が説明できる• NOSQLの使いどころが説明できる Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 駆け足です• 本当は1日半くらいかけて学ぶ内容を 2時間でやります• スライドは後日SlideShareにアップします• 推薦図書(5冊)も紹介します Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 次回(9月下旬)の予定• アーキテクチャによる分類(続き) • 性能に関わる部分• ハンズオン • HBaseクラスターを動かします • YCSB(Yahoo! Cloud Serving Benchmark) Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 河野 達也 / Tatsuya Kawano エバンジェリスト 開発者 著者の一人 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • CloudianKK• Cloudian S3完全準拠クラウドストレージ• Hibari DB GBクラスのウェブメール• NOSQL afternoon in Japanを主催• グローバル開発リーダー Gary Ogasawara • InktomiでCAP定理のE. Brewer氏の弟子 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • NOSQLの特徴高速大容量半構造のデータ Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • http://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • M2M センサーデータ 経済産業省 より抜粋 0図0-3 「スマートメーター制度研究会報告書」 序 章 ビ ッ グ デ ー タ の 時 代 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 従来のデータベースでは対応が難しい• 膨大な量 • 12TB/日• 速く処理する • 12TB 80MB/秒 42時間• 半構造データ • 全てのデータを均一に整えるのは難しい Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  •  Bigtable や Dynamo の論文発表が契機となり、ソフトウェアによる大 規模分散技術は俄かに脚光を浴びました。ビッグデータに直面していたビッグデータに対応するための新技術Web サービスのエンジニア達がこれに触発され、Bigtable や Dynamo の 図0-2 Google Bigtableと Amazon Dynamo の発表論文(表紙の一部) Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • いてメッセージを保存しているIn-Box サーチのために開発され、オープンソースとしてリリースされました。その後 Cassandra は、大規模な大手Webサービスが利用を開始ニュース関連 SNS であるDigg (ディッグ) クラウドサービスの大手 や、 図1-2 代表的なNOSQL の利用企業の例 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • SQL以外のデータベースを総称• 世界に100種類以上 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • なってしまいます。その場合、ハードディスクをより大きな  もうひとつの対策は、新たにサーバーを追加し、各サー 一般的なNOSQL製品の特徴ることがひとつの対策となります。つまり、ハードウェアの 分割して保存するという方法です。ップしていくのです。そうしてデータを全て移し替え、また データが増えた場合、ら、 • スケールアウト と追加することで、 データの保存容量を拡張していくとい さらに大きなハードディスクに置換するというサイクルす。こうした対策方法を「スケールアップ」 の方法を 2 「スケールアウト」 (図 と呼びます と呼んでいます • 汎用的なハードウェアが利用できる (図 2-7) NO 。 第 考え方は、スケールアップではなくこちらの方です。 2 章 N Oップのイメージ S 図2-7 スケールアウトのイメージ Q L の デ ー タ モ デ ル スケールアップ スケールアウト Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 一般的なNOSQL製品の特徴(続き)• 複雑で多種多様に変化するデータ構造に対応• 高可用性と高信頼性 • 耐障害性 • サービス無停止で拡張 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • NOSQLは用途を絞り込んだデータベース• 機能が少ない• データの整合性が緩い(結果整合性)• 製品の成熟度? Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 事例1LINEhttp://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • http://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • http://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • http://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • http://www.slideshare.net/sunsuk7tp/hbase-at-line Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • データモデルによる分類キー・バリュー型ドキュメント指向型ソート済みカラム指向型 http://beautifuldata.net/2012/01/ telling-stories-with-network-data-instagram-in-china/ Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  •  RDB では、行と列で構成されるテーブル(表)の形でデータ構造の設計をし、そのうえでテーブル間の関係性を定義します。図にすると図 2-1 RDBのデータモデル2-1 RDB のデータモデルのイメージ • 行と列で構成されるテーブルを定義 • テーブル間の関係性を定義 • 正規化により冗長生と不整合を排除_責.indd 050 2012/04/06 10:59:32 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • キー・バリュー型型データモデルのイメージす。新しいデータが追加されるごとに、行が加えられてが増えるに従って、表が縦の方向に伸びていくイメージ • 辞書のようなデータ形式ー型に該当する NOSQL データベースには、Dynamo、、Hibari、Redis、Scalaris ス カラリス ) Tokyo Cabi- ( 、あります。 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • RDBにおけるデータ分散におけるデータ分割のイメージ サーバー 1 サーバー 2 性能がスケール しにくい サーバー 3 サーバー 4キーを指定するだけでバリューを探し出せるキー・バリュー型で Inc. & KK Copyright © 2012 Cloudian All Rights Reserved.
  • キー・バリュー型におけるデータ分散・バリュー型におけるデータ分割のイメージ サーバー 1 サーバー 2 2 テーブル間の関連やトラン 第 ザクションがないため、 2 章 容易にスケールアウト N O S させられる Q L の デ ー タ モ デ ル サーバー 3 サーバー 4複数のサーバーに複数のバリューを複製する © 2012 Cloudian Inc. & KK Copyright All Rights Reserved.
  • キー・バリュー型におけるデータの複製0 キー・バリュー型におけるデータの複製 サーバー 1 サーバー 2 複製 複製 複製 サーバー 3 単独のサー Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.のような課題に対するソリューションを実装しておらず、
  • ドキュメント指向型 • キー・バリュー型のバリエーション • バリュー部分に構造を持ったデータを格納 • データ内の各項目にインデックスが付く{ 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.
  • タ モ そして、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.
  • ように、個々のカラムは内部ではキー・バリューとして格納されています。 たとえば、 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しかし、
  • アーキテクチャによる分類マスタ型、P2P型データ分割CAP定理 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 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)型のアーキテクチャ システムの構造といった意味合いで一般的に使われますが、本書ではシステムの構造を意味します。 念テ とク 技チ 術ャ の74117_第3章_責.indd 074 2012/04/06 11:06:27 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 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.
  • して、その整理番号に従って、リングの各スペースにキーを割り当て 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.
  • 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.
  • 通常のケース: (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.
  • 分割耐性• ネットワークが分断されても 間違った結果を起こさない• 間違った結果が何にあたるかは CP、APで異なる Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • ョンや業務上の要求条件次第です。 ンライアント 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.
  •   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.
  • 果的にデータの整合性を保証できることになります。 整合性と性能のトレードオフ(続き)図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.
  • 主な製品HBaseCassandraRiakRedisMongoDBVoltDB (NewSQL) Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Apache HBase• Google Bigtableを参考に設計• 採用事例 Facebookメッセージング、 LINE、Mozillaクラッシュレポーター• ソート済みカラム指向型• 強い整合性(CP)• スケールアウト型(自動シャーディング)• マスタ型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Apache HBase• 速度:★★★☆☆• 安定性:★★☆☆☆• 注意点 • 安定させるのが難しい • HDFSよりMapRの方が高速、安定する (MapRはプロプライエタリ) Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Apache Cassandra• Amazon DynamoとGoogle Bigtableを参考に 設計• 採用事例 Twitter(分析系)、Digg、Cloudian• ソート済みカラム指向型• 緩い整合性(調整可能AP→CP)• スケールアウト型 (コンシステント・ハッシング)• P2P型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Apache Cassandra• 速度:★★★★☆• 安定性:★★★★☆• 注意点 • ディスク容量の使用効率が悪い • データ再配置の性能が悪い Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Basho Riak• Amazon Dynamoを参考に設計• 採用事例 IDCフロンティア• ドキュメント指向型• 緩い整合性(調整可能AP→CP)• スケールアウト型 (コンシステント・ハッシング)• P2P型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Basho Riak• 速度:★★★☆☆• 安定性:★★★★★• 注意点:なし Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • MongoDB• ドキュメント指向型• 強い整合性(CP)• スケールアップ • シャーディングに対応しているが、、、• インメモリ、高速 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • MongoDB• 速度:★★★★★• 安定性:★★★☆☆• 注意点 • メモリーの使用効率が悪い • メモリー不足でレスポンスが極度に悪化 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Redis• キーバリュー型 (配列やリストの扱いに優れる)• 強い整合性(CP)• スケールアップ型 • インメモリ、高速 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Redis• 速度:★★★★★• 安定性:★★★★☆• 注意点 • 格納できるデータサイズがメモリーの 搭載量に制限される Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • VoltDB• NewSQL• SQLとACIDトランザクションが使える インメモリ・データベース• スケールアウト型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • VoltDB• 超高速、高い安定性 (発表者自身は試せていない)• 柔軟性が犠牲に • アドホックなクエリはできない。 事前にJavaでストアドプロシージャを 書く • ノード追加時はサービスをいったん停止 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • 事例2CloudianRedisCassandraHyperStore http://cloudian.jp/cloud-storage-products/cloudian.html Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Cloudian™の論論理理アーキテクチャ Admin 認証情報 サーバー (Redis) HTTPS ログイン HTTP QoS  DBアカウント設定/   HTTPS 管理理コンソール S3サーバーセキュリティキー Servlets (Redis) HTTP レポート HTTPData  Explorer データサーバー ユーザーデータ (Cassandra) ウェブUI アカウント情報 (Cassandra) HTTP  or   HTTPS   (S3) レポートアプリケーション (Cassandra) 56
  • オブジェクトストアとしてのCassandra• BLOBストレージ • グループごとに  column  family  を作成 • ⾏行行キー  <バケットID>/<オブジェクトID>• オブジェクトのメタデータ • ACL  (アクセスコントロールリスト)、オブジェクトのサイズ・・・ • Cassandra  ⾏行行キャッシュを活⽤用• 巨⼤大なS3オブジェクトのサポート   • マルチパート  Amazon  S3  multi-‐‑‒part  APIを使ってアップロード • チャンキング  ⼤大きなオブジェクトを⼩小さなチャンク(例例  10MB)に分割して保存 • HTTPレンジヘッダー  ダウンロード時は  HEAD  リクエストでオブジェクトのサイズを 取得してから、スタートのバイト位置と⻑⾧長さを指定してダウンロード • HyperStore™  巨⼤大なオブジェクトをネイティブなファイルシステムに保存
  • ⼤大きなデータの扱いで性能が劣劣化 遅延時間の 遅延時間の中央値 30分間で バリューサイズ 95パーセンタイル値 スループット (ミリ秒) 処理理した (ミリ秒) 100KB (件/秒) 件数 Get Put Get PutHibari  0.1.8         9.268 12.299 61.914 75.934 2,073 3,733,136Cassandra  1.0 28.551 9.992 379.745 155.680 1,699 3,060,198Cassandra  0.8.6       34.099 8.402 1,015.888 333.048 1,336 2,406,446バリューサイズ  1KBHibari  0.1.8 1.027 1.676 3.069 2.881 8,775 15,804,196Cassandra  1.0 1.016 0.949 2.476 4.789 8,748 15,755,306Cassandra  0.8.6       1.282 0.948 5.729 2.243 8,700 15,668,017出典:「NOSQLの基礎知識識」  リックテレコム、2012年年4⽉月出版
  • HyperStore™(特許出願中) Admin 認証情報HyperStore サーバー (Redis) • ストレージのハイブリッド化により S3 QoS サーバー (Redis) 処理性能とディスク利用効率の向上を実現 • オブジェクトの大きさに応じて データストア 最適なストレージを自動選択 HyperStore™• メタデータは引き続きCassandraに格納 Manager Data Store• パーティショニング、レプリケーション、ノード (Cassandra) の死活監視は、Cassandraの分散機能を使用 Cloudian®• Cassandraのソースをフォークしてカスタマイ サーバー Accounting (Cassandra) ズ Reporting (Cassandra)
  • HyperStore:  レイテンシーの測定 50.0 37.5 >30% fasterms 25.0 PUT-Cass PUT-HS 12.5 0 0 1 10 100 1000 KB 60.0 45.0 >400% fasterms 30.0 GET-Cass GET-HS 15.0 0 0 1 10 100 1000 KB
  • 推薦図書 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • NOSQLの基礎知識ビッグデータを活かすデータベース技術本橋信也 (著)河野達也 (著)鶴見利章 (著)太田 洋 (監修)256ページ出版社: リックテレコム (2012/4/25)ISBN-10: 4897978874ISBN-13: 978-4897978871 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • NoSQLプログラミング実践活用技法Shashank Tiwari (著)中村 泰久 (監修)長尾 高弘 (翻訳)HBase、Cassandra、MongoDB、Redis407ページ出版社: 翔泳社 (2012/5/18)ISBN-10: 4798126055ISBN-13: 978-4798126050 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • まつもとゆきひろコードの未来まつもと ゆきひろ (著)MongoDB、VoltDB360ページ出版社: 日経BP社 (2012/5/17)ISBN-10: 4822234630ISBN-13: 978-4822234638 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • NoSQLデータベースファーストガイド佐々木 達也 (著)MongoDB、Redis232ページ出版社: 秀和システム (2011/04)ISBN-10: 4798029599ISBN-13: 978-4798029597 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • HBaseLars George (著)Sky株式会社 玉川 竜司 (翻訳)584ページ出版社: オライリージャパン (2012/7/25)ISBN-10: 4873115663ISBN-13: 978-4873115665 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • この勉強会を終えると(再)• NOSQL製品を分類するための キーワードが分かる• 主要な5製品の特徴が説明できる• NOSQLの使いどころが説明できる Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
  • Questions? http://gplus.to/tatsuya6502 http://twitter.com/tatsuya6502 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.