データベース系技術者として仕事に携わると、単にSQLだけでは解決できない事、或いはSQLで解決は出来るものの、圧倒的にパフォーマンスが落ちる経験は、暇に尽きないですね。
■最近のDBデータの特徴
一部金融系ではバイナリーデータが残っているものの、それ以外では殆どのデータはnumuric、varchar2、char、date、timestampと言った「実数或いは文字列化」されたデータを扱う事が多くなってきたのではないでしょうか。
■DB内でデータをやり取りする分にはSQLが有効だけど…
多くのDB経験者は、DB内で全て完結させたい!って思ってるかと。
その象徴が、PL/SQLを代表とする、ストアドプロシージャーでしょう。
1トランザクションで色々な事が実行できるメリットは、計り知れません。
しかし、それはそれで良いのですが。
「それだけでは」と、
現場でその考えは見事に打ち砕かれます。
そう。
大抵のシステムは、DBサーバー間、或いはシステム間の通信を強制されますね。
まあ、当然です。
■DB間・システム間をつなぐのは結局「ファイル」
今のところ、DB間を事実上シームレスにつなぐシステムは、部分的にはあるものの。
殆どの場合は、DB⇒ファイル出力⇒転送⇒DB格納と言う流れ。
そこには
・DBの出力仕様
・各システム事の設計思想の違い
・文字コード
‥があるわけで。
送ったー受け取ったーじゃ、入れるね⇒できなかった
ってのは頻繁にある事です苦笑(本当に残念ながら
■そこでデータ修正をする手軽で優秀な言語
・速度
・開発の手軽さ
・想定データ量
・変換に適したプログラミング言語
と言ったさまざまな要因が求められる中で。
最近はawkがお気に入り。
これはバイナリを扱わない限りは本当にいい。
スクリプト系の中でも一番と言ってよいほど速い。
且つ、スクリプト系の手軽さも兼ね備えて。。。
何より、DBデータの処理と相性がいい。
DB技術者ならば、awkは覚えて損はない。
古い言語だけど、今さらその便利さに気が付いた。
■大量データ処理をLinuxで行った経験
まあ…言わずとも知ってる人が多いと思う。
超鈍足⇒shell
~~~超えられない山
まあまあ
・awk、gawk
・perl
・python
など
~~~越えられない山(なんだかんだ、スクリプト言語はコンパイル言語を超えられない)
・C、C++
・java
・Fortran
等
ただし、中にはJavaScriptやnode.jsみたいな例外的に、コンパイル言語に肉薄する(勝てないけど)ってのもあるらしい。
■どの言語も「扱うデータ量なりに選ぶのが肝心」
遅い言語でも、データ量が少なければ、問題にならない。
問題なのは、処理量なのだ。