読者です 読者をやめる 読者になる 読者になる

SQL (1)

最近ついに SQL を使い始めました.
というのも本業の方では Fortran の Unformatted で Direct Access なレコードファイル*1C++ でガリガリと直接読み込んでは,カット条件*2を変えてデータ出力といった日々なわけですが,生データに対する最初のラフカットぐらいは,SQL を使って Server 内で最適化なり並列処理なりをやってもらった方が効率が良いに違いないと常々感じておりました.また一次データを RDBMS 内に格納することで,ファイル I/O の制限や環境依存性から解放されるというメリットもあります*3.現在私が主に利用しているフレームワークは次の 3 つですが,幸いこれらはいずれも SQL 経由でのデータ I/O のライブラリが用意されています.うまく結合できるといいのですが……

というわけで,クエリアナライザの推定実行プランを見ては「すげー」と感動する今日この頃です.これまで一生懸命ループから書きおこしていたのが抽出条件を記述するだけでよくて,後は自動的に複数の実行プランが作成され,実行時パラメータを考慮して最適なものを選択してくれます.楽ですねぇ.多くのプログラマが,この「楽になった」と思える瞬間に大なり小なり身体を蝕まれているんじゃないかと思います.麻薬のように.
まあなんにせよ,今後 multi-core CPU の普及も予想されるわけで,具体的な手続きの記述を極力廃した言語で実行時最適化を期待するか,あるいは最初から環境を決め打ちして手続きレベルの最適解を(環境ごとに)用意するか.どちらの手法も必要に応じて使い分けられるよう準備をしておきたいですね.

*1:メモリ上のバイナリ表現をそのまま出力し,ランダムアクセス可能なファイル形式.そういえば N88 BASIC のころもレコード単位のファイルアクセスとかやってたような記憶が……

*2:実験で得られた一次データには由来の異なるイベントが混ざっているため,興味のある事象以外はノイズとして除去してデータの質を向上させます.このためにパラメータ空間に色々な条件をもうけてイベントの選別を行います.これをカットと呼んでいます.

*3:正直,2GB や4GB のファイルサイズ制限とか,gzip 圧縮されたファイルを pipe 経由で読み込むせいで seek 不可能とかからさっさと解放されたいです