2014-05-23

サンプル

2014-05-23

てすと

written by iHatenaSync

2014-03-01

ClubDB2参加記録第177回 DB2 BLUとイントラパラレル試してみたよ（ゲスト講師：永安氏)に行ってきました。

club DB2

久しぶりのblogです。
もっとアウトプットする癖を定着させたいですが、なかなかうまく行かないですね。

さて、表記の通りで、久しぶりにCLUB DB2に参加してきました。
最近は気持ちの余裕が足りてなく、勉強会からもついつい足が遠のいていましたが、「このままじゃダメだ」と思い、思い切って業務を切り上げて参加してきました。

DB2 BLU(ブルー)アクセラレーションのご紹介（by @sumi_chan )

簡易的に高速分析処理をさせるテクノロ ジー

カラムストアによるI/O削減
- 列単位で保管。DWHの場合、行全部ではなく一部の列にアクセスすることが多い → 余計な列をI/Oしない分I/Oを減らす
効率のよい圧縮
- 列単位で圧縮＝同じ（似た）データが繰り返しやすい＝圧縮率が上がる
- 高頻度のデータは高圧縮にする圧縮アルゴリズム
- 圧縮状態で演算が可能 → 解凍コストが不要
  - ”＝”だけでなく、”＞”、”＜”演算も可能！
SIMDを使うことで高速
- SIMD：Single Instruction Multiple Data
- 1回の命令で複数のレジスタを演算するH/W命令。
  - （例）v4si_add命令（gccで使える命令）
    - v4si_add(a,b)
    - {4,13,28,43} + {17,97,53,8} = {21,110,81,51} を1命令（1クロック）で処理する仕組み。ストア命令の分を考慮すると4倍以上命令数が少ないはず。
- IBMの技術というわけではなく一般的な技術（？）
データスキッピング
- 何らかのデータの塊（ページ単位？）毎にデータ範囲のタグを持つ。不要なページヘのアクセスをスキップすることでI/Oを減らす。
- (例)5年分のデータを保管しているDBで直近1年分だけアクセスする場合、不要な4年分にはI/Oしない。
エンティティ単位でカラムナを選択できる
- Create TableのOrganize by [COLUMN|ROW]で指定

BLUの強み

全体的に早くなることもメリットだけど、極端に遅いことを回避することが大きなメリット

