RDBMSの機能と活用について

自分は、とある場所で勉強会を月１回主催しています。毎回色々なテーマで勉強をするのですが、その中で思ったことがあります。

アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。

今自分が直面している課題は、

何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。

要件はたったそれだけなのですが、実現にはいくつかのやり方があります。

パターン１　データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）

パターン２　データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）

パターン３　SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）

パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。

現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）

今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）

また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。

それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。

よって、今年の目標は、RDBMSを極めることとした。

2016年振り返りと2017年目標と予測

久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。

2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。

さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。

人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。

2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）

とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）

自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？

ExcelのCSVの取り扱いについて（苦労した）

テストデータを作っていて、苦労したので記録しておく。

バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）

”ABC","¥123,456","XYZ"

みたいな形。

このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。

ABC,"¥123,456",XYZ

つまり

1. 勝手にダブルクォートを削除する。
2. 全部削除ならまだ統一感があるが、データ内にカンマ「,」が含まれているとその列のダブルクォートは残す。

テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。

小さな親切、大きなお世話だ。

MariaDBについて勉強した

久しぶりに勉強したシリーズ。
といっても前から存在は知っていて最近ちょっと使い始めたところ。MySQLは、オープンソースのデータベースとしてよく知られているが、サン・マイクロシステムズが、オラクルに買収されてしまったため、元々のMySQLの開発者が将来に懸念を抱き（オラクルは、オープンソースを潰すことで有名だ）、ソースコードをフォークして作ったRDBMSだ。

MySQLとAPIの互換性があり、ドライバなどはほぼそのまま使える。
オラクルだと有償の機能（スレッドプール）が、タダで使える。

互換性を意識しつつ、より良い機能という方針で開発が進んできたが、バージョンが上がるにつれて、だんだんと本家MySQLと機能差がでてきたようではある。

なぜMariaDBを勉強したかというと、再度RDBMSを勉強し直し、DOA（データオリエンテッドアプローチ）、データモデリングを勉強し直したいと思ったからだ。商用のデータベースにお金を払うほどお金持ちでは無いので、取りあえずオープンソースでと思った次第。取りあえずリレーショナルシップだけ実現できればと思って、調べ始めたが驚いた。

参照整合性制約
ストアドプロシージャ
トリガ
チェック制約
ドメイン（カラムに色々と制約を仕込むことができる）

などなど
普通に使いそうな機能は一通りあった。
20年前くらいにORACLE7.3を使っていたが、もうとっくにその機能は超えているのだろう。ガンガン使ってみてDOAを思い出してみたい。

IT開発におけるパフォーマンス問題について

最近また業務システムの設計をするようになった。
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか？それとも自分の考え方が間違っているのだろうか？確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか？

IT開発プロジェクにおける計画外のタスクについて

また、みずほ銀行の基幹システム開発が話題になっている。本当か嘘かわからないが、工数の９割が進捗会議についやされているという噂を見た。また進捗会議にむけての会議もあるらしい。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。

ITプロジェクトで失敗した時

当たり前のことだけれども人間だれしも失敗をする。その時どのような心持ちでいれば良かったかを書いてみたいと思う。なぜこのとこを書こうかと思ったかと言えば、最近自分はプロジェクトで小さな失敗をした。（正確に言うと失敗をしたかも知れないと思い込んでビクビクしていた）その時に冷静に考えて、なんで自分はこんなにビクビクするんだろうと振り返ってみた。
過去自分はプロジェクトの激務で体調を崩し、長期にわたって休んでしまったことがある。それは失敗をリカバリーしようとして激務に激務を重ねて結果的に体調を崩してしまった。
（もとからそのプロジェクトは失敗していたが、リカバリーせよとの指示を受けてプロジェクトに入った）
その時のトラウマがあるのだろうと思う。その時の自分は委任契約で大手ITベンダーに雇われていた。それなりに高給の契約ではあったが、契約上はプロジェクトの成否に一切責任のない立場のはずであった。
しかし実態はユーザーさんから毎日毎日「どうなっているんだ！怒」と責められ、どなられる毎日であった。しまいには「お前のせいでこれこれの金額分の損失を被った。どう賠償してくれるんだ！」と言われた。ベンダーのPMに相談したがなにもしてくれなかった。
また同じ立場であるはずの協力会社の人も責めてしまった。「なんでできないんだ！」とか「どうしてこうなった」と言ってしまった。
結局のところ「火中の栗を拾う」とは聞こえが良いが、「本当」の責任者は責任をとらず、委任契約である自分に便宜上責任を押し付けたのだった。
その時の自分は「プロジェクトを救う！」といった今考えると意味の無い義侠心にかられて、仲間を責め、自分を責め、プライベートもすてて頑張ったが、個人の力では限界もあり潰れてしまった。
委任契約で個人が受けるペナルティーは、契約を打ち切られる以外にはなく、責められるいわれもないはずである。
通常は契約の継続は生活の安定とリンクしているので、ついつい無理をしてしまいがちになる。とことん追い詰められると最後は「死」を意識してしまうまでになるが、サラリーマンと違って労災は降りない。残業代も契約上明記がなければ請求権はない。
なので心の安定を図る為、いつでも契約を打ち切られる（こちらから打ち切る）ことを念頭において仕事をしている。「信頼している」と言われてもその人は99%生涯の面倒は見てくれない。どころか半年先の約束でさえ平気で破る。なので戦国時代の武将では無いが、常に死地にあることを意識していれば、おのずと飄々と「責任逃れ」ができる。責任はないので責任逃れという言葉はおかしいが。
冒頭に書いたビクビクしてしまった理由は、昔の記憶が少し残っていたからだろうと思う。なので、何かあったらこのブログを見直して、これからも飄々とプロジェクトに関わることができればと思う。
委任契約の関係は、切るか切られるかしかないのだから。