2018年度若手技術者向け講座大量データの扱い・ストアド・メモリ管理

概要
• 大量のデータを効率よく扱う方法を学習します。
• ストアドプロシージャについて学習します。
• DBMSのメモリ管理について学習します。
2

目次
• 大量のデータを扱う
• インデックスを後から作成する
• ダイレクトパスインサート(Oracle)
• バルクインサート(Oracle)
• テストデータ作成のテクニック
• ストアドプロシージャの活用
• DBMSのメモリ管理
• データキャッシュ
• ログバッファ
• ワーキングメモリ
3

前提条件
• このテキストの内容はPostgreSQL（バージョン9.6.9）の環境で検証し
たものとなっています。
• テキストと同じ環境で検証する場合はPostgreSQLをインストールし、
事前にデータベース（axizdb）とユーザー（axizuser）を作成してくだ
さい。
• 一部、Oracleによる検証も行っています。Oracleは12c Relase2の
Enterprise Editionを使用しています。
4

大量データのインサート方法
• 大量データをインサートする手順
大量のデータを一括でインサートしたい場合
1. テーブル定義作成
2. インサート
3. インデックス作成
の手順で実施する。
インデックス作成の手順を先に行ってはいけない！
なぜでしょうか。
6

• なぜインデックスを後から作成するのか
• インデックスの内部構造は木構造になっている。（B-tree）
• 木の深さは均等になるような構造になっている。
• insert, update, deleteを実行したら、インデックスの構造が
組み変わるアルゴリズムが動く。
データを大量にインサートする場合、インサートのたびにインデック
構造を変化するアルゴリズムが動作するため、DBMS内の負荷が高くな
る。
• インサート後にインデックスを作成すれば、アルゴリズム自体は
一回の実行で終了するため、負荷を減らすことができ、
速度が速くなる。
7

• 検証（テーブル定義）
• 実際に検証してみます。以下のような構造のテーブルとインデックス
を用意します。
• 10万件のデータをインサートするとき、インデックスを先に作る場合
と後に作る場合の差異を確認してみます。
8
itest インデックス
物理名型 primary key 1 id
id int 〇 2 c1
c1 char(500) 3 c2
c2 char(500) 4 c3
c3 char(500) 5 c4
c4 char(500) 6 c5
c5 char(500) 7 c6
c6 char(500) 8 c7
c7 char(500) 9 c8
c8 char(500)

• 検証（インデックスを先に作成）
• まずはテーブルを作成します。
9
axizdb=>create table itest(
id int primary key
, c1 char(500)
, c2 char(500)
, c3 char(500)
, c4 char(500)
, c5 char(500)
, c6 char(500)
, c7 char(500)
, c8 char(500)
);

• 次にインデックスを作成します。
• 8つのインデックスを作成します。
10
create index c1_index on itest (c1);

• 10万件のデータをインサートするのにかかる時間を検証します。
11
select now(); -- 開始時刻を表示
-- 再帰SQLを使用して、10万件のデータを作成する
insert into itest
with recursive DUMMY(i) as
(
select 1 i
union all
select i+1 from DUMMY where i < 100000
)
select i , 'c1' || i , 'c2' || i, 'c3' || i, 'c4' || i, 'c5' ||
i, 'c6' || i, 'c7' || i, 'c8' || i from DUMMY;
select now(); -- 終了時刻を表示

• 実施結果は以下のようになります。
12
開始時刻終了時刻
データ作成

• 処理前と処理後の時間を比較すると、2分以上かかっていることが分
かります。
13

• 検証（インデックスを後に作成）
• 次は、データを作成した後にインデックスを作成する場合を検証しま
す。
• テーブルを一度削除して再作成し、空の状態にしてください。
14
select now(); -- 開始時刻を表示
-- 10万件インサート
insert into itest
(select 1 i
union all
select i+1 from DUMMY where i < 100000
)
select i , 'c1' || i , 'c2' ||
i, 'c3' || i, 'c4' || i, 'c5' ||
i, 'c6' || i, 'c7' || i, 'c8' ||
i from DUMMY;
-- インデックス作成
select now(); -- 終了時刻を表示

