Apuri she ji_gaido_teburushe_ji__v1.0

アプリケーション設計ガイド
テーブル設計
バージョン9.1, Enterprise mode
作成日：2018年7月5日
更新日：2018年XX月XX日
1

更新履歴
版日付変更者変更内容備考
1.0 2018年7月5日大林加奈子初版発行
※注意点
社外に提示する際は、本スライド(更新履歴)を削除し、PDF化
してお渡しください

Agenda
 テーブル設計に関するチェックポイント
 Verticaでのテーブル概要説明
 文字列カラムの設計
 Verticaのパーティション概要説明
 パーティション設計
 パーティション関連パラメーター設定
 パーティション関連のモニタリング
 関連ページ

テーブル設計に関するチェックポイント
• YESの場合：次のチェックポイントへ
• NOの場合：「Verticaでのテーブル概要説明」へ
テーブルとプロジェクションの定義
を認識されていますか？
• NOの場合：「文字列カラムの設計」へ
マルチバイト文字を保持するカラム
長が適切に設計されていますか？
• NOの場合：「Verticaのパーティション概要説明」へ
Verticaでのパーティションについて
理解されていますか？

テーブル設計に関するチェックポイント
• NOの場合：「パーティション設計」へ
パーティションが適切に設計され
ていますか？
• NOの場合：「パーティション関連パラメーター設定」へ
パーティション関連パラメーター
が適切に設定されていますか？
• YESの場合：終了
• NOの場合：「パーティション関連のモニタリング」へ
パーティション関連の確認方法に
ついて把握されていますか？

Verticaでのテーブル概要説
明
6

Verticaでのテーブル概要説明
Verticaではテーブルにデータを保持せず、プロジェクションにデータを保持
テーブル
論理的
プロジェクション
物理的
Sales_fact_p1
Sales_fact
日付顧客ID 売上高
0701 10000000001 100
10000000002 480
10000000003 2,500
日付エリア店舗顧客ID 売上高
0701 東京新宿 10000000001 100
: : : : :
0707 大阪梅田 10000000005 1,300
Sales_fact_p2
日付顧客ID 店舗エリア売上高
date int varchar(10) varchar(10) Int

Projection-3
create table table1
(日付 date ,顧客ID(int),店舗 varchar(10),エリアvarchar(10) , 売上高(int)）;
Verticaでのテーブル概要説明
Verticaでは、テーブルは論理スキーマとして定義（実体は持たない）
日付顧客ID 店舗エリア売上高
date int varchar(10) varchar(10) Int
日付売上高
0701 100
1,000
0702 1,0000
0703 2,400
1,600
6,400
0705 1,000
0706 1,100
1,300
Projection-1 Projection-2
エリア店舗日付売上高顧客ID
大阪梅田 0703 2,400 10004
0706 1,100 10008
東京池袋 0703 1,600 10005
品川 0705 1,000 10007
新宿 0701 100 10001
1,000 10002
0703 6,400 10006
名古屋名古屋 0702 1,0000 10003
0706 1,300 10009
大阪梅田の平均売上高 7/6の売上
プロジェクションは物理スキーマとして定義（自動ツールによりチューニング）
クエリー毎に最適化を事前に行うことも可能
店舗売上高（SUM)
名古屋 11,300
新宿 7,500
梅田 3,500
池袋 1,600
品川 1,000
店舗別売上ランキング
(事前集計プロジェクション)

文字カラムの設計
 データの内容を確認し正しいデータ型を指定。VARCHARを指定する場合、余分なサイズで指
定しない（該当のカラムがJOINやGROUP BYで使用されると性能劣化が発生する可能性がある
ため）
 Vertica上の文字コードは、UTF-8（1byte～4byte）
 マルチバイト文字を含む場合、該当の列については、「日本語文字数×4 byte」で設定
- 例：10文字の日本語が含まれる場合
- DDLにおいて、該当の列の型を「VARCHAR(40)」あるいは「CHAR(40)」
 関連ページ
