私はＩＴ系・金融系の中でも、比較的にデータベースに強い。
元々はプログラミング言語特化だったのだが、今はデータベース系エンジニアとしての性格が強い。
(だからこそ、金融系ITerとして活躍できるのだが)
画像は以下から転用
https://gihyo.jp/dev/serial/01/redshift/0001
列思考DB、行思考DBの違い。
今はRedshiftをメインで扱っている。
Oracle、DB2、PostgreSQL、MySQLなどと違い、いわゆる列思考（カラムナー型）のDBの特徴なのか、相当にクセがある。
致命的なのは、Insertが遅い…どうしようもないぐらいに遅い。
従って、大量データを投入する場合には、insertではなくloadする事になる。
これは、既存のDBでもinsertよりもloadした方が速いのは一般的に知られているが「遅さ」がまるで違うのだ。
尚、Oracleに代表されるDBがinsertよりもloadの方が速い理由は、はっきりしている。
loadユーティリティを使う場合は、行挿入の都度indexを最適化しないのが大きな理由。
(indexを手動で外す、もしくは自動でindexを外しデータ挿入後にindexを再構築する)
だが、redshiftの遅延の原因はどうもそういう事ではないらしい…原因はもっと調べないとなぁ…。
とはいえ、現在は
oracleにデータ投入、S3経由でredshiftへデータ移行という、非常に迂遠な方法を取っているので、ちょっとした操作を頻繁に行う際には面倒くさくて仕方が無い。
S3経由せずに、copyコマンドで直接LOADしようとするとエラーになってしまうし…（環境の問題か？）
そこで、insertを少し考え直してみようと思う。
要するに、insertを大量発行するから悪いのかもしれない。
insert into aaa (a,b,c,d,e) values (1,1,1,1,1);
insert into aaa (a,b,c,d,e) values (2,2,2,2,2);
insert into aaa (a,b,c,d,e) values (3,3,3,3,3);
と、やらずに。
insert into aaa (a,b,c,d,e) values
(1,1,1,1,1),
(2,2,2,2,2),
(3,3,3,3,3)
とやれば、トランザクションは1回しか発生しないので早くなる説。
早速試してみよう