Shinagawa Osaki
3. 要求の追加
オープンデータ連携からの要求
• インターネット上のオープンな巨大データ集積が増え
それらを自動連携させる枠組みがこれからの課題になる
ビッグデータ利用からの要求
• 交通実証やビッグデータ連携などにより
刻々変わるストリーム型の状況情報への対応が必要に
Copyright 2013 by Ken Sakamura
ストリーム型の状況情報の例
●
駅の位置{駅uc 5 , 関係uc 6 , 地理座標}
●
路線と駅の関係{区間F064, 関係uc
7
,駅102}{区間F064, 関係uc
7
,駅103}{駅102, 関係uc
6
, 35.627163, 139.722698}動的状況を重ねることで…
静的状況と…
TRONSHOW2O14
「 u1 」の総括の上で
モデル研究プロジェクトとしての u1
•
u1でIoTのための統一されたデータ表現の情報モデルを確立グローバルにオブジェクト／概念を識別するためのucode データの共通表現のためのucR （ucode Reration）
u1 の考えに基づいた実用的な実装を
•
現在の技術に基づいてCopyright 2013 by Ken Sakamura
IoT 実現への課題
● IoT 実現のための多くの課題
1.
ユビキタスID
サービスの安定性•
高負荷時の性能維持、24
時間/
週7
日の信頼性2.
計算の複雑性とパフォーマンス•
部分グラフマッチングのNP
困難性、...
3.
管理の複雑さ•
数十億のucode
を管理する方法4.
敵対行動に対する保護•
悪意のある第三者からのDDoS
攻撃● これらの実用にあたっての課題を解決することを
TRONSHOW2O14
Copyright 2013 by Ken Sakamura
④ -1
uID サービスの安定性
uID サービスの安定性
● 最新のクラウドコンピューティング技術を 使った実装
IaaS (Infrastructure as a Service)
、OpenStack
、ロードバランサの導入、...
• Amazon EC2
やGoogle Compute Engine
の利用...
● u2 サービスは、 IaaS のサービス上で実現
現在u2WG
メンバーにリリース
TRONSHOW2O14
Copyright 2013 by Ken Sakamura
④ -2
計算の複雑性とパフォーマンス
計算複雑性とパフォーマンス
● 大規模グラフデータベースは、本質的に計算困 難である
「計算複雑性理論」から知られている•
部分グラフ同型問題のNP
完全性のため、グラフ・クエリはNP
困難Intractable
(cannot be solved efficiently for large data)
Tractable
(can be solved efficiently) 計算量クラス階層
EXPSPACE EXPTIME
PSPACE NP
P NL
TRONSHOW2O14
クエリに対する制限
Copyright 2013 by Ken Sakamura
● 実用のために設計されたのが u2
u1
のモデルに基づいているが、u2
の目的は実用的なIoT
情報フレー ムワークを実現すること
この計算複雑性とパフォーマンス問題を解決する必要がある● u2 は、この問題に対する新たなソリューションを提供
u2
では、ucR
グラフとクエリはいくつかの条件を満たすように制限され ている• ucR
グラフは語彙定義の制限がある（例えば「含んでいる」という述語は、ツリー構造でなければならない）
•
クエリでは任意の語彙集合にマッチするワイルドカードを述語として持てない
これらの現実的制限によりucR
モデルに基づいた実践的かつ十分に 柔軟なIoT
情報フレームワークを実現することが可能となるu2 の基本コンセプト
多様な DB の API に対するクロスクエリを
組織や DB 構成を超えて行える情報連携基盤
• その中でucRネイティブのDBはリクエストが確定できない複
雑な関係処理の考えられるデータ群を扱うものとする
TRONSHOW2O14
既存の DBMS の利用
Copyright 2013 by Ken Sakamura
● 定型的で制約ある関係でまとまったデータ群は、そ のスキーマに適した既存の DBMS に接続する
定型的で制約ある関係の語彙のグループをDB
のドメインに相当させ る
既存のDBMS
を簡単なラッピングで仮想的なucR DB
としてシステム に統合できるようにする KVS
によるDB
やGIS
など、本来のucR
と性質の違うスキーマの確定さ れたDB
も、この仮想的なucR DB
化により統合する● これによりデータの種類や問題に適したアルゴリズ ム・データ構造を効率よく扱えるようにする
「現在位置から1km
以内にあるコンビニを検索」→ GIS: R
木(R-tree)
を利用
「大量のセンサデータを扱う」→ KVS:
分散ハッシュテーブル(DHT)
を利用
u2
RDB
クエリ分解・レスポンス統合による クロスクエリ
KVS RDF
ucR
RDB KVS
Query
Decomposition
GIS
Response Reconstruction
Mobile Application
ucR Response ucR Query
TRONSHOW2O14
ucodeRP2.0
ucode 解決プロトコル 2.0
IoT の実現に必要な情報を集約・統合するための プロトコル
• ucR (ucode relation)モデルに基づくオープンモデルによる 組織を超えたデータ連携を意図した設計
既存のRDBやKVS等のデータベースを統合し、クロスクエリを可能にする仕組み
Copyright 2013 by Ken Sakamura
ucode 解決プロトコル 2.0
● ucode Resolution Protocol ver.2 は REST/CoAP, REST/HTTP, JSON を前提にする
● DB のドメインに相当する語彙グループに属する ucR クエリをサブクエリとして分解し処理する
解決サーバがucR
クエリを受信すると、それを解釈し、必要な語彙グ ループ単位に分割して、対応するラッパー「uCR
アダプタ」に向けて分 割したサブクエリを発行する● 分散データベース構成を実現する
ucR
解決サーバフロントエンドは分散データベース構成で、対応するDB
のドメインが不明な語彙は、より上位の解決サーバに送り解決結 果を待つというカスケード動作を行う
データ秘匿等の要請もあり、ローカルなucode
解決フロントエンドサーTRONSHOW2O14
ucodeRP2.0 の動作
Copyright 2013 by Ken Sakamura
uID Center
ロードバランサ
ucR解決サーバ フロントエンド群
利用者(1) ucodeRP2.0 によるクエリ
会社Aのサーバ
ドキュメント内
TS2014u2
(ページ 42-56)