View
941
Download
3
Category
Preview:
Citation preview
®© 2014 MapR Technologies 2
コンタクト先情報 Ted Dunning
MapR Technologies チーフアプリケーションアーキテクト Apache Drill、Zookeeper、Mahout のコミッタ & PMC
Apache Foundation のインキュベータ VP
Email tdunning@apache.org tdunning@maprtech.com Twitter @ted_dunning
今日のハッシュタグ: #BDE2015
®© 2014 MapR Technologies 3
アジェンダ • Good とは何を意味するか? • 緩い型付けとは何を意味するか? • 実現できることの例 • テーブル数が 1/10〜1/20 になる現実のデータベース • 新たな展望 • 質問
®© 2014 MapR Technologies 4
Good とは何を意味するか? (DB にとって) • 表現力が豊か (Expressive)
– 必要な概念を表現できる
• 効率的 (Efficient) – 十分に安いハードウェアで十分に高速
®© 2014 MapR Technologies 5
Good とは何を意味するか? (DB にとって) • 表現力が豊か (Expressive)
– 必要な概念を表現できる
• 効率的 (Efficient) – 十分に安いハードウェアで十分に高速
• 内観できる (Introspectable) – データとスキーマを調べて容易に把握することができる
®© 2014 MapR Technologies 6
新たな視点 • 次の場合に、内観 (Introspection) はより優れているといえる
– モデルを記述するのに最小限のデータエントリが使われる – 名前が多すぎることによる混乱がない – 参照のスコーピングが、より単純な問題に焦点を絞り込むことの助けになる – 多対1の関係が埋め込める
• 内観はリレーショナルモデルの目的ではなかった • したがって、内観は結果としても実現されなかった
®© 2014 MapR Technologies 7
とてつもなく古い • リレーショナル理論は 古い (1970年)
– データ構造より前 – 主流の再帰プロシージャより前 – レキシカルスコープより前 – 論理プログラミングより前 – 現実的な関数プログラミングより前 (Church, McCarthy, Iverson, Backus
はおいといて)
• 内観を向上させるためには何か新しい更新が必要
®© 2014 MapR Technologies 8
リレーショナルと HBase スタイルの noSQL の比較 リレーショナル
• 行はフィールドを含む • フィールドは基本型を含む • 構造は固定で不変 • 構造は事前に定義される • 参照整合性(オプション)
• 複数行にまたがる表現
HBase / MapR DB • 行はフィールドを含む • フィールドはバイト列 • 構造は柔軟 • 事前に定義された構造なし • 単一キー • カラムファミリー • タイムスタンプ • バージョン
®© 2014 MapR Technologies 9
リレーショナルと構造化が施された HBase の比較 リレーショナル
• 行はフィールドを含む • フィールドは基本型を含む • 構造は固定で不変 • 構造は事前に定義される • 参照整合性(オプション)
• 複数行にまたがる表現
HBase + 構造化 • 行はフィールドを含む • フィールドは基本型を含む
– またはオブジェクトやリスト • 構造は柔軟で不規則 • 事前に定義された構造なし • 単一キー
®© 2014 MapR Technologies 10
データベースの「亀」モデル • フィールド値として複合オブジェクトを許容する
– JSON スタイルのリストおよびオブジェクト
• ジョインによるオブジェクトへの参照を許容する – リスト内で局所化された参照を含む
• 複数オブジェクトのリストと複数リストのオブジェクトはテーブルと同一構造、したがって …
• テーブル内の複合データも、 • 複合データ内のテーブルも、 • さらにはテーブルを含む複合データを含むテーブルも存在
®© 2014 MapR Technologies 11
ただし書き • これは従来の BLOB とは違います • そして配列の Lateral View のジョイン とも違います
• 理由は表現法を説明していくにつれて明らかになります
®© 2014 MapR Technologies 13
オブジェクトとしてのテーブル、テーブルとしてのオブジェクト
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] }
複数リストを含むオブジェクト
®© 2014 MapR Technologies 14
c1 c2 c3
c1 c2 c3
マイクロカラムナフォーマット
カラム型で格納されているテーブル全体が First-class の値になり得る
これは1対多の関係を埋め込むのに非常に有効
®© 2014 MapR Technologies 15
メモ • もし埋め込んだテーブルが First-class であるなら、スキーマはデータ
になる
• 埋め込まれた際にもしスキーマがデータから導かれる場合、テーブルを最上位に持っていく構成は不可能
• したがって、First-class オブジェクトの埋め込みはスキーマ情報の遅延検出が行われることを意味する
®© 2014 MapR Technologies 17
データとしてのカラム名 • カラム名が事前定義されていない場合、カラム名は情報を伝えること
が可能
• 例 – 時系列のウインドウ内における時刻オフセット – Web クローラのトップレベルドメイン – 顧客の購買プロファイルのベンダー ID
• 事前定義されたスキーマではこの表現法は不可能
®© 2014 MapR Technologies 18
時系列のリレーショナルモデル
15:51:0315:52:0715:52:11
101101101
Sample time
Time series ID
Row key
value
Data values
1.160.040.08
時系列 ID
サンプリング時刻
行キー データの値
®© 2014 MapR Technologies 19
テーブル設計: ポイントごと
時系列 ID
タイムウインドウ 開始時刻
カラム名はサンプリング時刻のタイムウインドウ内のオフセットになる
行キー データの値
®© 2014 MapR Technologies 20
テーブル設計: ポイントごと + 副テーブルのハイブリッド
ウインドウが閉じた後、行内のデータは異なるカラムファミリ内にカラム志向の表形式の値として再記録される
時系列 ID
タイムウインドウ 開始時刻
行キー データの値
カラム名はサンプリング時刻のタイムウインドウ内のオフセットになる
圧縮された行を 格納する1つのカラム
®© 2014 MapR Technologies 21
圧縮の結果
サンプルは 64 ビットの時刻, 16 ビットのサンプル値
サンプリングレートは 10kHz 本来のタイムスタンプを維持することが重要であり、それはサンプル時刻のジッタ次第 タイムスタンプを保持するための容量オーバーヘッドはどれくらい?
®© 2014 MapR Technologies 23
NoSQL 上の MusicBrainz • アーティスト、アルバム、曲名、ラベルが主要なオブジェクト • 現実の把握:
– 制作(作曲)、レコーディング、リリース、リリースグループを追加 • アーティストだけで 7 テーブル • 場所が 12、ラベルが 7、リリース/グループが 17、制作が 8
– (でもレコーディングは 4 だけ!) – 合計 12 + 7 + 17 + 8 + 4 = 48 テーブル
• しかし待て、まだある! – 注釈テーブルが 10、編集テーブルが 10、タグテーブルが 19、レーティングテーブ
ルが 5、リンクテーブルが 86、カバーアートテーブルが 5、CD タイミング情報のテーブルが 3 (計 138)
– さらに 50 以上のテーブルはドキュメント化されていない
®© 2014 MapR Technologies 28
artist
idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>
artist
idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>
®© 2014 MapR Technologies 29
artist
idgidnamesort_namebegin_dateend_dateendedtypegenderareabeing_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>
Primitive values
One to many relations
Equivalent to indexes
プリミティブな値
1対多のリレーション
インデックスと同等
®© 2014 MapR Technologies 30
artist
idgidnamesort_namebegin_dateend_dateendedtypegenderareabegin_areaend_areacommentlist<ipi>list<isni>list<alias>list<release_id>list<recording_id>
{ name, begin_date, end_date }
®© 2014 MapR Technologies 32
{id, recording_id, name, list<credit>length}
recordingidgidlist<credit>namelist<track_ref>
releaseidgidrelease_group_idlist<credit>namebarcodestatuspackaginglanguagescriptlist<medium>
{id, format, name, list<track>}
release_groupidgidnamelist<credit>typelist<release_id>
®© 2014 MapR Technologies 35
さらなる削減 • 86 のリンクテーブルはすべてアーティスト、リリース、その他の項目
のプロパティになる • 44 のタグ、レーティング、注釈テーブルはすべてリストプロパティにな
る • 5 つのカバーアートテーブルはすべてファイル参照のリストになる
• 現在のスコア: 162 テーブルが 4 に
• ご理解いただけたでしょうか
®© 2014 MapR Technologies 36
これは Good か? • 表現性
– JSON データモデルは少なくとも元々のリレーショナルモデルと同等の表現力
• ネストデータを記述するのが多くの場合、より簡単 • 難しくなることはない
• 効率性 – 埋め込みによりデータサイズが増える可能性がある。ただし局所性は向上 – セッションにまとめることでデータサイズを大幅に削減できる – 逆参照の埋め込みは一般的なインデックスよりも効率的 – 埋め込みカラム型データは時系列データで 1000 倍の速度向上
• 内観 (ご判断ください)
®© 2014 MapR Technologies 37
でもどうやってクエリを実行できる? • SQL は使えない
– SQL は厳密な型付け – SQL は元々のリレーショナルモデルに強く結びついている – SQL 生成ツールはリレーショナルモデルを要求する
• SQL を使う必要がある – 膨大な数のツールや開発者が SQL の記述方法を理解している – SQL はデータベースの世界の共通言語 (lingua franca)
®© 2014 MapR Technologies 38
不可能に挑戦 • Apache Drill を利用
• Drill は SQL 準拠 – 標準のシンタックスとセマンティクスを使用
• Drill は SQL を拡張 – オブジェクトおよびリストを First Class として扱う – 構造の分解、フラット化を完全サポート – リレーショナルモデルを最大限複合データに適用可能
®© 2014 MapR Technologies 40
クエリの例 • Elvis を見つける
select distinct id, name, alias from ( select id, flatten(alias.name) alias from artist where alias like 'Elvis%Presley' )
®© 2014 MapR Technologies 41
クエリの例 • Elvis がクレジットされているアルバムを見つける
select distinct album_id, namefrom( select id album_id, name, flatten(credit) from release) albumsjoin( select distinct artist_id from ( select id artist_id, flatten(alias) from artist where name like 'Elvis%Presley’ )) artistsusing artist_id
®© 2014 MapR Technologies 42
まとめ • リレーショナルモデルの拡張により、 極めてシンプルになる
– 実際の例では、テーブル数を 1/20 以下に削減できた
• シンプルにすることで、内観の改善につながる – これは good
• Apache Drill は拡張されたリレーションの問題に対して非常に高速な処理を行うことが可能
• 今すぐに試すことができる
®© 2014 MapR Technologies 44
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
®© 2014 MapR Technologies 45
Real World Hadoop Ted Dunning、Ellen Friedman 著、2015 年 3 月出版(オライリーより)
本日サイン会にて無料配布
Recommended