ささややかなビッグデータ

300万件や5000万件のデータで四苦八苦していたあの頃は何なんだろうと思う。10万件のデータをExcelに落として65536件に入りませんと新入社員の頃、言ってたのは何だったのか。

目の前には5億件のデータが簡単に入っており、いとも簡単に扱うことができる。

5億件のデータを1分で3件正しいかを判断するコツを人間が掴んだとしても、24時間（1日で4320件しか見れない。全部見るのに115740日、約317年間だ。人で言えば、3～4世代、引き継がれる。
でもSQL文だと5分以内で戻ってくる。

そして、これをシュミレーションをする為に30倍、40倍のデータにしている訳であるが、これも、あっという間にできてしまった。。。。家に帰って、朝起きてトーストを食べている間に。

200億件。

このデータの正しさは何なのか？

200億件とわかるのは、count文を発行したからである。決して目で見たわけではない。
金額の合計・平均がわかるのは、sum文、avg文を発行して、コンピューターが返してくれるからである。決して200億件、すべて足して、件数で割った訳ではない。

そんなデータがいとも簡単に手元で扱えるようになったことにに、素晴らしいさと若干恐れも感じる今日この頃である。

各社の買収された製品に思うこと

大手のメーカー、ソフトウェアベンダーが買収を続けているが、それらを使ってみて感じることは、どんどん品質としてはバラツキがでてきていて、無秩序な状態になっているなと感じる。以前は、各社とも、一定の品質があった。品質を語るには、あまりに自分には知識はないが、たとえば、マーケットからは見えずらいが、アーキテクチャ・デザインをした際のソフトウェアの柔軟性、長く使っていく為に必要な製品自体の性能、状態をモニタリング、評価できる機能、コアダンプへの出力内容、保守時における手順のやりやすさ、など、あまりビジネスに関係ないところにおいても、一定の配慮がされていた。不足している製品があっても、それに追いつこうとする意志を感じられた。

しかし、今やマーケットやその製品ビジネスバリューで、あまりにもたくさん買って、製品毎のマーケット別ポートフォリオは存在しているのだが、そこまでかなという感じだ。

なんとなく良さそうなのだが、実際の業務で使ってみると、不備が多々、見受けられるパターンがある。その時、今までの製品は、あれだけの品質を保っているのに、なぜなんだろうと、当然ながらの質問を購入者は思う。

一方、ベンダー側も、一定の品質に保とうと一定の努力はしているのだが、決定的に大事だった技術者が辞めてしまったり、マーケットとしての価値が下がったりして品質改善のコストは少額になったりして、買収された製品の中でも当然ながら、バラツキが出てくる。

うーん。まあ、使える製品、使えない製品として統廃合されていくことは正しいが、今後も延々とこの繰り返しなんだろうなと思うと、これって一体何なのかなー、と思うことが多い。

例えはいいか別として、水や電気やガスのインフラは、一定の品質を保っている。ここは、崩れてはダメな部分だ。崩れないように、日々、保守を実施している。ソフトウェアも同様だ。ただ、ソフトウェアは進化し続けている。その中で一定の品質の安定さが欲しいと思うことが多い。
まあ、銀行やその他、数多くのシステムが一定の正常さで動いているわけ（このブログもそうだし）であり、それを一定の安定さと受け止めればいいわけであるが、決定的に、建築や水やガスとは異なるものだということは、その中にいるものとしては思う。

nzload memo②

①外部表形式でのロードと実はスピードが変わらないとブログで報告している人は、英語系では多数。本当か、検証してみる必要あり。ただ、インターフェースファイルが多いと外部表定義も多くなるので、それは管理がめんどくさい。外部表自体を動的に都度作成・削除することも可能だと思うが、GROOMの処理との関連が気になる。

②営業資料は結構なスピードでの資料になっているが、結局はロード元（ファイル格納場所）のストレージの性能がパフォーマンスに大きく関わる。Netezza内には通常ファイルは格納できないので、別途通常のストレージに置いてからのロードになる。

Netezza Tool Aginity

NetezzaへSQL DeveloperやSI Object BrowserやPL/SQL　Developerのようにアクセスするクライントツールである。使いづらいところもあるが、それなりに使える。フリーツールであるが、ユーザー登録は必要。ライセンスが登録したメールに送られてくる。

http://www.aginity.com/workbench/netezza/

後は、付属しているAdministorator Toolかな。

netezza _V_RELATION_COLUMN

_V_RELATION_COLUMNは、テーブル内の利用可能な列の情報を参照可能。DB、スキーマ別のテーブル名、列名、型を参照可能。

単体テストのと結合テストの異常系テスト内容について

単体テスト（UT/PT)の異常系テスト内容と結合テスト（サブシステム内）の異常系テスト内容は、結局何が異なるのか？　とクライントから指摘されたことがある。
結局は、同レベルのことしかできないのではないか？、という内容である。この発言は、UT/PTの中でモジュール単位のテストとプログラム単位のテストの2つのテストを実施していることが前提となっている。つまり、PTの中で、ある程度結合してテストをしていて、その単位がIT(サブシステム内）の機能単位とあまり変わらない為である。

実際に実施してみると、運用ツールとしてSkyWalk（ジョブ・ツール)で実施して、UT/PTと同様のエラーケースを実施したりと、あまり意味がないよね、運用ツールを使って動かしたことが唯一のテストかーみたいな話になる。

かと言って、障害リカバリーを見据えたテストをしたいが、そこまで品質が追いついていない。

netezza _v_dual

OracleのDUALと同じ扱いのNetezzaのViewは、下記だと思う。





In Netezza:
select current_date from _v_dual;

nzload memo①

Netezzaのnzloadの検証をして、わかった点を下記に記す。OracleやDB2のLoader機能と同一の機能を期待していると、痛い目に合う。適切な時期に簡単な技術検証をしておくべきである。

① オラクルのCTLファイルと同様、制御ファイルの考え方はあるが、使えるものではない。単純にスキーマやDB、ロードテーブル、コマンド・オプションの記述等の指定ができるだけである。致命的なケースとしては、ファイル内容に合わせて列指定におけるロードができない点。固定長ファイルでないと列指定はできない。

② 日付やタイムスタンプをロード時にデフォルトで挿入することはできない。オラクルならば、制御ファイルの中で、項目名 DEFAULT SYSDATEでロード時の処理タイムスタンプ等を格納できるが、Netezzaではできない。

③ ファイル・デリミタ、日付デリミタ等は可能。日付の形式も指定可能。エラーの最大許容件数の指定、ログの出力先の変更も可能。固定長ファイル形式はそれなりに使える。