DB2 BLUとイントラパラレル試してみたよ！(by 永安さん）

毎度ながら訳の分からない長文になるので、心に残ったキーワードを中心に。

PostgreSQLで限界を感じることがあるため、テクノロジーとしてイントラパラレルを試してみたかった
- PostgreSQLはシングルプロセス、シングルI/O
- グリーンプラムは？と思ったら、内部に複数のPostgreSQLが動いているらしい
元データ 100GBをDB格納すると
- Non-BLU ： 189GB（TBL+Index）
- BLU ： 48GB
  - この時点で約4倍の差。Non-BLUが圧縮なしとはいえ、この時点で大分性能が出そう。

検証結果として、すっごく早くなったクエリが沢山と、そんなに早くなっていない（それでも通常の行指向DBと同じぐらいのパフォーマンス）のクエリがある。
早くなるパターン
- 利用する列が少ない＝ I/Oが大量に減る
- I/Oが1/30に減る例も！
- その分CPUバウンドになって、CPU利用率が上がっている
- CPU利用率が上がっても総処理時間が短くなっているので、総CPU利用量は下がっていそう。
イマイチなパターン
- select *を含むクエリ
  - 内部で列をくっつけて行を作りなおすJoinが動くので、どうしてもオーバーヘッドが大きい。
  - でも、Non-BLUに負けてないんだからすごい。
データによって差が出るのでPoC重要

カラムナーDBの実装

本編最後のQAで非常に有意義なことを知ったのでメモ

行の再構成コストを削減するために、カラムナーDBはいろんな実装がある
- 行指向DBをマスターとして保持しつつ、アドホック・クエリー用に列指向DBを同時持ちする
- 1つずつではなく、複数の列をまとめて格納する
- BLUは1列ずつのデータしか保持しない
  - 今回の例は、行の再構成コストを払ってもお釣りが来るほど、I/O削減が効いているパターンだと思われる
  - 確かにDBによっては30倍の圧縮効率が出ていた。
カラムナーDBをOLTPに使うのはさすがに無理
- INSERT/DELETEまでは何とかなるがUPDATEが致命的
- UPDATE文を内部でDELETE/INSERTに置き換える実装をしているが、遅い
DB2 for z/OSにはBLUは提供されていない
- BLUの代わりにAnalytics Acceleratorがある
  - Analytics Accelerator：ｚの後ろにNetezzaをおいて、アドホック・クエリーをNettezaに自動でオフロードする仕組み
- 結局、CPU課金が大きいので、ｚ上のDB2で処理するBLUではなく、Netezzaにオフロードする方がメリットが大きい。

雑談

当然ながら2次会にも参加しました。永安さんの正面という一番美味しい席に座らせてもらって、楽しい＆有意義な時間を過ごさせてもらいました。楽しかった〜。
本編で、かなりの質問をさせていただいたのですが、2次会でも遠慮せず（失礼しました！）色々と質問させていただきました。
毎度のことながら終電の関係でお先に失礼しましたが、非常に楽しい＆有意義な時間でした。
でも、お酒の席の会話、半分ぐらい忘れちゃってる。。。もったいないので、次からはメモ持参で参加しようかな（笑）

その他のキーワード

検証結果を非公開（配布資料なし/UStreamなし）理由
- 前提条件を無視して、数字だけがひとり歩きしかねないので数字は公表しなかった
- 数字だけひとり歩きして嫌な思いをさせたくない
- 追試可能な状態にしてある。再現性がある
  - 関連資料Githubに公開（https://github.com/snaga/db2-blu-config）
最近の永安さんの肩書：チーフデータマエショリスト（笑）
- 一瞬、どんな肩書なのか真剣に考えてしまいました。

30日で検証準備からプレゼン準備を実施
- 最初にWBSを作成！

最後に

毎度のことではありますが、運営して頂いているClubDB2の皆さん、いつもありがとうございます。
また、お忙しい中検証結果をシェアしていただいた永安さん、ありがとうございました。
またまた、2次会でお会いした皆さんとも楽しい時間を過ごすことが出来ました。

2012-07-22

ClubDB2参加記録第146回達人が語るこんなデータベース設計は嫌だ（by ミックさん）に行ってきました。

club DB2

毎度毎度、久しぶりにClubDB2に参加してきました。
ここ半年ほど、第4金曜日に夜勤が入ることが多くなり、参加したくてもできないことが多かったのですが、今回は講演者がミックさんということで、夕方に1時間早上がりをする段取りまで付けて参加しました（笑）

ミック([twitter:@copinemickmack] / id:mickmack)さんについては、前回の登壇（Welcome to Wikis)で初めてお目にかかり、その後著書を2冊ほど読ませていただきました。
特に近著「達人に学ぶDB設計徹底指南書」については、非常に多くのグレーノウハウ、バッドノウハウ、「わかるわかる」と頷くノウハウから「えー！こんなのあり（笑）」といったノウハウを分かりやすく紹介していただき、気付ば毎朝30分ｘ5日ほどで読了してしまいました。2時間ちょっとで読み終わってしまうとは、高い買い物でした（笑）
今回の2次会でありがたくサインも頂き、現在は後輩の課題図書として貸出中です。
この本で、前チームの若者たちが少しでもピヨピヨを卒業してくれると嬉しいものです。

達人に学ぶDB設計徹底指南書初級者で終わりたくないあなたへ

作者: ミック
出版社/メーカー: 翔泳社
発売日: 2012/03/16
メディア: 単行本（ソフトカバー）
購入: 21人クリック: 316回
この商品を含むブログ (24件) を見る

閑話休題。
さて、今回のミックさんの公演ですが、サイジング方面からみたDB設計がテーマでした。
話は多岐に渡ったのですが、私自身考えさせられることが多かったテーマを中心にブログにまとめようと思います。

これだけは覚えて帰ってほしい３つのキーワード

ミックさんが「これだけは！」とおっしゃるキーワード。これはそのまま掲載して、このブログを読み返すたびに気付けるようにしたいと思います。

トレードオフ
- ハードウェアの進歩により大分変わってきたが，データベースの世界にはまだまだのこっている。
- データベースに求められる要求水準は青天井
  - これは主に性能要求に関することだったと思います。
手続き型の呪い
- ファイル≠テーブル
- 超重要。DBエンジニアの人生を変える（笑）
ストレージに触るものは不幸になる。
- 「ディスクに触ったら負けかと思ってる」

ミックさんの名言

