[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシアムデータベース部会吉田行男

© Hitachi Solutions, Ltd. 2017. All rights reserved.
株式会社日立ソリューションズ
技術革新本部研究開発部
2017/06/16
吉田行男
IoT時代のデータストア
0
--躍進するNoSQL、拡張するRDB

０-１自己紹介
1
【経歴】
 入社当時は、金融端末のソフトウェア開発に従事。
 2000年頃から、Linux/OSSのビジネス開発を担当。
 2012年から、オープンソース専門組織に所属。
【現在の業務】
 OSSを活用したビジネス構築のための支援
• 新しい技術/OSSの発掘・評価検証
• ビジネス・ソリューションの立ち上げ支援
• 現在特にフォーカスしている領域：
クラウド基盤(OpenStack)
ビッグデータ(Hadoop、NoSQL, Spark)
Enterprise(PostgreSQL, OpenCOBOL)
【その他】
 OSSコンソーシアム副会長
 日本OSS推進フォーラムビッグデータ部会長
 より賢く活用するためのOSS最新動向
http://japan.zdnet.com/software/sp_15yoshida/

※OSSfm(thinkIT)
２
https://thinkit.co.jp/article/11711 https://thinkit.co.jp/article/11781

※より賢く活用するためのOSS最新動向(ZDNet Japan)
3
https://japan.zdnet.com/article/35100222/
https://japan.zdnet.com/article/35098937/

１. 市場動向
２. ビッグデータ関連OSS動向調査
４. 選定指針
Agenda
4
３. NoSQLとは？
５. 最近の動向

１-１国内オープンソースソフトウェア利用実態(①)
5
 国内オープンソースソフトウェア
利用実態
 企業におけるOSSの導入率は31.3%、
前年（31.5％）および一昨年（32.0％）の
調査からの大きな変化なし。
 産業分野別：通信/情報(39.2%)>公共／
公益(37.6%)＞金融(35.4%)の順。
 従業員規模別では、1,000人以上で導入
が活発。100人～499人が最も低調。
 中小企業ではOSSを導入して管理する人
材が乏しいのが原因？
 IaaS利用企業の42.5％及びPaaS利用
企業の53.1％がOSSを積極的に使用して
いくという方針。
 クラウドサービスの普及がOSS使用拡大
のドライバーに！
出典：IDC「2016年度国内オープンソースソフトウェア
利用実態調査結果」

１-１国内オープンソースソフトウェア利用実態(②)
6
「2016年度」「2015年度」

１-２オープンソースの適用状況
■ 「OS」から「ミドルウェア、アプリケーション」、さらに「新技術」領域へ
オペレーティングシステム
Linux
Webサーバー
Apache/nginx
アプリケーションサーバー
Tomcat / JBossAS
データベース
MySQL / PostgreSQL
スマートフォン用
プラットフォーム
Android/
Firefox OS/
Tizen
アプリケーション
領域
ミドルウェア領域
オペレーティング
システム
サーバ領域端末領域
情報家電向けLinux
CRM
SugarCRM
ERP
Compiere /
ADempiere
勤怠管理
MosP
オフィス
スイート
OpenOffice/
LibreOffice
シングルサイン
オン
OpenAM
ポータル
Liferay
BI
Jaspersoft
/Pentaho
ECM
Alfresco
運用監視
Zabbix/
Hinemos
分散処理基盤
Hadoop/Spark
クラウド基盤
OpenStack
構成管理
ansible/
chef/puppet
7
新技術領域

２．ビッグデータ関連OSS動向調査
8

２-１ビッグデータ基盤を構成する機能
 主に、さまざまなデータを「収集・検知」する機能、収集・検知したデータを「蓄積・貯蔵」
する機能、蓄積・貯蔵したデータを「分析」する機能から構成される
データソースデータ収集・検知ビッグデータ蓄積・貯蔵・その他
高速化キャッシュ/スケールアウト
データ分析
分析用データ
Apache Hadoop MapReduce
Apache Hadoop YARN
Apache Mesos
Apache Spark
Apache Tez
並列分散処理
Apache Drill
Apache Hive
Apache Spark SQL
Impala
準リアルタイムクエリ
Apache ManifoldCF
Apache Nutch
クローラ
Apache Sqoop
Talend
データロード
Apache Flume
Fluentd
収集
Apache S4
Apache Spark
Streaming
Apache Storm
Esper
Drools Fusion
Jubatus
CEP
Apache Hadoop HDFS
Ceph
GlusterFS
Lustre
データ蓄積ファイルシステム
MIT Kerberos
OpenLDAP
セキュリティ/認証
Hinemos
Zabbix
運用管理/監視
Webデータ
売上情報など
センサデータ
システムログ
音声
画像
構造化データ
（業務RDB）
非構造化データ
Apache Sqoop
データロード
Apache Cassandra MongoDB
Apache Hbase Redis
Infinispan Riak
運用管理/監視
クローラ
データロード
収集
CEP
Complex Event
Processing
データ蓄積
ファイルシステム
並列分散処理
データロード
定型業務DB
インメモリDB
DWH/ﾏｰﾄﾚｽDBインメモリDG/分散KVS
9
Analysis Tools
Mlib
Jubatus
機械学習
R
統計分析
Pentaho
JasperReports
SAS
MicroStorategy
BI/BA ツール
ElasticSearch
全文検索
Caffe
Chainer
CNTK
Deeplearning4j
DSSTNE
PredictionIO
ディープラーニング
TensorFlow
Theano
Torch7
機械学習
全文検索
BI/BAツール

２-２ビッグデータ基盤を構成する機能へのソフトウェアマッピング
 ビッグデータ基盤をオープンソースをベースとして構成することは十分に可能
 ただし、個々のソフトウェアにおいて品質や成熟度が異なるため、見極めが必要
データソースデータ収集・検知ビッグデータ蓄積・貯蔵・その他
高速化キャッシュ/スケールアウト
Apache Hadoop MapReduce
Apache Hadoop YARN
Apache Mesos
Apache Spark
Apache Tez
並列分散処理
Apache ManifoldCF
Apache Nutch
クローラ
Apache Sqoop
Talend
データロード
Apache Flume
Apache Kafka
Fluentd
収集
Apache S4
Apache Spark
Streaming
Apache Storm
Esper
Drools Fusion
Jubatus
CEP
Apache Hadoop HDFS
Ceph
GlusterFS
Lustre
ElasticSearch
データ蓄積ファイルシステム
Hinemos
Zabbix
運用管理/監視
Webデータ
売上情報など
センサデータ
システムログ
音声
画像
構造化データ
（業務RDB）
非構造化データ
Apache Sqoop
データロード
Apache Cassandra MongoDB
Apache Hbase Redis
Infinispan Riak
インメモリDG/分散KVS
MIT Kerberos
OpenLDAP
Apache Drill
Apache Hive
Apache Spark SQL
Impala
10
データ分析
Data to be analyzed
Analysis Tools
Mlib
Jubatus
Hivemall
機械学習
R
統計分析
Pentaho
JasperReports
SAS
MicroStorategy
BI/BA ツール
MySQL
PostgreSQL
定型業務RDB
* OSSで著名なもの
はない
DWH/ﾏｰﾄﾚｽDB
VoltDB
インメモリDB
ElasticSearch
全文検索
Caffe
Chainer
CNTK
Deeplearning4j
DSSTNE
PredictionIO
TensorFlow
Theano
Torch7

２-３調査観点
11
•以下の視点で調査
開発の活性度
そのソフトウェアは活発に開発されていますか？
ビジネスの活性度
そのソフトウェアはビジネスで活用されていますか？
技術者の注目度
そのソフトウェアはどれくらい注目されていますか？
技術情報の充実度
そのソフトウェアの情報はどれくらい豊富にありますか？
(*)http://www.ossforum.jp/jossfiles/SS3.pdf

開発の活性度
そのソフトウェアは活発に開発されていますか？
12

２-４「開発の活性度」の調査項目
13
•開発者数
– 2016年に開発リポジトリ（GitHubなど）にCommitした人数
– および 2015年からの増加率
•開発量
– 2016年に開発リポジトリ（GitHubなど）にCommitした数
– および 2015年からの増加率
•活動日
– 全開発期間におけるCommitされた日の割合
•開発者向けメーリングリストの流量
– 2016年に開発者向けメーリングリストに投稿されたメールの量
•イシュー解決率
– 全イシューにおけるクローズされたイシューの割合
•今回の調査ではプライオリティ（など）による絞込みは行っていない

２-５開発者数（Committer）
14
Ceph
TensorFlow
Apache Spark
Elasticsearch

２-６月平均の開発者数ランキング
15
TensorFlow
（105）
1位
10位
３位
CNTK
（33）
Elasticsearch
（53）
2位 Apache Spark
（101）
4位 MongoDB
（49）
7位 Apache Hive
（35）
6位 Apache Kafka
（38）
7位 Apache Cassandra
（35）
7位 Apache Mesos
（35）
Apache Spark
（121）
1位
2位
３位
Elasticsearch
（52）
MongoDB
（43）
4位 Apache Hadoop
（40）
5位 GlusterFS
（40）
6位 Apache Mesos
（38）
（33）
7位 VoltDB
（33）
5位 Apache Hadoop
（41）
10位 VoltDB
（33）
9位 Apache Hive
（32）
10位 Theano
（27）
TensorFlow
（5）
26位
13位 Apache Kafka
（22）
17位 CNTK
（15）
12位 GlusterFS
（32）
14位 Theano
（27）
2016年 2015年

２-７開発者数［横軸］と成長率［縦軸］
16

２-８開発量（Commit）
17
Ceph
MongoDB
TensorFlow
CNTK
Elasticsearch

２-９月平均の開発量ランキング
18
TensorFlow
（1,002）
1位
2位
３位
CNTK
（635）
Elasticsearch
（513）
4位 Apache Spark
（362）
5位 Chainer
（336）
6位 MongoDB
（330）
7位 Theano
（276）
7位 Apache Mesos
（276）
9位 VoltDB
（269）
（228）
Elasticsearch
（605）
1位
2位
３位
Apache Spark
（419）
Theano
（371）
4位 VoltDB
（361）
5位 MongoDB
（352）
6位 Apache Cassndra
（326）
8位 Apache Hadoop
（253）
7位 Apache Mesos
（280）
9位 Chainer
（247）
10位 CNTK
（243）
TensorFlow
（44）
22位12位 Apache Hadoop
（208）
2016年 2015年

２-１０開発者数［横軸］と開発量［縦軸］
19

２-１１活動日
20
週休1日
週休2日
週休3日

２-１２開発者向けメーリングリストの流量推移
21
Apache Hadoop
Apache Hive
Apache
Storm
Apache
Kafka
（※）メールの流量のみ。
（※）近年はGoogle Groupsなどメール以外の媒体で
議論するケースも多い為、メール流量＝議論の活発度にはならない。

２-１３イシュー解決率
22
（※）今回の調査ではイシューの種類や
プライオリティに対する絞込みは未実施。
（※）本結果は全イシューに対するクローズの割合。

２-１４ Top1［横軸］とTop5［縦軸］までの開発比率
23

２-１５「開発の活性度」ランキング
24
1位
Elasticsearch2位
Apache Spark3位
※各ソフトウェアの各調査項目に対する偏差値を比較したランキング
MongoDB4位 CNTK5位
TensorFlow

３．NoSQLとは？
25

© Hitachi Solutions, Ltd. 2017. All rights reserved. 26
３-１ NoSQLとは？(wikipediaより)
NoSQL（一般に "Not only SQL" と解釈される）とは、
関係データベース管理システム (RDBMS) 以外のデータベース
管理システムを指すおおまかな分類語である。
関係データベースを杓子定規に適用してきた長い歴史を打破し、
それ以外の構造のデータベースの利用・発展を促進させようとす
る運動の標語としての意味合いを持つ。
SQLとは、RDB (Relational Database)のデータを操作するための言語です。
(SQLは公式には何かの略ではない言語名ですが、Structured Query Languageと紹介
されることもあります)

リレーショナルデータベース(Relational DataBase)
データモデル：表形式トランザクション問合せ言語：SQL
日付数値文字
更新
更新
id name
A abc
B xyz
３-２前提知識：RDBとは？
SELECT score
FROM T1, T2
WHERE name='abc' AND
T1.id=T2.id
人間にわかりやすい形、
Excelが流行る理由
10
英語っぽい問い合わせ言語
複雑な条件を付けられる
人間へのわかりやすさ・データ整合性を重視したデータベース
id score
A 10
B 5
障害時の復旧
（耐障害性）
複数の人が同時更新しても
整合性担保（同時実行制御）

Variety (多様性) Volume (量) Velocity (速さ)
RDBが苦手とするビッグデータの３つの【V】
ログ
SNS
画像
センサー GB
PB
種類が多い、あるいは
頻繁に変更が入るものを
俯瞰してみたい
データ量が大きくなれば
整合性などの影響も大き
くなっていく
整合性のために排他処理、
SQLの解析時間も、
表形式からの型変換
Variety
「とりあえず格納」は事前定義する表形式とは相性が悪い
Volume/Velocity
スケールアップ(高スペックサーバ) ⇒限界あり
スケールアウト(水平分散サーバ) ⇒高価格になりやすい
３-３一般に言われるRDBの課題

リレーショナルデータベース(Relational Database)で大変な所を削ることで
高速化・開発容易化
データモデル：表形式トランザクション問合せ言語：SQL
日付数値文字
更新
更新
id name
A abc
B xyz
３-４ RDBへのアンチテーゼとしてのNoSQL
SELECT score
FROM T1, T2
WHERE name='abc' AND
T1.id=T2.id
10
id score
A 10
B 5
2列だけにしよう
行毎に列数が違ってもいいだろう
一度に一人しか触れない形にしよう
事前に列とか決めなくても…
独自APIにしよう
XML on HTTP
（実はRDBより前からやってることを汎用化した物）
インメモリ（壊れたら再起動）

３-５もう一度 NoSQLとは？
30
 「Not only SQL」の略称
SQL≒RDB以外のデータ格納庫を指す総称としての言葉
 「No! SQL」ではなく、適材適所で使い分けが必要
 「用途特化型」：はまれば強いが、罠も多い
（F1マシンで一般車道走ったら事故起こします）
 特に、RDBでは当たり前の格納データの整合性保証や、
トランザクションやジョイン、その他各種の便利な機能が、
NoSQLでは基本的にサポートされないことに注意

３-６ NoSQLのデータモデルと代表製品・サービス
31
種別名 OSS 商用版・商用製品クラウドサービス
キーバリュー型
（分散KVS型）
・Redis
・Memcached
・Riak
・Oracle Coherence
・Oracle NoSQL Database
Enterprise Edition
・Pivotal GemFire
・Amazon ElastiCache
(Redis または Memcached)
・Microsoft Azure Redis Cache
ワイドカラム型
（列指向型）
・Cassandra
・Hbase
・DataStax Enterprise
(Cassandraの商用版)
・Google Cloud Bigtable
ドキュメント型・MongoDB
・Couchbase
・CouchDB
・RavenDB
・MongoDB Enterprise
Edition
・MarkLogic
・Amazon DynamoDB
・Microsoft Azure DocumentDB
・IBM Cloudant
グラフ型・Neo4j
・OrientDB
・Neo4j Enterprise
Edition
・OrientDB Enterprise
OSS・商用製品・クラウドサービスと豊富に存在します。目的を明確化
した上で、RDB含めて適切な製品・サービスを選択する必要がある。

キーバリュー型データモデル
３-７キーバリュー型
32
 一意なキーと、キーに1対1で対応するバリューのペアで、
データを保持するシンプルな構造。（マップ構造）
 複雑な検索等は苦手だが、単純な処理は高速にこなす。
 バリューの自由度が高く、ほとんど型に縛られないので、
動画や音声、画像などのメディアデータも扱いやすい。
Key１
Key5
Key3
Key4
Key2
Value１
Value5
Value3
Value4
Value2
Value6Key6
バリューキー
キー（ファイル名）バリュー（実データ）
mail_01.msg
movie_02.mp4
music_03.mp3
photo_04.jpg

３-７-１ Redis（キーバリュー型）
33
基本情報
 開発元：Salvatore Sanfilippo氏（2009年）→VMware社(2010
年)→Redis Lab(2011年)
 開発言語：ANSI C
 ライセンス：3条項BSDライセンス
 サポートOS：Linux・Mac OS Xなど（Windowsは未サポート）
 公式サイト：https://redis.io/
主な特徴
 スケーラビリティ：シャーディングにより容易にスケールアウト可能
 低レイテンシ：シンプルなデータモデル＋メモリ空間にデータ保持
 高可用性：レプリケーション機能での複製とメモリデータの永続化
 バリューの多様性：文字列だけでなくList/Set/Hash等も使用可能
主な事例
 （国内）DeNA,サイバーエージェント、ニコニコ動画、GMO、LINE 他
 （海外） github、flicker、twitter、intasgram、stackoverflow 他

３-８ワイドカラム型
34
 キーバリュー型のバリュー部分が、更に任意の数の
キーバリューの集合（列名と値）になったような構造。
 RDBと似た構造だが、行ごとに列の名前や数は自由。
 列方向の集約が高速で集計処理などが得意。
 時系列に発生するセンサデータの格納に適しており、
IoT(Internet of Things)と相性が良い。
ワイドカラム型データモデル
キー
Key2
Key1
列A
値2
値1
列B
値4
列C
値5
列A
Key3
値3
列A
値6
列D
バリュー
キー
温度計/1月1日
0時0分
5℃
0時1分
5℃
0時2分
5℃
2℃ 3℃ 2℃
湿度計/1月1日
0時
30%
1時
31%
2時
32%
0時
34%
… 23時59分
バリュー
…
…
23時
28%
湿度計/1月2日
0時
28%
1時
29%
2時
28%
…
…
23時
33%
湿度計/1月3日
温度計/1月2日
0時0分
0℃
0時1分
0℃
0時2分
-1℃ … 2℃
… 23時59分
温度計/1月3日
0時0分 0時1分 0時2分
… 0℃
1月3日0時2分の状態
温度計：1分毎
湿度計：1時間毎

３-８-１ Cassandra（ワイドカラム型）
35
基本情報
 開発元：Facebook社（2008年）
→Apache Software Foundation Incubator Project(2009年3月)
→Apache Software Foundation Top Level Project(2010年2月)
 開発言語：Java
 ライセンス：Apache License 2
 サポートOS：Windows・Linux・Mac OS Xなど
 公式サイト：http://cassandra.apache.org/
主な特徴
 スケーラビリティ：クラスタ構成により容易にスケールアウト可能
 SQLライクなAPI：RDBに慣れたアプリ開発者の勉強コスト低減
 マルチデータセンタ：ディザスタリカバリや収集・分析の分離に活用
 整合性の自由度：整合性と可用性・性能を天秤にかけて調整可能
主な事例
 Facebook・Apple iCloud・Yahoo! JAPAN・ぐるなびなど

ドキュメント型データモデル
３-９ドキュメント型
36
 キーバリュー型のバリュー部分が、JSONやXMLなどの
半構造化データ（ドキュメント）になったような構造。
 キーバリュー型よりも、データの検索性に優れている。
 スキーマレスなので、複雑なデータを柔軟に運用する
ことができ、一般的なWebシステムとは相性が良い。
ID1
ID5
ID3
ID4
ID2
Key1 Value1
Key2 Value2
Key1 Value1
Key3 Value3
{ キーバリュー
ID ： 12345 ,
Name ： ‘OSS 花子’,
Position ： {
Building ： ’(本社)’,
Floor ： ’3F’
} ,
Member ID ： [ 45534 , 53425 ,123745 ,51251 ] ,
Job ： [
{ Type : ‘Development’, Year : 5 } ,
{ Type : ‘Maintenance’, Year : 3 } ,
{ Type : ‘Support’, Year : 1 }
]
}
＜JSONオブジェクト例＞JSON（JavaScript Object Notation）：カンマ区切
りのCSVやタグで囲むXMLと同様、取扱いが容
易なため広く使われている

３-９-１ MongoDB（ドキュメント型）
37
基本情報
 開発元：米国10gen社（現MongoDB社）（2009年）
 開発言語：C++
 ライセンス：GNU AGPL v3.0
 公式サイト：https://www.mongodb.com/
主な特徴
 スケーラビリティ：シャーディングにより容易にスケールアウト可能
 スキーマレス：JSON形式で柔軟にデータを格納
 検索条件：ソート、limit/skipによる制限、複雑な集計処理の実行等
 検索性能：インデックスの設定や強制利用による高速検索
主な事例
 社外：Ameba・MetLife・McAfee・gumiなど

３-１０グラフ型
38
 グラフ理論に基づき、データ同士を相互に結びつけた構造。
ノード・リレーション・プロパティの３要素で表現される。
 人・物・場所などの相関関係を表現する際に利用。
 NoSQLだが他の種別とは性質が大きく異なる。RDBが苦手な
３つのVの中のVariety（多様性）における、表形式での表現が
難しいデータに特化しており、Volume（大量）はむしろ苦手。
グラフ型データモデル
ノード1 ノード2
ノード3
プロパティ1 プロパティ2
プロパティ3
リレーション1 リレーション3
名古屋新青森
東京
・名古屋空港
・名古屋駅
手段：飛行機+α
料金：35590円
所要時間：230分
・青森空港
・新青森駅
・羽田空港
・東京駅
手段：新幹線
料金：10360円
手段：新幹線
料金：17150円
リレーション2

３-１０-１ Neo4j（グラフ型）
39
基本情報
 開発元：Neo Technology社（2007年）
 開発言語：Java
 ライセンス： GNU AGPL v3.0 及び GNU AGPL v3.0
主な特徴
 グラフ構造Native対応：グラフ構造をそのまま格納
 グラフクエリー：グラフ構造向けの専用問い合わせ言語
 トランザクションサポート：シングルノードをベースにトランザクション
サポート
主な事例
 社外：ドイツのトラック輸送管理システム

３-１０－１ Neo4j事例：トラック輸送管理システム
40
●システム概要
トラック配送のルーティング管理。荷物配送の最適な経路を素早く出したい
●課題（RDBでは難しいこと）
大量の配送先をたどっていくjoin処理が大規模では重い
テラバイトクラスのデータに対するjoinがOracleでは困難だった
●採用理由
グラフ構造の検索が非常にシンプルに実装できる。

４．選定基準
41

４-１ RDBとNoSQLの使い分け（一般情報系システムの例）
42
RDBで対応可能な
ユースケースか？
データモデルは
グラフ型が適切か？
厳密な一貫性は
必要か？
運用・構築に
不安はあるか？
グラフ型NoSQL
各種RDB
キーバリュー型・ワイドカラム型・ドキュメント型から
もっとも適切なデータモデルを検討・選択する
OSS版NoSQL
クラウドサービスや
商用版NoSQL
NO
NO
NO
YES
NO
YES
YES
YES
厳密な一貫性を
保証するNoSQL

４-２目的ごとの方針例
43
 既存（RDBを使った）システムの性能改善
 一般にはそのままRDBを使った方が良いです。性能ボトルネック
見極めを。
 一部データを参照用キャッシュとしてNoSQLに一時的に入れるな
ど、限定的な使い方は有効です
 ライセンス費は削減できるかもしれませんが開発費も考えましょう。
無料のRDBもあります（サポートの不安はNoSQLも一緒）
 既存（ファイル等を使った）システムの信頼性確保
 ファイルアクセス部分を置き換えることは比較的容易で、高速化・
高信頼化ができるかもしれません
 新規システムを構築する場合
 PoC/プロトタイプの素早い提供には有効
 大規模化した時のこと、整合性のことを考えずにPoCは危険

５．最新動向
44

５-１ RDBの逆襲
45
 Key-Value API, json型サポート、カラムストア
 PostgreSQL：
9.2でサポートされたJSON型
9.4からJSONB型がサポート
9.3からは、Foreign Data Wrapper実装
 MySQL：
5.7.8からJSON型がサポート
memcachedのAPIでMySQLのデータにアクセス可能

mysqld
５-２例：MySQLのNoSQL API
46
 MySQLのデータにKVSであるmemcachedのAPIでアクセス
 同じデータをSQLでもNoSQLでもアクセスできる
Application
MySQL Server
Memcached
Plugin
InnoDB Storage Engine
SQL(MySQL Client) NoSQL(Memcached Protocol)
KVS派：RDBMSはSQLを解析しなければならないから遅い
 社外事例：NoSQLとしてMySQLを使うDeNAが、memcachedよりも
高速な75万クエリ／秒を実現
 http://www.publickey1.jp/blog/10/nosqlmysqldenamemcached75.html

５-３例：Oracleのインメモリカラムストア
47
カラム派：RDBは集約計算が遅い
 Oracle Databaseはメモリ上にカラムストアを作成、テーブルと同期
 カラムストアとRDBMSの良い所取り
ディスク上は表形式で保持
メモリ上
従来の行形式のキャッシュ列形式
従来処理集約・集計等

５-４例：各種RDBのJSON型サポート
48
 Oracle/MySQL/PostgreSQLはJSON型をサポート
 ある列の中にドキュメント構造を格納。この中は自由な形式
ドキュメントDB派：RDBMSは列の変更に弱い
{ キーバリュー
ID ： 12345 ,
Name ： ‘OSS 花子’,
Position ： {
Building ： ’(本社)’,
Floor ： ’3F’
} ,
Member ID ： [ 45534 , 53425 ,123745 ,51251 ] ,
Job ： [
{ Type : ‘Development’, Year : 5 } ,
{ Type : ‘Maintenance’, Year : 3 } ,
{ Type : ‘Support’, Year : 1 }
]
}
＜JSONオブジェクト例＞
列をJSON型で定義

株式会社日立ソリューションズ
技術革新本部研究開発部
IoT時代のデータストア
2017/06/16
吉田行男
END
49
--躍進するNoSQL、拡張するRDB

・本資料に記載されている会社名、商品名、ロゴは各社の商標、または登録商標です。

[db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシアムデータベース部会吉田行男

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシアムデータベース部会吉田行男

Similaire à [db tech showcase OSS 2017] A14: IoT時代のデータストア--躍進するNoSQL、拡張するRDB by OSSコンソーシアムデータベース部会吉田行男 (20)

Plus de Insight Technology, Inc.

Plus de Insight Technology, Inc. (20)

Dernier

Dernier (8)