- https://my.vertica.com/docs/latest/HTML/index.htm#Authoring/AdministratorsGuide/Locales/LocaleUTF8Supp
ort.htm

Verticaのパーティション概
要説明
11

Verticaのパーティション概要説明
パーティショニングはテーブル単位で列に対して定義
 テーブル定義で指定したキーを元に、データをノード内で分割
 高速なデータ削除とクエリパフォーマンス向上に有効
Vertica#1 Vertica#2 Vertica#3 Vertica#4 Vertica#5
2015/3/
1
2015/3/
1
2015/3/
1
2015/3/
1
2015/3/
1分散テーブル
（分散化されたプロジェクション）
Data#1
Data#2
Data#3
Data#4
Data#5
ソースデータ
2015/3/
2
2015/3/
3
2015/3/
2
2015/3/
3
2015/3/
2
2015/3/
3
2015/3/
2
2015/3/
3
2015/3/
2
2015/3/
3

DDL例）
Create table TEST(
YYYY VARCHAR(4) not null,
MM VARCHAR(2) not null,
DD VARCHAR(2) not null,
SALES_AMOUNT NUMERIC(9,2)
)
Segmented by HASH (SALES_AMOUNT) all nodes
Partition by (YYYY|| MM || DD);
Node#1
Node#2
Node#N
Projection A
Insert/COPY
①ノード分散
①ノード分散
ハッシュキーごとに、
格納するノードを決
定
Projection B
②パーティション分散
2017/9/1 2017/9/2 2017/9/3
②パーティション分散
パーティションキーを元に、格納先を決定。
そのキーを持つパーティションがなければ、
自動作成される
2017/9/1
パーティション
（≒ファイル、ROS）
パーティションキー
全プロジェクション
で同じ動き
セグメンテーションとパーティショニング

パーティションすることのメリット・デメリット
 メリット
1. データ削除の高速化 ※多くの場合、データ削除の高速化のために、パーティション化実装
- Select drop_partition(‘partition_key’); を実行することにより、ファイルのかたまり（ROSコンテナ）を高速に物理
削除可能
2. パーティションプルーニング（Partition Pruning）／ストレージプルーニング（Storage Pruning）
- 実行クエリに関連するレコードが含まれないことが分かっているファイルのかたまり（ROSコンテナ）を読み
飛ばしすることが可能であるため、クエリ実行の高速化を実現
 デメリット
1. エラー発生の危険性
- パーティションを細かく切りすぎてしまうことにより、データロード時にToo many rosコンテナエラーが出るこ
とを誘発してしまう可能性あり
2. カタログのサイズの肥大化
- パーティションを細かく切りすぎてしまうことにより、物理ファイル数が増えてしまい、カタログのサイズが
肥大化してしまう可能性あり
14

パーティションプルーニング（Partition Pruning）／ストレージプ
ルーニング（Storage Pruning）
 適用可能な値を格納しないストレージコンテナを省き、I/Oを削減し、クエリパフォーマンス
を向上
 例：年ごとにパーティション化されたデータを持つテーブル
- 2017年のコンテナだけ参照し、その他のコンテナを読み飛ばす動作となる
date amount
2017-10-11 6
2017-09-05 12
･･････
2017-08-22 8
=> CREATE TABLE ... PARTITION BY EXTRACT(year FROM date);
=> SELECT ... WHERE date = ‘2017-08-22’;
date amount
2016-03-13 96
2016-04-21 17
･･････
2016-02-22 7
date amount
2015-07-12 43
2015-03-02 45
･･････
2015-12-02 68
Min: 2017-01-01
Max: 2017-12-31
Min: 2016-01-01
Max: 2016-12-31
Min: 2015-01-01
Max: 2015-12-31
読み飛ばし読み飛ばし

パーティション設計
16

パーティション設計
 サイズが大きいファクトテーブルのみパーティション化することを推奨
 DROP_PARTITION関数でデータを削除できるように、設定する場合が多い