前回の公演でも触れていたことなのですが、「ガリガリチューニングを頑張るよりH/Wを買うのが（多分）正しい」
特にSI案件ではこれがかなり難しいことなのですが、エンジニアとしてはかなり的を射ている言葉だと思います。先日、社内でこの考え方を話したら、参加者の皆さんが目からウロコが落ちる反応をしていました。コロンブスの卵ではあるのですが、このご時世、まさにそのとおりですよね。
具体的には、以下のような対処がこれに当たると思います。

メモリを積む
良いストレージ製品を買う
パーティショニングオプションを買う

ディスクに触ったら負け？

このキーワード、インフラエンジニアとしてもろに食いつきました。「そうなの？」って。
でも、世界の大部分のシステムであれば、たしかに、インフラレイヤーをDBエンジニアに意識させたらインフラエンジニアの負けですよね。制約があるなら、最初から設計して、「こういうふうに使ってね」って説明したいものです。
でも、ケースバイケースとはいえ、メインフレームの基幹システムの分野ではディスクの物理設計、パフォーマンスをちゃんと見られないとインフラエンジニアとしては不十分だと感じる事が多いです。（私もまだまだ勉強中の身ですが）

責任分界点という考え方

ミックさんが一例としてあげていた「ビュー ⇔ テーブル ⇔ ファイル ⇔ ストレージ」の責任分界点議論、
それぞれの責任分界点を以下のように分けていました。（アプリケーションエンジニア部分はkmasu追記部分）

ビュー：アプリケーションエンジニア
テーブル、ファイル：DBエンジニア
ストレージ：インフラエンジニア

この「責任分界点」とか「役割分担』という言葉って、往々にして誤解を生みやすい言葉ですよね。
私は、（誰に聞いたか忘れたのですが）「責任分担」という言葉が好きです。
一例を上げれば「インフラエンジニアとしてストレージに責任をもつなら、隣接するDBエンジニア領域を知らないと責任が持てないよね？」ということです。
ちょっと長くなるのですが、
「システム全体を考えれば、インフラエンジニアはストレージだけを見ていれば良いのではなくて、ストレージ観点でファイル（DBMS）側に入り込んでいかなければダメだし、DBエンジニアもストレージのことを勉強して、インフラエンジニアを使いこなさないといけない。あくまで、スペシャリティとしてどこまでをカバーするか、であって、隣接する分野の知識を持ち、その分野のスペシャリストを使いこなしてシステム全体を最適化するのがエンジニアとしての責務」だと思うんです。
このへんはid:megascusさんとほぼ同じ考えなのだと思いました。

酒井さんとの議論

2次会でちょっとだけ酒井さんと話をしたテーマです。
ここは後日まとめたいな〜。
検索キーがクラスターインデックスだったら、ループのほうが早いことがある？ってことを話しさせていただきました。

その他キーワードメモ

TPC-Cは「システム構築の現場では」参考にならない。超ハイスペックストレージを使っていてサイジング無視だから
シェアードナッシング　VS　シェアードディスク。パフォーマンスを出そうとすれば社アードナッシング型になるが、制約が大きい
- - （kmasu私見）結果として、使い方として制約をかけている（かけやすい）アプライアンスではシェアードナッシングが採用し易すく、採用されているのかな？
全部メモリに載せちまえ（笑）
- ディスクは限界。15,000rpmを超えられない → 伸び悩み → 他のH/W（CPUスピードやメモリサイズ）に置いて行かれる → ボトルネックになる
- トランザクションデータもメモリに載せちゃえ！
  - （kmasu私見）DB2 for z/OSでもそれやりたい！でも、メモリが高いしDB2の仕組み的にBP大きくするの危ないしなぁ・・・
32bit OSはだめよ！2Gの制約。オワコン

雑談

当然ながら2次会も参加しました。
毎度ながら、終電の関係でみなさんより少し早くお暇しましたが、非常に楽しい時間を過ごすことができました。

