HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか

®
© 2014 MapR Technologies 1
®
© 2014 MapR Technologies
Ted Dunning
2015 年 6 月 10 日

®
コンタクト先情報
Ted Dunning
MapR Technologies チーフアプリケーションアーキテクト
Apache Drill、Zookeeper、Mahout のコミッタ & PMC
Apache Foundation のインキュベータ VP
Email tdunning@apache.org tdunning@maprtech.com
Twitter @ted_dunning
今日のハッシュタグ: #BDE2015

®
アジェンダ
•  Good とは何を意味するか?
•  緩い型付けとは何を意味するか?
•  実現できることの例
•  テーブル数が 1/10〜1/20 になる現実のデータベース
•  新たな展望
•  質問

®
Good とは何を意味するか? (DB にとって)
•  表現力が豊か (Expressive)
–  必要な概念を表現できる
•  効率的 (Efficient)
–  十分に安いハードウェアで十分に高速

®
Good とは何を意味するか? (DB にとって)
•  表現力が豊か (Expressive)
–  必要な概念を表現できる
•  効率的 (Efficient)
–  十分に安いハードウェアで十分に高速
•  内観できる (Introspectable)
–  データとスキーマを調べて容易に把握することができる

®
新たな視点
•  次の場合に、内観 (Introspection) はより優れているといえる
–  モデルを記述するのに最小限のデータエントリが使われる
–  名前が多すぎることによる混乱がない
–  参照のスコーピングが、より単純な問題に焦点を絞り込むことの助けになる
–  多対1の関係が埋め込める
•  内観はリレーショナルモデルの目的ではなかった
•  したがって、内観は結果としても実現されなかった

®
とてつもなく古い
•  リレーショナル理論は古い (1970年)
–  データ構造より前
–  主流の再帰プロシージャより前
–  レキシカルスコープより前
–  論理プログラミングより前
–  現実的な関数プログラミングより前 (Church, McCarthy, Iverson, Backus
はおいといて)
•  内観を向上させるためには何か新しい更新が必要

®
リレーショナルと HBase スタイルの noSQL の比較
リレーショナル
•  行はフィールドを含む
•  フィールドは基本型を含む
•  構造は固定で不変
•  構造は事前に定義される
•  参照整合性（オプション）
•  複数行にまたがる表現
HBase / MapR DB
•  フィールドはバイト列
•  構造は柔軟
•  事前に定義された構造なし
•  単一キー
•  カラムファミリー
•  タイムスタンプ
•  バージョン

®
リレーショナルと構造化が施された HBase の比較
リレーショナル
•  構造は固定で不変
•  構造は事前に定義される
•  参照整合性（オプション）
•  複数行にまたがる表現
HBase + 構造化
–  またはオブジェクトやリスト
•  構造は柔軟で不規則
•  事前に定義された構造なし
•  単一キー

®
データベースの「亀」モデル
•  フィールド値として複合オブジェクトを許容する
–  JSON スタイルのリストおよびオブジェクト
•  ジョインによるオブジェクトへの参照を許容する
–  リスト内で局所化された参照を含む
•  複数オブジェクトのリストと複数リストのオブジェクトはテーブルと同一
構造、したがって …
•  テーブル内の複合データも、
•  複合データ内のテーブルも、
•  さらにはテーブルを含む複合データを含むテーブルも存在

®
ただし書き
•  これは従来の BLOB とは違います
•  そして配列の Lateral View のジョインとも違います
•  理由は表現法を説明していくにつれて明らかになります

®
noSQL 表現法のカタログ

®
オブジェクトとしてのテーブル、テーブルとしてのオブジェクト
c1 c2 c3
行志向の形式
c1 c2 c3
列志向の形式
[ { c1:v1, c2:v2, c3:v3 },
{ c1:v1, c2:v2, c3:v3 },
{ c1:v1, c2:v2, c3:v3 } ]
複数オブジェクトのリスト
{ c1:[v1, v2, v3],
c2:[v1, v2, v3],
c3:[v1, v2, v3] }
複数リストを含むオブジェクト

