2018年2月16日AUG関西支部勉強会資料です。

1. まだまだ知らない！？
コンポーネントあれこれ！
インフォテリア株式会社
ASTERIA事業本部 営業推進部
技術支援担当 菊地 雄大

2. 自己紹介
 名前
菊地 雄大（きくち たけひろ）
 年齢
31歳
 普段のおしごと@東京
ASTERIAのプリセールス
セミナー講師（体験セミナー・トレーニング）
菊ちゃんブログ（ASTERIA体験記）
 好きなコンポーネント
• LoopStartコンポーネント
• Timerコンポーネント

3. はじめに
ASTERIAにどれくらいのコンポーネントが用意されて
いるか知っていますか？
なんと、約300種類もあるんです！！
でも。。。業務の中でよく使うコンポーネントって限
られてきませんか？
普段使わない＝知らない（かも？）な
便利なコンポーネントや
便利な使い方をご紹介していきます！

4. 面倒なテストデータ作成を
お手軽に！！
～LoopStartコンポーネント～

5. 大量レコードデータの作成。。。
こんな時どうしていますか？
負荷試験に備えて大量データの準備。。。
 Excelのオートフィル機能を利用
ドラッグが面倒！！
 バッチを作る
そこまで手間をかけますか？
もっと手軽に
テストデータ作れないかな？？

6. LoopStartで大量データをお手軽作成！
1行データを準備するだけ！
LoopStartコンポーネントで
必要な件数のデータを
生成してくれます

7. コネクションを
動的に切り替える！
～DynamicConnectionコンポーネント～
～Timerコンポーネント～

8. こんな時はありませんか？
複数システム（複数拠点）のDBにデータを書き込みたいけど、
同じテーブル構造なのに別処理（フロー）を書かないといけ
ない？
-項目に修正が入ったら全部のマッピングを変更？
RDB
RDB
RDB
RDB 拠点A
拠点B
拠点C
拠点D

9. コネクションを動的に切り替える！
コネクション定義を実行時に変更するコンポーネントです。
使い方
ただ・・・、
“1回のリクエスト実行の中で一つのコネクションに対して一度だけ実行できます。”
２システム以上のDBに登録したいとかの場合は・・・・
なのでこの場合非同期処理にします。
ここで動的に設定する

10. こんな感じで非同期呼び出し
Timerコンポーネント使います
Timerコンポーネントで非同期呼び出し
（別リクエストになる）
HTTPコネクションやメール系コネクションも使えますので是非！

11. フォーマットを気にせず
気軽に結合！
～RecordJoinコンポーネント～
～RecordSQLコンポーネント～

12. 別々のファイルデータをまとめたい。。。
注文情報と顧客情報をまとめて見たい！
ファイル同士の結合って
どうやるの？

13. RecordJoinで簡単結合
ファイル同士の結合ならこんなフローで
共通のキー
顧客ファイルの情報
注文ファイルの情報

14. こんな時にもRecordJoin！
結合できるのは
ファイルソースだけではありません！

15. データソースが別々でも。。。
ファイルとRDBで
結合できるの？
DB上の顧客情報
ファイルで受領した注文情報

16. こんなフローで結合できます
ファイルとの結合フロー
「白石 鈴子」をキーに
ファイルとDBの情報を結合！

17. 縦の結合（UNION）ってできる？
※UNION句とは
結果表を一つにまとめるSQL構文
売上明細_2016.csv 売上明細_2015.csv
DBに入れるのも
手間だし…

18. RecordSQLコンポーネント

19. ファイルソースもSQL加工が可能です
2つのファイルを
UNION完了！！

20. 実行されているのはこんなSQL
select
売上番号
日付
支店名
商品名
単価
数量
売上高
from
日毎売上明細_2015.csv
UNION
select
売上番号
日付
支店名
商品名
単価
数量
売上高
from
日毎売上明細_2016.csv
ORDER BY 支店名
ファイルを
DBのテーブルとして
加工できる！

21. レコード系コンポーネントは他にも。。。
レコードタブには他にも便利なコンポーネントがたくさ
ん用意されています
– RecordFilter（レコードのフィルタリング）
– RecordSort（レコードな並べ替え）
– RecordTranspose（レコードの縦横変換）
– RecordAggregate（レコードの集計）

22. レコード系コンポーネントの注意事項
 OutOfMemoryに注意！
 ASTERIAは中間DBは持っていないので全ての処理が
メモリ上で行われます
 大量レコードの処理には。。。
 「モード」プロパティで最適な処理を
読み込み件数を指定を！
• オンメモリ
FlowServiceのメモリを使用して処理を行うのでパ
フォーマンスが上がります。
• RDB
オンメモリと比べて大量のレコードを処理すること
ができます。（RDBはHSQLDBを使用しています）

23. 便利なコンポーネントに
潜むワナ！？
～TableDB関数～
～Startコンポーネント～
～EndResponseコンポーネント～

