平成28年度[前期]JEITA講座 データベース技術の最新動向 と今後の展望 2016年 5月30日 日本ユニシス株式会社 総合技術研究所 技術開発室 中山 陽太郎 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ ビッグデータ データ処理量/日 データ量 Organization Amount of data processed per day Organization Amount of data stored eBay 100PB Google 15,000PB Google 100PB NSA 10,000PB Baidu 100PB Baidu 2,000PB NSA* 29PB Facebook 300PB Facebook 600TB Ebay 90PB Twitter 100TB Sanger 22PB Spotify 64TB Spotify 10PB Sanger 1.7TB(DNA配列) * NSA： アメリカ国家安全保障局（National Security Agency ) (参照) https://followthedata.wordpress.com/2014/06/24/data-size-estimates/ 3 ©2016 Nihon Unisys, Ltd. All rights reserved. Webスケールアプリケーション Facebook 月間アクティブユーザー：15億5000万人 (2015年11月) 日間アクティブユーザー：10億1000万人 Twitter 月間アクティブユーザー：2億8400万人（2014年10月） Line ユーザー数：5.6億人（2014年10月） 動画配信サービス Netflix 8100万ユーザ（2016年4月） Hulu 900万ユーザ （参照） http://venturebeat.com/2015/11/04/facebook-passes-1-55b-monthly-active-users-and-1-01-billion-daily-active-users/ http://gaiax-socialmedialab.jp/socialmedia/435 http://gaiax-socialmedialab.jp/socialmedia/368 http://www.webpronews.com/netflix-earnings-2016-04/ 4 ©2016 Nihon Unisys, Ltd. All rights reserved. Data Platform Map Jan. 2016 Non-relational zone Relational zone Grid/Cache zone https://451research.com/state-of-the-database-landscape データベース技術の発展と背景 データベース技術の歴史を辿ると何が⾒えるか？ 年代 イベント 1960年代 ネットワーク型データベース 1970年代 コッドによる関係モデル IBM SystemR, UCB INGRES 1980年代 IBM DB2, Oracle, Unisys RDMS1100 オープン系商用RDB 1990年代 オブジェクト指向DB, XML ダウンサイジング 2000年代前半 オープンソースDBMSの普及 (PostgreSQL, MySQL) センサーデータベース, ストリームデータベース 2005年〜 インメモリデータ処理，ストリームデータ処理 Web2.0，情報大爆発 クラウドコンピューティング登場（Amazon AWS) 2010年〜 アプライアンスDWH，列指向DWH クラウド，キーバリューストア Hadoop, NoSQL, ビッグデータ 現在 汎用機 UNIX サーバ Windows サーバ 分散クラスタ クラウド SQL on Hadoop, Spark, NoSQL, NewSQL IoT 6 6 ©2016 Nihon Unisys, Ltd. All rights reserved. DB技術の発展と背景 インターネット以前 定型業務，ベンダー主導型のビジネス DB技術発展は，パフォーマンスと 機能性の競争 高速性 インターネット以降 機能の単純化 EC普及，モバイル発展，ソーシャル 基本技術とDBMSの関係 アプリケーショ ン • SQLからKVSへ • SQLからNoSQLへ インメモリ 並列分散処理 プログラミング 言語 機能性 モデリング技法 インターネット以前 基盤技術 OS,分散技術 • NWからSQLへ Hadoop以降 • ハードウェア・アーキテクチャ 7 KVSからSQLへ ©2016 Nihon Unisys, Ltd. All rights reserved. DB技術の発展と背景 H/Wとデータベースの融合 ハードウェアとDBMSの融合 SQL in Silicon VLDB2015の基調講演 SWとHWの”フレンドシップ” Oracle SQL in Silicon ハードウェアアーキテクチャの進化による DBリファクタリング ストレージと主記憶を透過的に連携する ストレージクラス・メモリ HPE ユニバーサルメモリによる次世代マシン ”The Machine” 8 ©2016 Nihon Unisys, Ltd. All rights reserved. 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ RDBMSの発展 Prof. Michael Stonebraker 2014年度チューリング賞を受賞 70年代RDB黎明期 80∼90年代RDB発展期 2000年代RDB成熟期 ∼ RDBMSの見直し ocean (ゴール) 2000年代 Hadoop,NoSQL黎明期 ∼2016年現在 Spark,NoSQL発展期 RDBからNewSQLへ Credit: Mary Anne Case 2020?年 SQL? Spark? 1974 IBM System R(サンノゼ研究所) E. Ted. Codd 1971∼2000 バークレー時代 2001∼2015現在 MIT時代 背景 1996 Googleの登場 2000 RDBの限界に遭遇 2005 Hadoop，Bigtable (写真) http://cacm.acm.org/magazines/2016/2/197423-the-land -sharks-are-on-the-squawk-box/fulltext#UF2 https://voltdb.com/leadership/dr-michael-stonebraker 10 ©2016 Nihon Unisys, Ltd. All rights reserved. M. Stonebrakerによるデータベース市場 データベース市場の1/3はトランザクション処理1/3はDWH， 残りの1/3は非リレーショナル 2000年から2015年現在までで⼤きな変化 Transaction Processing Database Market DWH Non Relational NoSQL Disk Base Row Store Row Store 2000〜2015 2000〜2015 Array Graph Main Memory Column Store Hadoop （資料）http://www.zdnet.com/article/the-elephants-dilemma-what-does-the-future-of-databases-really-look-like/ 11 ©2016 Nihon Unisys, Ltd. All rights reserved. One size does not fit all ビジネスアプリケーションの多様化 The End of an Architectural Era (It‘s time for a complete rewrite) Michael Stonebraker 新たなRDBアーキテクチャの追求 汎用的なRDBは，すべての要求を満たすことが困難 “One Size Fits All”: An Idea Whose Time Has Come and Gone Stream Database: StreamBase H-Store: 商用版VoltDB ビッグ データ C-Store: 商用版Vertica 汎用 RDB カラム指向 DWH 12 超高速 OLTP ©2016 Nihon Unisys, Ltd. All rights reserved. VoltDBのアーキテクチャ RDBの新しいアーキテクチャによるNewSQL 商用版VoltDB = インメモリRDB ＋ ACID ＋ シェアードナッシング 大規模トランザクション処理に特化した分散型RDB – ACID特性トランザクション – シェアードナッシングによるスケーラビリティ PostgreSQLの生みの親M.ストーンブレーカ博士 により、MIT等の大学の共同研究から誕生 マルチマスター型クラスタ – ノード追加によるスループットと容量拡張 – マルチマスタとレプリケーションによる無停止 アーキテクチャ – 廉価サーバによるクラスタで大型DBサーバ 以上の性能を実現 13 ©2016 Nihon Unisys, Ltd. All rights reserved. 13 レガシーRDBMSの課題 ディスクベースのレガシー DBMSにおける4つの課題 同時実⾏制御(Concurrent Control) 先⾏ログ書き込み(Write Ahead Log) ARIES(Algorithm for Recovery and Isolation Exploiting Semantics) ラッチ(Latching) ブロックレベル，⾏レベル バッファプール管理 スペースアロケーション ダーティバッファ書き出し ディスクデータの読み込み TPC-CワークロードにおけるCPUリソース使用率の比較 CPU Cycle Breakdown for Shore on TPC-C New Order Stonebraker, “OLTP Through the Looking Glass”, SIGMOD 2008 同時実⾏制御のボトルネック リソースの競合をどう効率化するか 14 ©2016 Nihon Unisys, Ltd. All rights reserved. Partition and Core Affinity Stored Procedure SP1 SP2 ①Customer P1 P2 P3 ・・ ②Order P1 P2 P3 ・・ トランザクション = SP単位 トランザクションの実⾏ ④Item ③Stock P1 P2 P3 ・・ Replication SP3 パーティション化 ① ② ③ P1 P1 P1 ④Item SP ① ② ③ P2 P2 P2 ① ② ③ P3 P3 P3 ④Item ④Item SP SP ・・ パーティションごとに1スレッド/コアで順 番に実⾏ ロック不要により、キュー/デッドロック 排除 VoltDBのパーティション パーティション=「データ」+実⾏エンジ ン 実⾏エンジンは、トランザクションをワー ク・キューで管理 単一パーティションの場合、ワーク・キュ ーは、シーケンシャルに実⾏される。 1トランザクション/１コア/1スレッド/1パ ーティション単位 パーティションの実⾏は、⼀度に1ワーク キュー（トランザクション） Core に割り当て ・・ Node1 Node2 Node3 15 ©2016 Nihon Unisys, Ltd. All rights reserved. Voter - Phone-based election process 電子投票デモ 電子投票デモ（Voter）とは VoltDB添付のサンプルアプリケーション 米国のテレビタレントショーコンテストで、視聴者が電話で投票する場面を想定 電話番号によって投票者を識別し、市外局番から⽶国の州を特定する コンテスト参加者 ・・・ 投票 リアルタイムに ヒートマップを更新 16 ©2016 Nihon Unisys, Ltd. All rights reserved. Voter - Phone-based election process Throughput results in the case of changing the number of nodes and the number of replication Number of replication :0 :1 :2 :3 Number of nodes Conditions to run the Voter Number of nodes: 1-10 units Number of partition: 4 Number of replication: 0-3 Execution time: 20 seconds Number of contestants: 6 Valid Votes: 2 votes Data size without replication: about 1.3GB Client running on the VoltDB server The more the number of nodes increases, the throughput increases There is a scale-out benefits 700000 [tps] at number of nodes: 10 units and number of replication: 0 The high-speed processing performance 17 ©2016 Nihon Unisys, Ltd. All rights reserved. DWH技術の展開 – カラム指向技術 背景： ディスク速度によるDBMSの課題 トランジスタ/チップ 1971年以降 100,000倍以上 ディスク密度 1956年以降 100,000,000倍以上 ディスク速度 1956年以降 12.5倍 ディスク速度によるDBMS性能の限界 % 18 ©2016 Nihon Unisys, Ltd. All rights reserved. カラム指向DWHとは データ圧縮 バンド幅利用の改善 コードパイプラインの改善 キャッシュ局所性の改善 列(カラム)指向型RDB 行指向型RDB SELECT AVG (Price) FROM Product SELECT AVG(価格) FROM Product No. Name Price Date Size 005 A ¥100 12/1/5 18 006 B ¥200 11/7/10 5 007 C ¥300 10/12/7 30 No. Name Price Date Size 005 A ¥100 12/1/5 18 006 B ¥200 11/7/10 5 007 C ¥300 10/12/7 30 対象の列のみ読み込んで、集計 ¥100 005 A ¥100 12/1/5 18 006 B ¥200 11/7/10 5 007 C ¥300 10/12/7 30 ¥200 ¥300 抽出 全行を読み込んで、必要な列を集計 抽出 集計 集計 19 ©2016 Nihon Unisys, Ltd. All rights reserved. DWH技術の展開 – カラム指向DWH Vertica 列型（カラム型） データベース スケールアウト型 MPPアーキテクチャ プロジェクション による最適化 Reads 3 columns AAPL AAPL BBY BBY 143.74 143.75 37.03 37.13 5/05/09 5/06/09 5/05/09 5/06/09 AAPL AAPL BBY BBY 143.74 143.75 37.03 37.13 5/05/09 5/06/09 5/05/09 5/06/09 検索時に必要な列のみを読み込むため、 従来のリレーショナルデータベースのよ うに⼤量ディスクI/Oを必要とせず、検 索を50〜1,000倍高速化 MMP（Massive Parallel Processing）アーキテクチャにより、ノー ドの追加による容易なスケールアウトが実現 クエリに最適化されたプロジェクションにより，検索処理 が適切に最適化される。データロード時に自動的に最 適化された汎用的なスーパー・プロジェクションや，クエ リごとに最適化された固有のプロジェクションを作成す ることが可能。 20 ©2016 Nihon Unisys, Ltd. All rights reserved. 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ Hadoop・NoSQL・Sparkの登場 Hadoop, NoSQLからSparkの登場まで MapR(2009) Hortonworks(2011) Amazon EMR(2009) Yahoo! D.CuttingによるGFS, MapReduce実装 2000 2003 The Google File System（2003） MapReduce(2004) Amazon Dynamo KVS(2007) Bigtable(2006) C-Store (2005) Facebook Hadoop 利用 (2006) 2015 2010 2007 2005 Microsoft Azure(2010) Cloudera社(2008) Google Cloud Dataflow発表 MongoDB(2009) H-Store (2008) Twitter Hadoop 利用 (2008) 22 Cassandra(2010) Spark(2011) ©2016 Nihon Unisys, Ltd. All rights reserved. Hadoopとは Googleによる分散ファイル，MapReduceの論⽂をベースに、D.Cutting氏らにより、検 索エンジンの基盤として開発 HDFS - Hadoop Distribution File System 複数サーバに分散してデータを格納・管理する機能 ペタバイト級の巨⼤データ処理が可能 MapReduce HDFS上のデータに対して、並列処理する仕組み MapReduceで作成されたプログラムを実⾏する仕組 23 ©2016 Nihon Unisys, Ltd. All rights reserved. MapReduce実⾏プロセス 処理をMap処理とReduce処理の２つのフェーズに分けて実装 分散処理を意識せずにプログラムの設計と実装が可能 <入力データ> ( 商品名，単価，個数 ) リンゴ, バナナ, リンゴ, ミカン, ミカン, イチゴ, ミカン, バナナ, イチゴ, ミカン, 100, 120, 100, 80, 80, 200, 80, 120, 200, 80, 3 5 1 2 1 2 2 1 2 1 Shuffle処理 <出力> (商品名, 合計金額) Map処理 (ユーザ実装) Shuffle処理 (ソートによる 再配置) MapReduceが 実⾏) リンゴ 100, 3 リンゴ 100, 1 ミカン 80, 2 ミカン 80, 1 ミカン 80, 2 ミカン 80, 1 24 リンゴ, 400 バナナ, 720 ミカン, 480 イチゴ，800 Reduce処理 (ユーザ実装) Reduce処理 集計(単価×数量) リンゴ Reduce処理 集計(単価×数量) ミカン 400 480 ©2016 Nihon Unisys, Ltd. All rights reserved. Spark登場の背景 MapReduceでビッグデータ処理が容易になったが，さらに次が求められる: 複雑なマルチステージ・アプリケーション (反復機械学習，繰り返しの多いグラフ処理) インタラクティブなアドホッククエリ MapReduceに代わるフレームワークが必要 RDD レジリエント分散データセットによる解決 data set (参照)Matei Zaharia, Resilient Distributed Datasets A Fault -Tolerant Abstraction for In-Memory Cluster Computing RDD data set RDD data set フィルター リング NUL Group Internal Use Only RDD data set data set 結合処理 RDD 25 集計処理 RDD ©2016 Nihon Unisys, Ltd. All rights reserved. MapReduceからSparkへ 分散データ処理技術の展開 HadoopからSQL on Hadoop インタラクティブなクエリ実⾏ Impala, Presto, Drill Sparkとは UC Berkley AMPLabの研究をベース On Memoryによる分散データ処理 メモリ上で⼤規模データの分散処理を実⾏ Hadoop MapReduce処理におけるHDD に対するデータの⼊出⼒が課題 SQL on Hadoop (Hive, Impala, Presto, Drill, ..) Spark SQL Spark Streamin g MapReduce MLlib GraphX Spark HDFS HDFS YARN Mesos 26 Cassandra HBase YARN ©2016 Nihon Unisys, Ltd. All rights reserved. ２．NoSQL – Not Only SQL 分散システム基盤による拡張性と可用性 多様なデータモデル キー・バリュー型 Dynamo、Riak, Couchbase 分散ハッシュ型 ビッグテーブル型 Cassandra、 HBase スプレッドシート，表形式 ドキュメント指向型 MongoDB 半構造型，JSON形式 Document Store Big Table グラフ型 GraphX, Titan Key Value Store 27 2 7 ©2016 Nihon Unisys, Ltd. All rights reserved. ⻄海岸のNoSQL関連企業マップ Databricks Couchbase Cloudera MarkLogic Facebook Hortonworks MongoDB Googlplex MapR スタンフォード大学 DataStax Cassandra Summit サンタクララコンベン ションセンター 28 Intel ©2016 Nihon Unisys, Ltd. All rights reserved. NoSQLとRDBの比較 RDBは、SQLとトランザクション、NoSQLは拡張性、可用性 NoSQL RDB 分散・単一アーキテクチャ 分散データ処理アーキテクチャ 単一サーバ型アーキテクチャ。 拡張性 ノード(サーバ)の追加により、データ容量、処 理量を拡張可能 負荷分散レプリケーション 共有ディスク型クラスタ構成 拡張性の制約 可用性・耐障害性 分散データ処理アーキテクチャがデータの冗 ⻑化を管理しており、可⽤性⾼い。 H/A(ホットスタンバイ)やミラーリング データモデル データ構造 キーバリュー構造。 ビッグテーブル型の表形式 ドキュメントデータ構造 リレーショナル・モデル 複雑なデータモデル 問合せ・SQL・⾼度な集計、条 件検索 固有API、get, put 定形的な問合せ アドホッククエリは向かない SQLによる問合せ アドホッククエリ トランザクション・整合性 アトミックな整合性 ノード間の整合性を保障 ACID型トランザクション 整合性を保証 29 2 9 ©2016 Nihon Unisys, Ltd. All rights reserved. NoSQLはキャズムを超えたか？ Cassandra Summit 2015 9/22∼24 サンタクララコンベンションセンタ 参加者 6,100+オンライン参加(5,000) セッション数137 基調講演 ビリー・ボズワース CEO スコット・ギャスリ (MS Excective Vice President ) MSとDataStaxとの戦略的協業発表 Azure上でCassandra利⽤可能 Jonathan Ellis CTO Cassandraの機能ロードマップ 新機能紹介，JSON, UDT, UDF, マテリアライズドビューなど http://itpro.nikkeibp.co.jp/atcl/column/15/061500148/100500026/ 30 ©2016 Nihon Unisys, Ltd. All rights reserved. Apache Cassandraとは Cassandra Amazon Dynamo分散基盤 + Google ビッグテーブル Facebookで開発, 2010年 Apacheトップレベルプロジェクト ユーザー： 現在500社 Netflix, Apple, eBay, Microsoft, RackSpace, Yahoo!, 楽天 ,… 特徴 大規模スループット性能 高負荷への耐久性 大規模で自由なスケールアウト マルチマスターによるSPOF排除 Hadoop，Sparkとの統合 用途： Webスケール企業における利⽤ オペレーショナルDB，コンテンツ管理， Webアクセスログ，時系列データ 最近は，IoTの基盤として， Kafka, Sparkと連携したアーキテクチャ 31 ©2016 Nihon Unisys, Ltd. All rights reserved. Cassandra概要 データの分散と分散されたデータの整合性を保障するための仕組み コンシステントハッシング クライアントのリクエスを受け付けたノードは， コーディネータとして振舞う Partition keyの値によって書き込み対象のノー ドを決定 トークンの全体範囲から，ノードに特定範囲 が割り当てられる。(−2ଷ 〜2ଷିଵ ) 分散処理機能とローカルリソースマネージャ ローカルリソースマネージャ ゴシッププロトコル メモリ管理Memtable，索引処理BloomFilter，デ ータファイルであるSSTableなどの機能から構成 される。 ノード同士が状態の情報を交換することで， ノードの稼働状況を全ノード間で共有する。 コーディネーターノード 一貫性レベル 整合性の保障，ONE, ALL, QUARUM 32 ©2016 Nihon Unisys, Ltd. All rights reserved. データモデルとデータ構造 Column Family ⾏の集合、RDBのテーブルに相当 事前定義が不要（スキーマレス） バージョン2.0以降CQLを推奨 SQLとほぼ同等なクエリ言語, 但し, JOINはできない。 RDBとほぼ同様にSQLによるテーブル定義が可能 但し，主キー，クラスタキー，スタティック属性などの違いがある。 主キーとハッシュキーの関係について理解する必要がある。 33 ©2016 Nihon Unisys, Ltd. All rights reserved. CAP定理と⼀貫性 トランザクションの定義 ACID特性（原子性、整合性(一貫性)、分離性、永続性） アトミシティ，コンシステンシ，アイソレーション，デュラビリティ RDBにおいて一般的 BASE特性（結果整合性） Basically Available、Soft-State、Eventual Consistency 基本的可用性、緩い状態管理、結果的な整合性(一貫性)の保障 AとPを満たす分散システムのトランザクション特性BASE CAPとACIDにおける一貫性 (C) ACIDにおける一貫性 “C” トランザクションの前後において，データの整合性が 保障されなければならない CAPにおける一貫性“C” すべてのクライアントが常に同じデータを参照する 34 ©2016 Nihon Unisys, Ltd. All rights reserved. Cassandraの一貫性の指定 分散システムにおける強い一貫性 W＋R ＞N 書込みノード数 読込みノード数 レプリケーション数 QUORUMの場合は，W=Q, R=Q 但しQ=N/2+1 レプリケーション=3 のクラスタ QUORUMは定足数(合議制における) 例: レプリケーション3の場合 クォーラムによる書き込みと読み出し クォーラム値は，3/2+1=2 読み出し(R=2) 書き込み(W=2) Write Read 一貫性の強さ ONE ONE 弱 ONE ALL 強 ALL ONE 強 QUORUM QUORUM 強 35 X* X* X ノード1 ノード2 ノード3 ©2016 Nihon Unisys, Ltd. All rights reserved. Cassandraのトランザクション 通常のACID型のトランザクションはサポートされない 更新の反映は，⼀貫性レベルの指定によって調整可能 単純にBASEではない。 特定の条件の下で，ACIDトランザクションが実⾏可能 ⼀つの更新SQLによる更新（軽量トランザクション） 複数更新SQLによる更新：但し同⼀テーブル，同⼀パーティションキー（ アトミックバッチ+軽量トランザクション） 機能 説明 軽量トランザクション Lightweight Transaction ・楽観的トランザクション (ACID，但し制約あり) ・単⼀更新SQL ・内部的にPAXOSコミットを実⾏(2PC) アトミックバッチ Atomic Batch ・アトミック性(A)と永続性(D)のみ. CとIは保障されない。Dはオプション。 ・軽量トランザクションを実⾏した場合，楽観的トランザク ションとなる。 36 ©2016 Nihon Unisys, Ltd. All rights reserved. 送⾦トランザクションの例 口座Aから口座Bに1000円送⾦ 更新前 更新後 ユーザID 口座 … ユーザID 口座 … A 2000 … A 1000 … B 5000 … B 6000 … C 800 … C 800 … ・・・ ・・・ … ・・・ ・・・ … ACIDトランザクションが必要 RDB （ACIDトランザクション） SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘A’ FOR UPDATE ; SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘B’ FOR UPDATE ; UPDATE 残高 SET 残高＝残高 - 1000 WHERE 口座ID＝’A’ ; UPDATE 残高 SET 残高＝残高 + 1000 WHERE 口座ID＝’B’ ; COMMIT : Cassandraで実現可能？ 37 ©2016 Nihon Unisys, Ltd. All rights reserved. 同時実⾏制御の検討 軽量トランザクションでは，複数の更新SQL間における排他制御 を保障できない。 軽量トランザクションによる限定的なACIDトランザクション 楽観的制御 排他ロックによる制御 トランザクション-t1 トランザクション-t1 トランザクション-t1 SELECT FOR UPDATE トランザクション-t1 SELECT X (X=5) SELECT X 更新ロック待ち (X=5) SELECT FOR UPDATE 排他ロック X=6に更新 UPDATE SET X=6 IF(X=5) UPDATE UPDATE SET X=6 IF(X=５) COMMIT 更新ロックOK アボート！ UPDATE 38 ©2016 Nihon Unisys, Ltd. All rights reserved. 複数データ更新の整合性を保証するためには 口座Aから口座Bに1000円送⾦ ロック確保 軽量トランザクション ( 楽観的トランザクション) アトミックバッチ 軽量トランザクション /QUORUM更新 ユーザID 口座 … lock A 2000 … T B 5000 … T C 800 … - ・・・ ・・・ … - LOCK (A) ; LOCK (B) : ユーザID 口座 … lock A 1000 … - B 6000 … - C 800 … - ・・・ ・・・ … - ユーザID 口座 … lock A 1000 … - B 6000 … - C 800 … - ・・・ ・・・ … - 39 トランザクション開始 SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘A’ ; SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘B’ ; UPDATE 残高 SET 残高＝残高 - 1000 WHERE 口座ID＝’A’ ; UPDATE 残高 SET 残高＝残高 + 1000 WHERE 口座ID＝’B’ ; COMMIT UNLOCK (B) ; UNLOCK (A) : ©2016 Nihon Unisys, Ltd. All rights reserved. 簡易TPC-B (JDBCBench) TPC-B：オフラインでのバッチ処理をモデル化したベンチマーク JDBCBenchを使用 テーブル： branches : 銀⾏の支店 tellers : 銀⾏員 accounts : 銀⾏口座。支店あたり10万口座 history : 取引履歴 評価環境： CPU Core i3-4150 3.5 GHz メモリ: 32GB 32GB HDD 500GB Cassandra構成 クラスタ最大9台構成 レプリケーション数３ ノード数：9 台 40 ©2016 Nihon Unisys, Ltd. All rights reserved. ユースケース：IoT基盤としてのCassandra Kafka+Cassandra+SparkによるIoT基盤アーキテクチャ Lambda at Weather Scale - Cassandra Summit 2015 (参照)http://www.slideshare.net/helenaedelson/lambda-architecture-with-spark-streaming-kafka-cassandra-akka-scala 41 ©2016 Nihon Unisys, Ltd. All rights reserved. (参考) 構築事例： 疫学データベース基盤 複数医療機関からの診療, 健診データの蓄積基盤 疫学データベース構築，医療研究・予防医学、患者指導に利⽤ 地域や集団内で、疾患や健康に関する事象の発生の原因・因果関係を研究 診療データをCassandraに格納 MapReduceにより並列ロード 全⽂検索システム構築のため，N-gramモデルのための転置索引を作成 患者基本情報 処方オーダー 個人情報DB 疫学データベース 診療データ (SS-MIX) 注射オーダー MapReduce 個⼈情報管理 名寄せ処理 検診オーダー Cassandra 格納形式データ 来院情報 データ形式 変換 病名情報 HDFS 検診データ 42 ©2016 Nihon Unisys, Ltd. All rights reserved. 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ ブロックチェーンとは 2008 年 11 月、Satoshi Nakamoto による論⽂「Bitcoin: A Peer-to-Peer Electronic Cash System」が始まり ビットコインの特徴 第三者機関を必要としない直接取引の実現 非可逆的な取引の実現 信用コストの削減(小額取引)，⼿数料の低コスト化 二重支払の防止 要素技術 ハッシュ関数(一意性) 公開鍵暗号化(電子署名) P2Pネットワーク Proof of Work (参考) ・平成２７年度 我が国経済社会の情報化・サービス化に係る基盤整備 （ブロックチェーン技術を利用したサービスに関する国内外動向調査）報告書, .株式会社野村総合研究所, 平成 28 年 3 月. ・斉藤賢爾,「ビットコインにおけるトランザクション、その展性と影響」，2014/05/16 . ・日経コンピュータ (編集) , FinTech革命(日経BPムック) 単行本, 2015/12/14 . 44 ©2016 Nihon Unisys, Ltd. All rights reserved. ブロックチェーンによるトランザクション ブロックチェーン 分散型台帳技術、または分散型ネットワーク 複数ノードに台帳データベースを配置し，Proof of Work(注)によって取引を認証 取引履歴の全体がチェーン状に連鎖し，ブロックの正当性を継承する仕組みを実現する。データの改 竄は実際上不可能とされる。 (注)Bitcoinの採掘を⾏う作業(マイニング)。ブロック内容から規定の値(連続する0)を含むハッシュ値を求 めるために加えるnonceを求めることにより，ブロックの承認を⾏う。約10分に1回程度で計算できるよ うに調整される。 時系列のブロックの連鎖により取引を記録 ブロック ブロック ブロック 複数の取引(トランザクション)を 一つのブロックに格納 ・・・ ⾦額 送⾦者 受領者 トランザクション 45 ©2016 Nihon Unisys, Ltd. All rights reserved. ブロックチェーンによるトランザクション(2) 口座Aから口座Bに1000円送⾦ 更新前 RDB （ACIDトランザクション） 更新後 SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘A’ FOR UPDATE ; ユーザID 口座 … ユーザID 口座 … SELECT 残高 FROM 口座テーブル WHERE 口座ID=‘B’ FOR UPDATE ; A 2000 … A 1000 … UPDATE 残高 SET 残高＝残高 - 1000 WHERE 口座ID＝’A’ ; B 5000 … B 6000 … UPDATE 残高 SET 残高＝残高 + 1000 WHERE 口座ID＝’B’ ; C 800 … C 800 … COMMIT : ・・・ ・・・ … ・・・ ・・・ … 取引要求 新たなブロック を通知 PoW ハッシュ計算 通知 通知 ブロックチェーンの分岐 ・・ ・・ 同時にPoWが成功した場合，チェーンが分岐する可能性がある。 その場合，分岐以降，より早くブロックがつながった方を正当な ものと⾒なす。(通常は6ブロック程度先に繋がった⽅を正当と⾒なす) 46 ©2016 Nihon Unisys, Ltd. All rights reserved. ブロックチェーンによるトランザクション(3) 分散の形態 各ノード上にブロックチェーンの複製が存在 コミットの考え方 更新の確定(コミット処理)は，PoWによるハッシュ計算が完了した時点 同期をとってコミットするという考え方ではない。 取引データベースを公開し，不正を排除するための⽅式 ACID特性は満たさない。 同期整合性は保障されないため，BASE (結果整合性)と解釈できる。 ビザンチン将軍問題 ビザンチン将軍問題の解決に準ずる⽅式と考えられるが，まだ議論がある。 CAP定理 APを満たす。 すべてのノードが同じデータベース(ブロックチェーン)のコピーを持っているため，無停止を 実現 ネットワーク分断におけるブロックチェーンの分岐では，復旧時により⻑いブロックチェーン が正当となるため，分断耐性を備えていると考えられる。 47 ©2016 Nihon Unisys, Ltd. All rights reserved. ブロックチェーン, RDB, NoSQL比較 ブロックチェーン (Bitcoin) RDBMS NoSQL (Cassandra) 分散アーキテクチャ P2P 単一ノード P2P, 分散ハッシュ データの分散方式 全ノードが同じDB(ブロッ クチェーン)保持 ー コンシステント・ハッシン グ DDL, DML 定型データ型 スクリプト言語 SQLによるスキーマ定義， 問合せ言語 CQLによるスキーマ定義， 問合せ言語 データモデル ブロックチェーン リレーショナルモデル リレーショナルモデル(サブ セット) トランザクション 特定のトランザクション処 理 ACID特性トランザクショ ン 一貫性レベルに応じたトラ ンザクション 一貫性 Proof of Workによる確率的 保障 あり：ACID特性 一貫性レベルによる BASE(結果整合性) 排他制御 ロック制御方式は用いない が，出入の整合性は保障さ れる。 共有・排他ロック方式 軽量トランザクション。そ れ以外上書き。 スケーラビリティ DBの拡張性は無し マイニングの計算能⼒ ー あり 可用性 あり (AP?) ー あり(AP) レスポンス 非同期，コミット確定まで 10分 同期コミット，レスポンス タイム：ミリ秒 一貫性レベルによる。レス ポンスタイム：ミリ秒 48 ©2016 Nihon Unisys, Ltd. All rights reserved. ブロックチェーンのまとめ ブロックチェーンはどうDBMSではないのか？ DBMSとして一般的な機能性を持たない ⼀元的なデータの管理 汎用的操作言語（専用のスクリプト言語を使用） ACIDトランザクション 固有のデータモデル 非集中分散型(Decentralize)によるデータ管理 データベースは，提供，運⽤，管理が⼀元的に⾏われることを前提 一元的な管理システムによらず，トランザクションの整合性を実現できることは画期的 多様化する技術 Ripple • Googleが出資したことが話題となった。ブロックチェーンの課題(スケーラビリティや確定時間の短縮化)を 改善。https://ripple.com/ Mijin • ⽇本発のブロックチェーン。複数のアセットを管理可能。出⼊⾦だけでなく複雑な計算処理や契約管理が可 能。2016年の実証検証において5,000/秒トランザクションを実現。http://mijin.io/ja/ Enigma • MITメディアラボが開発。完全準同型暗号によりデータのプライバシー保護を実現し，スケーラブルなデー タ分析を可能とする。データをシェアせず秘密分散により分散した状態でデータ分析を可能とする。 http://enigma.media.mit.edu/ 49 ©2016 Nihon Unisys, Ltd. All rights reserved. 1 背景 2 RDBMSのリファクタリング 3 ⼤規模分散処理の発展Hadoop, Spark, NoSQL 4 DBMSから⾒たブロックチェーン 5 まとめ まとめ− データベース技術の展望 IT環境の発展によりアプリケーションが多様化 ソフトウェア，ハードウェア技術の進化により，データマネージメントに求められる要求も多様化 分散システム，メニーコア，大規模メモリ・・ ブロックチェーンのような新たなデータ処理も登場 汎用用途のRDB時代からの脱却 ビッグデータ時代のデータマネージメントに求められる3Vへの対応 Volume（量） Velocity（速度） Variety（多様性） OLTP, DWH, データ分析 各用途におけるビッグデータ，WebスケールIT指向へ One size fits allからOne size fits oneへ DBMSのさらなるRewrite, Reengineering, Refactoring メニー・コア 大規模メモリ 不揮発メモリ（ストレージクラス・メモリ） DBMS技術とハードウェア技術との連携と融合 51 ©2016 Nihon Unisys, Ltd. All rights reserved. まとめ − データベース技術の展望(続き) データベース技術の動向 今，DB技術は大きな変革期 HadoopからSpark，NoSQL Cassandra, MongoDB 統合アーキテクチャ ラムダアーキテクチャ，SQL on Hadoop 新たなストレージとしてのデータレイク H/W，S/Wの融合 In-DBデータ分析からIn-Chipデータ処理 企業内・企業外のデータ管理 必要なデータを集められるキュレーション プライバシー保護の保障 データマネージメントの⾃律化 Self Management Database System 商用RDBでは既に言われているが，その先はあるか？ 52 ©2016 Nihon Unisys, Ltd. All rights reserved.
© Copyright 2024 ExpyDoc