- テーブルをパーティション化を使用してデータをグループ毎に分ける
- 例：
- 取引が行われた年に基づいてデータを分割するように指定
17
=> CREATE TABLE trade (
tdate DATE NOT NULL,
tsymbol VARCHAR(8) NOT NULL,
ttime TIME)
PARTITION BY EXTRACT(year FROM tdate);

データ削除に最適化するためのパーティション設計例
Clickstreamテーブルのテーブル設計例
 Clickstreamテーブルの年月カラムに対して、
DROP_PARTITIONを実行する際の実行クエリ
例
 Clickstreamテーブルのテーブル設計例
=> select
DROP_PARTITION(‘Clickstream’,’2016’);
CREATE TABLE clickstream (
tdate DATE NOT NULL,
user VARCHAR(20),
URL VARCHAR(100),
…
)
PARTITION BY EXTRACT
(year FROM tdate);
2016年のデータを全て削除。Rollback不可
だが、デリートベクターは生成されず、
ファイルがただちに物理削除されるため、
システムパフォーマンスに悪影響を与え
ることはない。パーティションキーの指定に関数も使
用可能。ただし、パーティションキー
ごとにROSコンテナが生成されるため、
ROSコンテナのノード・プロジェク
ション毎の上限値1024を超えないよう
に指定するカラムを決める必要あり。

パーティション関連パラ
メーター設定
19

パーティション関連パラメーター設定
 ActivePartitionCount
- Verticaにアクティブパーティションを認識させ、Mergeoutを効率的に実行させるために設定
- デフォルト値：１
- 設定方法：
1. 現在の設定を確認する。
2. 設定を変更する。
=> select get_config_parameter('ActivePartitionCount');
get_config_parameter
----------------------
1
(1 row)
=> select set_config_parameter('ActivePartitionCount',2);
set_config_parameter
----------------------------
Parameter set successfully
(1 row)

アクティブパーティションとは
 ストラータアルゴリズムに則って、Mergeoutを行うパーティション
 頻繁かつ同時にロード・更新されうるパーティション（の数）をアク
ティブパーティションに設定
例）
日単位でパーティションを設定しているテーブルに対するバッチ処理
において、必ず当日データ＋前日データで更新する場合は、当日と前
日の2パーティション分がアクティブパーティションになるよう、
ActivePartitionCountを2に設定する

ストラータアルゴリズムとは
 アクティブパーティションを構成するROSコンテナのサイズ、数など
を制御するアルゴリズム
 アクティブパーティションに対するMergeoutは、システムテーブル
STRATA で定義された条件にしたがい、効率的に動作する
 非アクティブパーティションは基本的に一つのROSに統合

10GB
100MB
10MB
1MB
1GB

10GB
100MB
10MB
1MB
1GB
多くの小さい ROS コンテナが積極的なト
リクルロードにより発生するかもしれな
い。また、デリートベクターも別の ROS
コンテナとして発生する。

10GB
100MB
10MB
1MB
1GB
MERGEOUT 処理は、 STRATA を使い、より
小さい ROS を組み合わせてより大きい
ROS にする。

10GB
100MB
10MB
1MB
1GB
ROS にする。

10GB
100MB
10MB
1MB
1GB
ROS にする。
DIRECT のバルクロードは、いくつかのス
トラータをスキップする可能性あり。

10GB
100MB
10MB
1MB
1GB
ROS にする。
DIRECT のバルクロードは、いくつかのス
トラータをスキップする可能性あり。
コンテナを統合する。一般的に、非アク
ティブパーティションは、シングルの
ROS コンテナとして存在する。

パーティションとROS
1COPYでも、パーティション毎にROSが分かれて保持される
日付,都道府県,売上
5/20,Tokyo,3000
5/21,Tokyo,4500
5/22,Tokyo,10000
5/20 5/21 5/22COPY
5/20,Osaka,3000
5/21,Osaka,4500
5/22,Osaka,10000
COPY 5/20 5/21 5/22
パーティション毎に1つのROSコンテナ生成