火消し会場から登場した（笑）ミックさんに、「障害対応は血沸き肉踊りますよね〜」っていったら、「ソルジャー症候群」だって言われちゃいました。いけないとは思いつつ、やっぱりそれはだめですよね(^^; でも、自分で火をつけるところまでは行っていない（はず）なので大丈夫です！

あと、PureScaleに話が及んだ瞬間の下佐粉さんの必死っぷりが楽しかったです（失礼！）でも、私もあそこは話したくてうずうずしました。「CFやCF Linkが高速で、ほぼダイレクトメモリアクセスだから、ロック制御や更新データ制御もボトルネックにならない！（なりにくいんです！）」って。

そうそう、「「魂に重量を引かれている」的なあれ」ってところ、思ったより会場の反応が鈍かったなぁ。自分的には一番面白かったです。

最後に

最後に、講演していただいたミックさん、いつも楽しい会を主催してくださっているClubDB2のみなさん、またLTに登場されたid:jfluteさん、本当に楽しい会をありがとうございました。
DBFluteについてはまた時間を見つけてブログにまとめようと思います。（そろそろ隣の部屋の相方の視線が痛い〜（笑））

当日のTweetから一分を記録

相変わらず[twitter:@Bizuayeu]さんのtweetは分かりやすくまとまっていてありがたいです。

講演者、他の参加者のブログのリンク

一部はトラックバックURLがわからなかったので、リンクのみです。

Club DB2 でゲスト講師をしました - ミックのブログ
 #clubdb2 ミックさんゲスト「達人が語るこんなデータベース設計はヤダ！」は大盛況でした | Unofficial DB2 BLOG
2012-07-14
ClubDB2で5分だけDBFluteしゃべりました - jfluteの日記
 「達人が語るこんなデータベース設計はヤダ！」へ参加してきました - 虎塚

2012-06-23

Excel列名変換問題を解いてみた。

IT perl

Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編) - give IT a tryにたまたまたどり着いて、「そういえば最近Perl使っていないな（というかコード書いていないな）」と思ったので、まずは問題1に挑戦してみた。

問題1: Excel列名変換問題

    仕様
        入力されたアルファベットを数字に変換する。
        変換ルールはExcelの列名と同等。
        例) A=1、B=2、Z=26、AA=27、XFD=16384

    起動時引数
        [0] アルファベット (A〜ZZZZ...[上限なし])*2

    実行例
        ExcelColConv.pl A → 1
        ExcelColConv.pl AA → 27

思考ロジックを整理しておくと

A〜Zを取り扱うので、要は26進数の10進数変換。
A〜Zを1〜26にどうやって変換するか？
- 文字コード変換を活用するとすっきりしたコードになりそう。だけど、大学生の時（1x年前）に川崎くんに実装の考え方を聞いただけで、コードを見たことも書いたこともないので、調べないとダメそう。
- あまりに久しぶりのPerlなので、文法とか調べていたらハッシュ型の変数なるものを発見。これは便利そう。
Perlでべき乗の演算子しらないな〜、と思って調べた。

で、作ったコードが以下。

my @val_array;
my $val_sum = 0;
my %hash;
%hash = (a => 1,b => 2,c => 3,d => 4,e => 5,f => 6,g => 7,h => 8,i => 9, j => 10,k => 11,l => 12,m => 13,n => 14,o => 15,p => 16,q => 17,r => 18,s => 19,t => 20,u => 21,v => 22,w => 23,x => 24,y => 25,z => 26);

my $input  = $ARGV[0];
my $len = length( $input );

# 入力文字列の順を逆にする
for ( my $i = 0 ; $i < $len ; $i++){
	$val_array[ $i ] = substr( $input , $len - $i - 1 , 1 );
}

#1桁ずつ26進数として処理
for ( my $j = 0 ; $j < $len ; $j++){
    my $conved_val = $hash { $val_array [ $j ] } ;
	$val_sum = $val_sum + ( $conved_val * (26 ** $j)) ; 
}

print "value : $val_sum \n";

ここまで作って答え合わせ。
Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編) - give IT a tryの答え（上位3作品）を見ると、

第1位：ハッシュ変数による変換。但し、ループが1回
第2位：文字コード変化を活用した変換。

そうそう、こうやってみたかったんですが、ordっていう関数があるんですね。で、Aのアスキーコードが65だから、64引くと。ちょっと調べたら、文字コードから文字にするにはchar関数を使えば良いようです。これは第2問に使えそうです。

    # Convert A-Z to a number
    my $ascii_code = ord($columns[$i]);
    # subtract 64 (to convert A to 1 B to 2 etc)
    my $value = $ascii_code - 64;

久しぶりにPerlの基礎を確認するのに便利だったページをいくつかメモしておく。

Perl入門ゼミ
特にこのページ

後は、MacでPerlを使う際の注意点。UnicodeとかCR改行コードでハマるとは思いませんでした。
http://d.hatena.ne.jp/hornistyf/20080421/1211981662