• 実行結果は以下のようになります。
15
開始時刻
データ作成

• 実行結果は以下のようになります。（続き）
16
インデックス作成
終了時刻

• 今回は処理前の時間と処理後の時間を比較すると50秒程度となってい
ます。
• 環境によって誤差はありますが、今回は1分以上差が出ました。
• この差はデータ量やインデックスの数が増えるとさらに大きくなりま
す。
17

ダイレクトパスインサート
• ダイレクトパスインサート（Oracleのみ）
• Oracleでのみサポートされる技術
• 一言でいうと、REDOログを経由せずに直接ディスク上に
書き込むことで、高速なインサート処理が可能になる。
18
-- ①
INSERT /*+ APPEND */ INTO table1 SELECT * FROM table2 ;
-- ②
INSERT /*+ APPEND_VALUES */ INTO table1 VALUES (1, 'a') ;

• 検証
19
通常のインサート(約3分半) ダイレクトパスインサート(8秒)

• まとめ
• Oracleの場合、大量のデータをインサートする際にはダイレクトパス
インサートを検討する。
• ただし、Enterprise Editionのみ使用可能。
• また、排他ロックがかかる、High Water Markが新しく割り当てられる
などのデメリットもあるので、使用する際は注意する。
20

バルクインサート
• バルクインサート
• ブルクインサートは、大量のデータをインサートする際に使用する技
術です。
• DBMSによってサポートの有無が異なります。
• ここではOracleのバルクインサートの例を紹介します。
21

• サンプル（通常のインサート）
• 以下はバルクインサートを使用しない、通常のインサートを行う
PL/SQLのプログラムです。itestというテーブルのレコードをitest2とい
うテーブルにインサートしています。
22
create or replace procedure insert_test_normal is
cursor csrItest is select * from itest; -- カーソルの定義
wk_itest csrItest%rowtype; -- レコードを格納する変数
begin
open csrItest; -- カーソルオープン
loop -- レコードの数だけループ
fetch csrItest into wk_itest;
exit when csrItest%notfound;
insert into itest2 values wk_itest; -- インサート
commit;
end loop;
close csrItest;
end;

• サンプル（バルクインサート）
• 以下はバルクインサートのプログラムをバルクインサートを使用する
ものに修正したものです。
23
create or replace procedure insert_test_bulk is
cursor csrItest is select * from itest; -- カーソルの定義
type tItest is table of itest%rowtype index by binary_integer;
wk_itest tItest; -- レコード型の配列
begin
open csrItest;
loop
fetch csrItest bulk collect into wk_itest limit 1000;
exit when wk_itest.count = 0;
forall i in 1..wk_itest.count
insert into itest2 values wk_itest(i); -- 1000件をまとめてインサート
commit;
end loop;
close csrItest;
end;

• 比較
• 通常のインサートでは、ループしながら1件ずつインサートしていま
す。
• 一方でバルクインサートの方は、1000件ずつまとめてインサートをし
ているのが分かります。
• 1000の数値を変更することで、1回のインサートのレコード数を変更
することができます。
24
fetch csrItest bulk collect into wk_itest limit 1000;
exit when wk_itest.count = 0;
forall i in 1..wk_itest.count
insert into itest2 values wk_itest(i);
fetch csrItest into wk_itest;
exit when csrItest%notfound;
insert into itest2 values wk_itest;
通常のインサートバルクインサート

• まとめ
• バルクインサートを使用することで、大量のレコードをまとめてイン
サートできる。
• 一般に通常のインサートよりも高速になりますが、メモリを多く消費
します。
• メモリの容量とレコードのサイズ次第では通常のインサートよりもパ
フォーマンスが落ちてしまう場合もあるので、プログラムに組み込む
場合は遅くならないことを検証してから使用するようにしましょう。
25