パーティションとROS
パーティション毎にROSが統合される
5/20 5/21 5/22
Mergeoutでパーティション毎にROS統合
Tuple Mover

ActivePartitionCount=1の場合
5/22がアクティブパーティション
5/20,Tokyo,3000
5/21,Tokyo,4500
5/22,Tokyo,10000
5/20 5/21 5/22COPY
5/20,Osaka,3000
5/21,Osaka,4500
5/22,Osaka,10000
COPY 5/20 5/21 5/22

アクティブパーティションはSTRATAの条件を満たさないと統合されない
5/20 5/21
Tuple Mover
5/22
5/22
最新パーティションは、検索処理と競合さ
せないよう、むやみにMergeoutさせない

5/21, 5/22がアクティブパーティション
5/20,Tokyo,3000
5/21,Tokyo,4500
5/22,Tokyo,10000
5/20 5/21 5/22COPY
5/20,Osaka,3000
5/21,Osaka,4500
5/22,Osaka,10000
COPY 5/20 5/21 5/22

アクティブパーティションはSTRATAの条件を満たさないと統合されない
5/20
Tuple Mover
5/22
5/22
5/21
5/21

ActivePartitionCountを増やすと
 メリット
- 巨大ファイルのMergeoutの頻発によるシステム負荷を抑えることが
できる
 デメリット
- 統合されないROSが増えて、
- 遅くなる検索が発生する可能性がある
- ROS Pushback（ROSの制限値超えエラー）が発生する可能性がある

パーティション関連のモニ
タリング
36

PARTITIONSテーブル
 例：ノード・プロジェクション毎のパーティション数の確認方法
=>SELECT node_name
,projection_name
,count(partition_key)
FROM v_monitor.partitions
GROUP BY node_name
,projection_name
ORDER BY node_name
,projection_name;
node_name | projection_name | count
----------------+-----------------------------+-------
v_demo_node0001 | inventory_fact_partition_b0 | 5
v_demo_node0001 | inventory_fact_partition_b1 | 5
･･･

STRATAテーブル
SELECT * FROM STRATA ;
Node_name | schema_name | projection_id | projection_name | partition_key | strata_count | merging_strata_count |
stratum_capacity | stratum_height | stratum_no | stratum_lower_size | stratum_upper_size | ROS_container_count
----------+-------------+-------------------+-----------------+---------------+--------------+----------------------+-----------
-------+----------------+------------+--------------------+--------------------+---------------------
node0001 | public | 45035996273942458 | t3_node0001 | 2016 | 11 | 4 |
32 | 28.8 | 0 | 0B | 2MB | 1
32 | 28.8 | 1 | 2MB | 57.6MB | 25
32 | 28.8 | 2 | 57.6MB | 1.62GB | 1
32 | 28.8 | 0 | 0B | 2MB | 6
32 | 28.8 | 1 | 2MB | 57.6MB | 25
32 | 28.8 | 2 | 57.6MB | 1.62GB | 1
アクティブパーティションは2016年、2017年データ
STRATAで定義された範囲でROSコンテナが生成
STRATA_STRUCTUREテーブルで、上記のサマリーも確認可能

関連ページ
 Vertica Partitions: The FAQs （英語）
- 上記記事の日本語版はこちら
 Using Table Partitions （英語）
39

Thank you
japan_vertica_info@microfocus.com

Apuri she ji_gaido_teburushe_ji__v1.0

Recommended

Recommended

More Related Content

Similar to Apuri she ji_gaido_teburushe_ji__v1.0

Similar to Apuri she ji_gaido_teburushe_ji__v1.0 (20)

More from Kaito Tonooka

More from Kaito Tonooka (11)

Apuri she ji_gaido_teburushe_ji__v1.0

Editor's Notes