高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース GridDB
•
1 j'aime•218 vues
「オープンソースビジネス推進協議会（OBCI）セミナー「今さら聞けないビッグデータとディープラーニング」(2016年10月26日セミナー資料)」 高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース GridDB
Recommandé
Recommandé
Contenu connexe
Similaire à 高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース GridDB
Similaire à 高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース GridDB (20)
Plus de griddb
Plus de griddb (20)
Dernier
Dernier (8)
高速処理と高信頼性を両立し、ペタバイト級の多種大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース GridDB
- 1. © 2016 TOSHIBA CORPORATION 高速処理と高信頼性を両立し、 ペタバイト級の多種大量データを蓄積する、 ビッグデータ/ＩｏＴ時代のデータベース 株式会社 東芝 インダストリアルICTソリューション社 IoTテクノロジーセンター 先端ソフトウェア開発部 野々村 克彦
- 2. 2 目次 1.はじめに – ビッグデータ – NoSQL – IoTと既存NoSQLの課題 2.GridDB – オープンソース化 – 特長 – 適用事例 – 公開サイト 3.まとめ
- 3. 3 • ビジネスの価値を向上させるビッグデータ活用が本格化 – センサーデータ、履歴データなど多様なデータが日々増加 • ビッグデータ管理の要件に合わせたデータベースが必要 ビッグデータ ビッグデータ管理は柔軟な拡張性が必須 リスク回避 効率向上 新価値創造 データ増加 分析＆ビジネス価値向上ビッグデータ管理 非構造 データ 高速性 可用性 大容量VOLUME VELOCITY VARIETY センサ ログ 株価 履歴
- 4. 4 • RDB – スケールアップでは限界がある。ビッグデータを管理するのに適していない – 一貫性を重視するため、スケールアウトは困難である • NoSQL(Not Only SQL) – キーによるPut/Getが基本I/F（キーバリュー型） – スケールアウトによる性能向上で近年注目されている – 一貫性を緩和する代わりにRDBでは対応できない規模の 大容量データを管理可能である RDBとNoSQL Key Value Key Value Key Value Node A Node B Node C スケールアウト RDB スケールアップ (CPU、メモリ、ディスク） NoSQL
- 5. 5 NoSQLのデータモデル データモデル キーバリュー型 列指向型 ドキュメント型 NoSQLの例 Riak Cassandra MongoDB キー バリュー キー カラム バリュー カラム バリュー キー JSON
- 6. 6 • IoT(Internet of Things、モノのインターネット) – 一意に識別可能な「もの」がインターネット/クラウドに接続され、情報交換す ることにより相互に制御する仕組み ※「IoT」『フリー百科事典 ウィキペディア日本語版』 • 特性 – 分、秒周期、さらにはそれ以下の周期で発生する膨大なセンサーデータを扱 う必要がある。長時間に渡るデータを保持する必要がある。 – 各センサ内のデータ欠損や参照データの矛盾など、データ一貫性やデータ整 合性を保つ必要がある。 IoT IoTデータ（センサー、ログ、履歴、株価等）人の活動で生成されるデータ ・SNS、ゲームなど ・テキスト、イメージデータ ・インメモリ前提 時間 処理数 時間 処理数
- 7. 7 （Ａ）IoTのデータ管理が困難 – センサ単位の一貫性を保てない。時間範囲指定の検索ができない、 メモリが足りない場合に性能が大幅に劣化、など （Ｂ）既存クラスタ管理方式に起因するトレードオフ問題 IoTにおける既存NoSQLの課題 ピアツーピア(Peer to Peer) マスタスレーブ(Master Slave) ○ノード追加でのデータ再配置が容易 ×一貫性維持のためのノード間通信のオーバヘッ ドが大⇒一貫性と処理速度がトレードオフ ○一貫性の維持は容易 ×マスタノードが単一障害点(SPOF) ×ノード追加でのデータ再配置が難しい Node A Node B Node C Node D Node A Node B Node C Node D Master Master’ HA
- 8. 8 （Ａ）IoTのデータ管理が困難 – センサ単位の一貫性を保てない。時間範囲指定の検索ができない、 メモリが足りない場合に性能が大幅に劣化、など （Ｂ）既存クラスタ管理方式に起因するトレードオフ問題 IoTにおける既存NoSQLの課題 ピアツーピア(Peer to Peer) マスタスレーブ(Master Slave) ○ノード追加でのデータ再配置が容易 ×一貫性維持のためのノード間通信のオーバヘッ ドが大⇒一貫性と処理速度がトレードオフ ○一貫性の維持は容易 ×マスタノードが単一障害点(SPOF) ×ノード追加でのデータ再配置が難しい Node A Node B Node C Node D Node A Node B Node C Node D Master Master’ HA ①キーコンテナ型のデータモデル ③ハイブリッド型のクラスタ管理
- 9. 9 目次 1.はじめに – ビッグデータ – NoSQL – IoTと既存NoSQLの課題 2.GridDB – オープンソース化 – 特長 – 適用事例 – 公開サイト 3.まとめ
- 10. 10 • GridDBとは – IoTデータ管理向けのスケールアウト型DB • GitHub上にNoSQL機能をソース公開(2016/2/25) – https://github.com/griddb/griddb_nosql/ • 目的 – ビッグデータ技術の普及促進 • 多くの人に知ってもらいたい、使ってみてもらいたい。 • いろんなニーズをつかみたい。 – 他のオープンソースソフトウェア、システムとの連携強化 オープンソースのGridDB
- 11. 11 GridDBの特長 ① IoT向けデータモデル – キーコンテナ型のデータモデル ② 高パフォーマンス(High Performance) – メモリ指向アーキテクチャ ③ 高信頼性(High Reliability) – （P2Pとマスタスレーブの）ハイブリッド型のクラスタ管理技術 ④ 高スケーラビリティ(High Scalability) – 自律データ再配置（ＡＤＤＡ）技術
- 12. 12 キーコンテナ型のデータモデル – キーバリューをグループ化するコンテナ（テーブル） – コンテナのスキーマ定義が可能。カラムにインデックスを設定可能 SQLライクなクエリ(TQL)が利用可能 – レコード単位でトランザクション操作（コンテナ単位でACID保証） ① IoT向けのデータモデル 単純なキーバリュー型とは異なり、使い慣れたRDBに近いモデリングが可能 ※ACID : Atomicity、Consistency、Isolation、Durability 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 2015/01/01 1:00 0.68874 0.353611 2015/01/01 2:00 7.677135 5.881216 2015/01/01 3:00 3.731816 2.511166 2015/01/01 4:00 9.739242 0.655805 … … … 機器１ テーブル表現で管理 対象毎にIoTデータを格納機器センサー 機器1 機器2 機器N データ格納 日時 センサA センサB 2015/01/01 0:00 7.788683 0.648364 キー コンテナ IoTデータ 株価 履歴 ログ 機器1のレコード
- 13. 13 • コンテナの種類 – コレクションコンテナ：レコード管理用 – 時系列コンテナ：時刻で並べられたレコード集合。時系列データ管理用 • 期限解放機能、サンプリング機能など データモデルの比較 データモデル キーバリュー型 列指向型 ドキュメント型 キーコンテナ型 NoSQLの例 Riak Cassandra MongoDB GridDB キー バリュー キー カラム バリュー カラム バリュー キー C0 C1 C2 C3 Val Val Val Val Val Val Val Val Val Val Val Val スキーマ コンテナ キー JSON
- 14. 14 RDB メモリ指向アーキテクチャ – イベント駆動エンジンであるため、少ないリソースで多くの要求を無駄なく処理 – メモリ、ディスクアクセスの排他処理や同期待ちを極力排除した、オーバヘッド の少ないデータ処理 – GB超級のメモリ搭載を前提とし、読み書きサイズを最適化しI/O効率を改善 ② 高パフォーマンス H/Wのスペックを最大限に生かすインメモリ指向DB トランザクション管理 クエリ処理 バッファ処理 要求処理 I/O処理 ５～10% イベント駆動エンジン GridDB Node
- 15. 15 代表的NoSQLとの性能比較 0 100 200 300 400 500 600 A B C D F Throughput(Kops/sec) YCSB Workloads 32 Node Cluster 読み書き混在する処理パタンで 5倍以上高速 GridDB • Azure上でYahoo! Cloud Serving Benchmark(YCSB)を 実行。GridDBは高速性を売りにする代表的NoSQLと比較しても 、数倍高速 ※YCSB：http://labs.yahoo.com/news/yahoo-cloud-serving-benchmark
- 16. 16 ハイブリッド型クラスタ技術 – ノード間で自律的、動的にマスタノードを決定。単一故障点（ＳＰＯＦ）を 排除 – レプリケーションによるデータ多重化、フェールオーバーが可能 – 永続化（インメモリ／ディスク併用） ③ 高信頼性 特別なスキルを必要とせずに、高可用なクラスタ構成が可能 データ配置管理情報（キャッシュ） 管理マスタ Client オリジナル レプリカ オリジナル レプリカ オリジナル レプリカ オリジナル レプリカ オリジナルレプリカ Client Client データ配置管理情報 自律的クラスタ構成 フェイルオーバー ノード１ ノード２ ノード３ ノード４ ノード５ データレプリケーション
- 17. 17 自律データ再配置技術（ＡＤＤＡ：Autonomous Data Distribution Algorithm） – インバランス状態を検知、長期同期プランニング – ２種類のデータを使ってバックグラウンド高速同期、完了後切替 ④ 高スケーラビリティ APL APL APL APL APL APL APL APL APL DB更新ログ （短期同期） メモリブロック （長期同期） 現状 目標 長期同期 プランニング ①負荷インバランス検知 ②長期同期プランニング ③長期同期実行 ④アクセス切替
- 18. 18 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 t1 t3 t5 t7 t9 t11 t13 t15 t17 t19 t21 t23 t25 t27 t29 t31 オリジナル(N1) レプリカ(N2) 新レプリカ(N3) DB更新ログ メモリブロック N１ N2 N3 メモリブロック DB更新ログ スローダウン 短期同期 t11 t25 更新水位 長期同期 プランニング サービス継続 高速 長期同期 障害発生 ⇒ バランスが崩れる レプリカ数が減る
- 19. 19 適用事例：電力会社 従来システムと比べて1,500倍のデータ量を 2,250倍の処理能力で対応 電力小売り事業者に対し、電力送配電網を提供し、契約ユーザの利用量に応じた料金を請求するシステム 電力の自由化に伴い、多数の電力小売り事業者が参入し、契約数の増加（3,000契約→450万契約）による データ量の爆発的増加へビッグデータ技術を適用し対応 入力データ 2.16億レコード (43.2GB) GridDB 処理時間＝40分 出力データ 3072MB (XML) サーバ(12コア)×5台 入力データ 14.4万レコード (28.8MB) RDB 処理時間＝60分 出力データ 2MB (XML) サーバ(32コア)×１台 データ量 1,500倍 処理能力 2,250倍 全体スループット 8KB/sec 全体スループット 18,000KB/sec
- 20. 20 Webサイト • コミュニティ版・サイト – https://github.com/griddb（日/英） サーバ(AGPL 3.0)、 Javaドライバ(Apache 2.0) Hadoop MapReduceコネクタ(Apache 2.0) ※括弧内はライセンス – 問合せ先：contact@griddb.org • デベロッパーズ・サイト – https://www.griddb.net（日/英） ホワイトペーパ、テクニカルリファレンス、 サンプルコードなど – フォーラム： https://www.griddb.net/ja/forum/top/ – SNS(Facebook、Twitter)
- 21. 21 目次 1.はじめに – ビッグデータ – NoSQL – IoTと既存NoSQLの課題 2.GridDB – オープンソース化 – 特長 – 適用事例 – 公開サイト 3.まとめ
- 22. 22 • GridDBは高速処理と高信頼性を両立し、ペタバイト級の多種 大量データを蓄積する、ビッグデータ/ＩｏＴ時代のデータベース です。 – High Performance – High Scalability – High Reliability まとめ オープンソースのGridDBを是非とも使ってみてください。 ● 本資料に掲載の製品名、サービス名には、各社の登録商標または商標が含まれています。
- 23. 23