24. マスタ参照可能なTableDB関数
 TableDB関数：Mapper関数
データベースのテーブルから検索を行い、そ
の結果を値として返します。
たとえば社内のコード変換用マスタテーブルを参照
し、入力データを項目単位で変換します。
体験セミナーでも
使ってます

25. でも、これってSQLを度々なげてるのでパフォーマンス悪いんじゃないの？
実際ベンチとると。。。
TableDB
関数あり
（1Fieldのみ）
単位：ミリ秒 10,000レコード 1,000,000レコード
カラム RecordGet Mapper Total RecordGet Mapper Total
20
1回目 94 46238 46362 8457 4576079 4584613
2回目 78 45692 45801 8058 4589911 4598021
3回目 93 45177 45302 8112 4579001 4587167
4回目 78 45255 45364 7998 4529291 4537334
5回目 78 45270 45380 8287 4561102 4569440
平均 84 45526 45642 8182 4567077 4575315
単位：ミリ秒 10,000レコード 1,000,000レコード
カラム RecordGet Mapper Total RecordGet Mapper Total
20
1回目 109 32 1201 8395 2291 106471
2回目 109 18 1186 7878 1887 108421
3回目 110 31 1232 8346 1951 106767
4回目 109 15 1201 8799 1965 106081
5回目 109 15 1201 8176 1933 108232
平均 109 22 1204 8319 2005 107194
２０００倍遅くなる！１SQLで4.5ms！(-_-メ)
バッチ処理ではちょっと使えない・・・回避策は？
2秒
75分
TableDB関数に潜むワナ。。。
TableDB
関数なし
（1Fieldのみ）

26. TableStream
“リクエストまたはセッションに保持したストリームから入力をキーとして対応する値
を返します。StreamPutコンポーネントを使ってメモリに保持したストリームが対象で
す。”
1. まずStreamPutコンポーネントを使用して、対象のテーブルレ
コードをメモリ上に格納
2. MapperでTableStream
このコンポーネントで華麗に回避！
取得したテーブルデータを
参照できる！

27. TableDB
関数あり
（1Fieldのみ）
TableStream
関数あり
（1Fieldのみ）
単位：ミリ秒 10,000レコード 1,000,000レコード
カラム RecordGet Mapper Total RecordGet Mapper Total
20
1回目 94 46238 46362 8457 4576079 4584613
2回目 78 45692 45801 8058 4589911 4598021
3回目 93 45177 45302 8112 4579001 4587167
4回目 78 45255 45364 7998 4529291 4537334
5回目 78 45270 45380 8287 4561102 4569440
平均 84 45526 45642 8182 4567077 4575315
●注意点
• タイミングによっては最新のデータを参照していないので、その前提での
利用をお願いします。
• メモリ上に格納するのであまり大量データはよろしくないです。
単位：ミリ秒 10,000レコード 1,000,000レコード
カラム RecordGet Mapper Total RecordGet Mapper Total
20
1回目 80 2013 2141 8551 141871 150802
2回目 60 2004 2114 8321 139012 148550
3回目 75 2019 2135 8190 140889 149880
4回目 82 2027 2145 8033 142229 151788
5回目 78 2025 2148 8281 139772 148801
平均 75 2017 2136 8275 140754 149964
まさかの約20倍以上のパフォーマンス向上！
RDBGet：平均40ms
StreamPut：平均30ms
75分
2分20秒
パフォーマンスが向上！

28. Startコンポーネント
初めから置いてありますね。。。
でも大丈夫ですか？
コンポーネント処理ごとに
トランザクションが発生！
ファイルのOpen/Closeで
パフォーマンスのボトルネックに。。。
RDBの更新（commit）も同様。。。
Startコンポーネントの潜むワナ。。。
安心してください！
トランザクション化
“はい”に設定してください。
パフォーマンスが向上します！

29. トランザクション
＝“いいえ”
トランザクション
＝“はい”
約8倍
の差が

30. EndResponseコンポーネント
普通に使いますよね。でも、大丈夫ですか・・・？
メモリ上にデータが溜まっていきます。。。
EndResponseコンポーネントも。。。
安心してください！
レスポンス（標準出力）を
返さないでいい場合は
Endコンポーネントを利用してください！

31. こんな機能もありますよ
テンプレートとして登録
各種コンポーネントのプロパティ設定/ストリーム定義
をテンプレートとして登録し、次回以降再利用できる
初期値の
登録も出来る！
登録

32. 便利なコンポーネントはたくさんあります
フローの自由度
処理の簡素化
ただし、
コーディング規約
• 「使用してよい」コンポーネント
運用ルール
• エラー時の動作ルール
↑インフォテリアが弱い部分。。。
おわりに
みなさんでぜひ積極的な
情報交換を！
アップ！！
必要になるかも。。。？