®
c1 c2 c3
c1 c2 c3
マイクロカラムナフォーマット
カラム型で格納されている
テーブル全体が First-
class の値になり得る
これは1対多の関係を埋
め込むのに非常に有効

®
メモ
•  もし埋め込んだテーブルが First-class であるなら、スキーマはデータ
になる
•  埋め込まれた際にもしスキーマがデータから導かれる場合、テーブル
を最上位に持っていく構成は不可能
•  したがって、First-class オブジェクトの埋め込みはスキーマ情報の遅
延検出が行われることを意味する

®
1つ目の例: 
時系列データ

®
データとしてのカラム名
•  カラム名が事前定義されていない場合、カラム名は情報を伝えること
が可能
•  例
–  時系列のウインドウ内における時刻オフセット
–  Web クローラのトップレベルドメイン
–  顧客の購買プロファイルのベンダー ID
•  事前定義されたスキーマではこの表現法は不可能

®
時系列のリレーショナルモデル
15:51:03
15:52:07
15:52:11
101
101
101
Sample time
Time series ID
Row key
value
Data values
1.16
0.04
0.08
時系列 ID
サンプリング時刻
行キー
データの値

®
テーブル設計: ポイントごと
時系列 ID
タイムウインドウ
開始時刻
カラム名はサンプリング時刻のタイム
ウインドウ内のオフセットになる
行キー
データの値

®
テーブル設計: ポイントごと + 副テーブルのハイブリッド
ウインドウが閉じた後、行内のデータは異なるカラムファミリ内にカラム
志向の表形式の値として再記録される
時系列 ID
タイムウインドウ
開始時刻
行キー
データの値
カラム名はサンプリング時刻のタイム
ウインドウ内のオフセットになる
圧縮された行を
格納する1つのカラム

®
圧縮の結果
サンプルは
64 ビットの時刻,
16 ビットのサンプル値
サンプリングレートは 10kHz
本来のタイムスタンプを維持す
ることが重要であり、それはサ
ンプル時刻のジッタ次第
タイムスタンプを保持するため
の容量オーバーヘッドはどれく
らい?

®
2つ目の例: 
音楽メタデータ

®
NoSQL 上の MusicBrainz
•  アーティスト、アルバム、曲名、ラベルが主要なオブジェクト
•  現実の把握:
–  制作(作曲)、レコーディング、リリース、リリースグループを追加
•  アーティストだけで 7 テーブル
•  場所が 12、ラベルが 7、リリース/グループが 17、制作が 8
–  (でもレコーディングは 4 だけ!)
–  合計 12 + 7 + 17 + 8 + 4 = 48 テーブル
•  しかし待て、まだある!
–  注釈テーブルが 10、編集テーブルが 10、タグテーブルが 19、レーティングテーブ
ルが 5、リンクテーブルが 86、カバーアートテーブルが 5、CD タイミング情報のテー
ブルが 3 (計 138)
–  さらに 50 以上のテーブルはドキュメント化されていない

®

®
あと180テーブ
ルが未表示

®
7種類のものを表現するための 
236テーブル

®
もっとうまくできるでしょうか?

®
artist
id
gid
name
sort_name
begin_date
end_date
ended
type
gender
area
being_area
end_area
comment
list<ipi>
list<isni>
list<alias>
list<release_id>
list<recording_id>
artist
id
gid
name
sort_name
begin_date
end_date
ended
type
gender
area
being_area
end_area
comment
list<ipi>
list<isni>
list<alias>

®
artist
id
gid
name
sort_name
begin_date
end_date
ended
type
gender
area
being_area
end_area
comment
list<ipi>
list<isni>
list<alias>
list<release_id>
list<recording_id>
Primitive values
One to many relations
Equivalent to indexes
プリミティブな値
1対多のリレーション
インデックスと同等

®
artist
id
gid
name
sort_name
begin_date
end_date
ended
type
gender
area
begin_area
end_area
comment
list<ipi>
list<isni>
list<alias>
list<release_id>
list<recording_id>
{ name, begin_date,
end_date }