大量データの扱いまとめ
• 大量のデータを高速にインサートしたい場合
• インデックスは後から作成する
• ダイレクトパスインサートを活用する（Oracle限定）
• バルクインサートを活用する（使用できるかはDBMS製品に依存する）
26

テストデータの作成
• 大量のテストデータをインサートする際のテクニック
テストのために、まとめて数十万件のデータをインサートする場面し
たい場合、どのようにしてテストデータを作成していますか。
再帰を利用したSQLを使用すれば、一括でのインサートが可能となりま
す。
27

テストデータの作成(再帰SQL)
上記のSQLを実行すると、図のように
10000件のレコードを取得できる。
大量のテストデータをインサートする際などに役立つ。
28
実行結果
-- 例 PostgreSQLの場合
(select 1 i
union all
select i+1 from DUMMY where i < 10000)
select i as id, 'テスト' as name from DUMMY;
id name
1 テスト
2 テスト
3 テスト
4 テスト
… …
9997 テスト
9998 テスト
9999 テスト
10000 テスト
-- 例 Oracleの場合
with DUMMY(i) as
(select 1 I from dual
union all
select i+1 from DUMMY where i < 10000)
select i as id, 'テスト' as name from DUMMY;

• クロス結合の使用
• クロス結合はプログラム内で使用することはほぼないが、
大量のテストデータを作成するときには便利です。
• pg_dependはシステムカタログにあるテーブル
7000件以上のレコードがある。cross joinすることで、
7000 × 7000 で 49,000,000以上のレコードが取得される。
29
実行結果
-- 例 PostgreSQL
select row_number() over(order by 1) num, 'test'
from (select *
from pg_depend A -- 約7000件
cross join
pg_depend B -- 約7000件
) A;
num test
1 test
2 test
3 test
4 test
5 test
6 test
7 test
8 test
・・・・・・

• ストアドプロシージャの活用
• さらに柔軟にテストデータを作成したい場合は、ストアドプロシー
ジャを作成した方が有効な場合もあります。
30

ストアドプロシージャの活用
31

• ストアドプロシージャ
• 大抵のDBMSには、そのDBMS内で動作するプログラミング言語が実装
されています。それをストアドプロシージャと呼びます。
• 戻り値の有無によって、ストアドファンクションと呼ばれるものもあ
ります。
• 複雑なSQLの処理を手続型のプログラミングで記述できるため、デー
タ移行やシステム開発での有効活用が期待できます。
• DBMSによって言語仕様が異なるので、DBMSを別の製品に移行する際
には注意が必要です。
32

• インサート処理をするストアド
• 以下は、データのインサートの際に使用したプログラムです。
• ループ処理しながらレコードをインサートしています。
33
create or replace function insert_itest(start_id int, end_id int) returns decimal as '
begin
for i in start_id..end_id loop
insert into itest values(i , ''c1'' || i , ''c2'' || i, ''c3'' || i
, ''c4'' || i, ''c5'' || i, ''c6'' || i
, ''c7'' || i, ''c8'' || i);
end loop;
return 0;
end;
' language plpgsql;

• インサート処理をするストアド
• 実行するときはSELECT句に呼び出す処理を記述します。
※これはPostgreSQLの場合です。DBMSによって呼び出し方法は異なる
ので、詳しくは各製品のマニュアルを参照してください。
34
SELECT insert_itest(1, 10000);

• 金額を算出するストアド
35
create or replace function sales_sum() returns decimal as '
declare
product RECORD; -- 商品レコード用変数
sales RECORD; -- 売上レコード用変数
sales_num real; -- 合計金額用変数
begin
sales_num = 0;
for product in select * from products where category_id = 3 loop -- 商品でループ
for sales in select * from sales
where products_id = product.products_id loop -- 販売でループ
-- 金額を加算
sales_num = sales_num + product.p_price * sales.unit_sales;
end loop;
end loop;
return sales_num; -- 合計を戻す
end;
' language plpgsql;

