Teradata

Teradataの実行計画(1) - 大量データの結合の計画

Teradataの実行計画について少しずつ整理していきます。 今回は大量データの結合の実行計画について。 こんなクエリは、どういう実行計画になっていればOKだろうか。 select * from t /* 1000万件のトランザクション */ inner join m /* マスタ */ on m.c1=t…

Teradata SQLパフォーマンス改善Tips(2) - not in で比較する列にはnot null制約を付ける

こんなSQLでパフォーマンスが出ない場合、 SELECT * FROM t1 WHERE c1 NOT IN ( SELECT c1 FROM t2 )not inで比較してる列=t1.c1, t2.c1 にnot null制約が付いているか確認してみるといい。 もしもc1にnullがあり得ないにもかかわらず、not null制約が抜け…

Teradata SQLパフォーマンス改善Tips(1) - PIを使って結合する

Teradataは、Primary Index(PI)を結合カラムにしたときに結合が最速になる、とマニュアルに書いてある。 以下はこの性質を使ってパフォーマンス改善した事例。 夜間バッチの時間短縮のため、時間のかかっているジョブをチェックしてみると、こんな結合条件の…

Teradataは単一テーブルから全件返すときもスプールを使う

Teradataで3000万件ぐらいのテーブルをただ全件引いてみると、 select * from t /* 3000万件 */しばらくだんまりになった後で、猛然と結果が返ってくる。 このだんまりの時間に何をしているのかexplainで調べてみると、 3) We do an all-AMPs RETRIEVE step …

Teradataはselect句が返す列数を減らすと速くなる

Teradataで3本以上のテーブルを結合する場合、必ず中間結果のスプールへの(つまりディスクへの)書き出しが発生する。 例えばa, b, cの3本を結合するなら、aとbの結合結果をスプールに書いて、次にスプールとcを結合する。 b, cが件数の非常に少ないテーブル…

Primary Indexは一意に近いほどよい、わけではない

Teradataはいわゆるshared-nothingアーキテクチャを採用していて、1つのテーブルのデータは、AMPと呼ばれる数十台の仮想マシンに分散して格納される。 Teradataは各レコードのキーすなわちPrimary Index(=PI)をハッシュ関数に食わせて、出てきた値からそのレ…

Teradataの待ち行列の捌き方・readロックがreadロックを排他しているように見える現象

Teradataでは、readロックがwriteロックを排他する。 つまり、あるテーブルの読み取りのみ行うトランザクションAを実行中に、そのテーブルを更新するトランザクションBを開始すると、更新トランザクションBは、Aがreadロックを解放するまで待ちになる。 ここ…

WebサイトのバックエンドにTeradataを採用するプロジェクト

けっこう大きなWebサイトの構成立案に弊社が参加していて、バックエンドのDBの選定などがウチ担当になっている。 高速なDBが必要ということで、営業サイドはTeradataを推す案を作っている。 高速なDB -> じゃあTeradataで、という感じなのだが、アプリの実装…

同一テーブルに対してinsertする2つのトランザクションがデッドロックした

Teradataで、あるテーブルに対して複数行insertするジョブを並行して走らせたところ、デッドロックしてしまった。 Teradataの場合、insertのデフォルトのロックはテーブルロックだと思っていたのだがこれが間違いで、実は行ハッシュロックというのが掛けられ…