®

®
{id, recording_id,
name, list<credit>
length}
recording
id
gid
list<credit>
name
list<track_ref>
release
id
gid
release_group_id
list<credit>
name
barcode
status
packaging
language
script
list<medium>
{id, format,
name,
list<track>}
release_group
id
gid
name
list<credit>
type
list<release_id>

®
27テーブルが4に減った

®
27テーブルが4に減った 
今のところは

®
さらなる削減
•  86 のリンクテーブルはすべてアーティスト、リリース、その他の項目
のプロパティになる
•  44 のタグ、レーティング、注釈テーブルはすべてリストプロパティにな
る
•  5 つのカバーアートテーブルはすべてファイル参照のリストになる
•  現在のスコア: 162 テーブルが 4 に
•  ご理解いただけたでしょうか

®
これは Good か?
•  表現性
–  JSON データモデルは少なくとも元々のリレーショナルモデルと同等の表現
力
•  ネストデータを記述するのが多くの場合、より簡単
•  難しくなることはない
•  効率性
–  埋め込みによりデータサイズが増える可能性がある。ただし局所性は向上
–  セッションにまとめることでデータサイズを大幅に削減できる
–  逆参照の埋め込みは一般的なインデックスよりも効率的
–  埋め込みカラム型データは時系列データで 1000 倍の速度向上
•  内観（ご判断ください）

®
でもどうやってクエリを実行できる?
•  SQL は使えない
–  SQL は厳密な型付け
–  SQL は元々のリレーショナルモデルに強く結びついている
–  SQL 生成ツールはリレーショナルモデルを要求する
•  SQL を使う必要がある
–  膨大な数のツールや開発者が SQL の記述方法を理解している
–  SQL はデータベースの世界の共通言語 (lingua franca)

®
不可能に挑戦
•  Apache Drill を利用
•  Drill は SQL 準拠
–  標準のシンタックスとセマンティクスを使用
•  Drill は SQL を拡張
–  オブジェクトおよびリストを First Class として扱う
–  構造の分解、フラット化を完全サポート
–  リレーショナルモデルを最大限複合データに適用可能

®
Drill はスケーラブルで拡張された SQL を提供

®
クエリの例
•  Elvis を見つける
select distinct id, name, alias from (
select id, flatten(alias.name) alias from artist
where alias like 'Elvis%Presley'
)

®
クエリの例
•  Elvis がクレジットされているアルバムを見つける
select distinct album_id, name
from
(
select id album_id, name, flatten(credit)
from release
) albums
join
(
select distinct artist_id from (
select id artist_id, flatten(alias) from artist
where name like 'Elvis%Presley’
)
) artists
using artist_id

®
まとめ
•  リレーショナルモデルの拡張により、極めてシンプルになる
–  実際の例では、テーブル数を 1/20 以下に削減できた
•  シンプルにすることで、内観の改善につながる
–  これは good
•  Apache Drill は拡張されたリレーションの問題に対して非常に高速な
処理を行うことが可能
•  今すぐに試すことができる

®

®
Ted Dunning と Ellen Friedman による小冊子
•  オライリーより 2014 年および 2015 年に出版
•  Amazon およびオライリーで販売中
•  MapR の厚意により無料 e-book が入手可
http://bit.ly/ebook-real-
world-hadoop
http://bit.ly/mapr-tsdb-
ebook
http://bit.ly/ebook-
anomaly
http://bit.ly/
recommendation-
ebook

®
Real World Hadoop
Ted Dunning、Ellen Friedman 著、2015 年 3 月出版（オライリーより）
本日サイン会にて無料配布

®
ありがとうございました!

®
Q&A
@mapr maprtech
tdunning@mapr.tech.com
Engage with us!
MapR
maprtech
mapr-technologies

HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか

More Related Content

What's hot

Viewers also liked

Similar to HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか

More from MapR Technologies Japan

HBase と Drill - 緩い型付けの SQL がいかに NoSQL に適しているか