• 金額を算出するストアド
• 取得したレコードでループしながら金額を算出するプログラムです。
• 戻り値として算出したプログラムを返しています。
• SELECT句の中で使用することで、結果を取得することができます。
36

• ホスト言語からのストアドの活用
• 通常、システム開発をする際はJavaなどのホスト言語からDBへ接続し
てSQLを発行します。
• ストアドプロシージャは、そのようなホスト言語からの接続にも活用
できます。
37

• Javaによる接続
38
double sum = 0;
String sql = "select * from products where category_id = 3"; // 商品取得用
stmt = con.prepareStatement(sql);
ResultSet rs = stmt.executeQuery(); // SQL文の実行
while (rs.next()) { // 商品テーブルでループ
int id = rs.getInt("products_id");
double price = rs.getDouble("p_price"); // 単価取得
String sql2 = "select * from sales where products_id = " + id; // 販売取得用
PreparedStatement stmt2 = con.prepareStatement(sql2);
ResultSet rs2 = stmt2.executeQuery();
while (rs2.next()) { // 販売テーブルでループ
sum += price * rs2.getDouble("unit_sales"); // 合計を加算
}
}
System.out.println(sum); // 出力

• 今回のサンプルは、先ほどのストアドプロシージャと同じ結果になる
処理をJavaで記述したものです。
• Javaの処理の中で、商品テーブルのループのたびに販売テーブルにア
クセスしています。
39

• 先ほどの処理を、ストアドプロシージャを使用するように修正した
コードです。
• 処理をストアドプロシージャに任せた分、Javaのソースコードが短く
なっています。
40
double sum = 0;
sql = "SELECT sales_sum()"; // ストアドの呼び出しのSQL
stmt = con.prepareStatement(sql);
rs = stmt.executeQuery(); // SQL実行
if (rs.next()) {
sum = rs.getDouble(1); // ストアドの結果取得
}
System.out.println(sum); // 出力

• ストアドプロシージャを使用することで、JavaからDBへの接続回数を
減らせることができるので、パフォーマンス的にもメリットがありま
す。
41

ストアドプロシージャまとめ
• まとめ
• ストアドプロシージャをつくることで、複雑なSQLの処理をまとめる
ことができる。
• ホスト言語からDBに接続するときに使用すれば、ソースコードを短く
できる + パフォーマンスが良くなるメリットがある。
• DBMSごとに仕様が大きく異なるため、DBMSを移行する際にはコスト
がかかる。
42

DBMS上のメモリ領域
• バッファマネージャー
• DBMSはバッファと呼ばれるメモリ領域を確保します。
• そのメモリ領域の使い方を管理するのがバッファマネージャーと呼ば
れるものです。
• DBMSのパフォーマンスにとって大きな役割を果たしています。
44

DBMS上のメモリ領域
• DBMS上のメモリ領域
DBMSは、データを保持するためのメモリ領域を確保しています。
メモリの種類と役割を見ていきます。
DBMSが確保するメモリ領域は主に３つあります。
データキャッシュとログバッファはデータを保持するための領域です。
45

データキャッシュ
• データキャッシュは、名前の通り、データを保持するためのメモリ領
域です。select文を実行した結果を保持します。
• select文を実行した際、データキャッシュにデータがあれば、高速なレ
スポンスを期待できます。データキャッシュにない場合、ディスク上
からデータを取得するため、その分レスポンスは低下します。
• 大量のデータを扱うか否かに関わらず、データキャッシュのメモリ領
域を多く確保すれば、SQLの処理を高速にできます。
46

• データキャッシュの呼び方
• Oracle：データベースバッファキャッシュ
• PosgreSQL：共有バッファ
• MySQL：バッファプール
47

• PostgreSQLのデータキャッシュの確認
48
axizdb=> show shared_buffers;

ログバッファ
• ログバッファは、通常データキャッシュに比べると少ない割り当てと
なっています。
• しかしログバッファの容量が小さいと、大量のデータをまとめて更新
する際には時間がかかってしまいます。
• データ移行などで大量のデータを更新する場合には、定期的にcommit
を行ったり、ログバッファの値を変更するなどの対応が必要になりま
す。
49

ログバッファ
• 更新処理（insert, update, delete）を実行した際に、更新結果が格納されるメ
モリ領域です。
• 更新処理のSQL文を実行した段階では、ディスクへの更新は行われません。
commitした段階で更新情報がログファイルに書き込まれ、それからディスク
上に更新します。
• これは、DBMSがストレージへの更新が終わっていない段階でも次の処理を開
始できるための仕組みになっています。
ログバッファの容量が小さいと、
大量のデータをまとめて更新する際には時間がかかってしまう。
データ移行などで大量のデータを更新する場合には、定期的に
commitを行うと速くなる場合がある。
50

ログバッファ
• ログバッファの呼び方
ログバッファは呼び方がDBMSによって異なるので注意
• Oracle：REDOログバッファ
• PostgreSQL：トランザクションログバッファ
• MySQL：ログバッファ
51

ログバッファ
• PostgreSQLのログバッファの確認
52
axizdb=> show wal_buffers;

ワーキングメモリ
• ワーキングメモリは、ソートなど、特定の処理に利用されるメモリ領
域です。order by句や、ウィンドウ関数を使用する際などに利用されま
す。
• 扱うデータ量が多く、ワーキングメモリの領域を溢れた場合は、ディ
スク上の一時領域が使用されます。
• そうなった場合、ディスクへのアクセスは当然メモリよりも低速のた
め、レスポンスが低下します。
53

• ワーキングメモリの呼び方
ワーキングメモリや一時領域は、DBMSによって呼び方が異なるので注
意する。
• Oracle：PGA
• PostgreSQL：ワークバッファ
• MySQL：ソートバッファ
一時領域
• Oracle：一時表領域(TEMP表領域)
• SQL Server：TEMPDB
• PostgreSQL：一時領域(pgsql_tmp)
54

• PostgreSQLのワーキングメモリの確認
55
axizdb=> show work_mem;

DBMSのメモリまとめ
• DBMSのメモリまとめ
• データキャッシュはSELECTのためのメモリ
• ログバッファは更新のためのメモリ
• ワーキングメモリはソートやハッシュの処理のためのメモリ
• SQLのパフォーマンスが悪い場合、サーバーのメモリに余裕があるな
らばメモリの設定の変更も検討する。
56

Oracleの大量データの速度比較
• インデックス作成済みでの10万件インサート
• 30分近くかかる
58

Oracleの大量データの速度比較
• 10万件インサート後にインデックス作成
• 約3分
59

Oracleのストアド
• Oracle版の合計算出用ストアド
60
create or replace function sales_sum return number is
-- 商品テーブル用のカーソル
cursor csrProducts is select * from products where category_id = 3;
-- 商品カーソル格納用
wk_product csrProducts%ROWTYPE;
-- 販売テーブル用のカーソル
cursor csrSales is select * from sales where products_id = wk_product.products_id;
-- 販売カーソル格納法
wk_sales csrSales%ROWTYPE;
sales_sum number; -- 合計算出用
begin
sales_sum := 0;
open csrProducts; -- 商品カーソルでループ
loop
-- ⇓続く

Oracleのストアド
• Oracle版の合計算出用ストアド（続き）
61
fetch csrProducts into wk_product;
exit when csrProducts%NOTFOUND;
open csrSales; -- 販売カーソルでループ
loop
fetch csrSales into wk_sales;
exit when csrSales%NOTFOUND;
-- 合計加算
sales_sum := sales_sum + (wk_product.p_price * wk_sales.unit_sales);
end loop;
close csrSales;
end loop;
close csrProducts;
return sales_sum;
end;
/

2018年度若手技術者向け講座大量データの扱い・ストアド・メモリ管理

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 2018年度若手技術者向け講座大量データの扱い・ストアド・メモリ管理

Similar to 2018年度若手技術者向け講座大量データの扱い・ストアド・メモリ管理 (20)

More from keki3

More from keki3 (20)