久しぶり

 久しぶりにブログを更新する。色々あったけど、Microsoft365を解約してドメインの退避先がなくなって一旦こちらに。

退避するにあたってDNSの設定を変えたけどムームードメインのDNSせっていが非常にわかりにくかったのでこちらに記録。

・MXレコード などで「@アットマーク」が使えなくて空白でいいことがわかるまで時間がかかった。

・SPFレコードで「"ダブルクォート」が不要だった。

 

結局、ヘルプデスクに聞いたけど、今やAIが返答してくれる。正確だし親切だしそういう時代なんだなあ。

クラウド時代のミドルウェア構成について（考え方の転換）

プロジェクトで色々経験して、最近思うことがあったので記録する。
また親しい人にもアドバイスを受けた。

今やっているプロジェクトは基幹系システムを刷新して、クラウド上に載せ替えるというものである。基本的には業務要件はAS ISのままで、それをクラウドに載せ替えるというものである。むろん汎用機からオープン系のシステムかわるので、言語が変わったり、アプリケーションサーバーとDBサーバーという今時の構成への変更はある。

自分の担当は、夜間バッチの部分で基本的にはJavaで作ることになる。

この夜間バッチが相当曲者で、これをJavaでやるとなると

1. DBからデータを持ってくる
2. データを加工する
3. データをDBにもどす

という順番の処理になる。汎用機時代はフラットファイルなので、夜間バッチには相当強くて、100万件だろうが200万件だろうが平気で処理を行う。一方オンライン処理には、それほど強く無いのではと想像する（今の時代のオンラインのトランザクション量は半端ないので、まえの現場は秒間200トランとか、、SNSとかスマホゲームはもっと多いだろう）

夜間バッチだと、30万件でもいま結構苦労している。（計算上で）

本当ならストアドプロシージャでやりたいのだが諸般の事情でそれはできない。

記録しておきたいことは、そんなことではなくて（関係なくはないが）、今まで自分はマイクロサービスというものに否定的であった。しかし現プロジェクトでいろいろ経験することで考えを改めることに至った。またアーキテクチャについても思うところがあった。

今のプロジェクトは、クラウドに乗せるといっても、基本的にはクラウド前のオープン系のアーキテクチャをそのまま踏襲している。

よってサーバーのインスタンスをクラウド上にいくつか立てて、それぞれをアプリケーションサーバーにしたり、DBサーバーにしたりしている。なので詳しいことは聞いていいが、アプリケーションサーバー間のロードバランスの仕組みを導入したり、DBサーバーをHOT-COLD構成にしたりしている。

当初はこれに疑問を持っていなかった。

しかしクラウドの利点の一つは、「スケーラブル」なことである。ロードバランスの仕組みや、DBの対障害性もクラウド側が機能としてもっている。

またクラウドの課金は、CPUの動いた時間である。（認識間違っていないかな？）

いまのお客様は、オンライン処理はそれほどでもなくて、夜間処理が非常にきつい。

しかしアプリケーションサーバーは、24時間動いている。すかすかの昼間も着実に課金されている。DBもHOT-COLD構成だが、COLD側もOSレベルでは動いているはずなので課金されることになる。

よって、クラウドにシステムを乗せるときは、できるだけ夜間バッチという考え方を捨てるべきとの考えに至った（そういうアドバイスを先輩にも受けた）

つまりできる限りCPUを効率的に使うため、

夜間バッチで行う処理は、マイクロ（でなくてもいいが）サービスで、バックグラウンドで個々のトランザクションで処理する。（集計できる形にまで、一気にオンラインで持っていって、集計とかだけ夜にする）

また少なくともDBサーバーを個々に立てるという考えも捨てるべきとおもったCOLD分のリソースがもったいない。クラウド側が持っているDBのサービス（Amazon RDSとか分散処理や、スケーラビリティもクラウド側が保証してくれる）を使うべきと思う。

本当にミッションクリティカルなシステムだけクラウド側の保証を超えて、独自の耐障害性の仕組みをADDするべきと考えた。

以上が記録したいことになる。過去の経験だけにすがって考え方の転換を図らないとすぐに知識は陳腐化するといういい経験になったと思う。

※ちなみに単純に仕組みを考えると単一の処理で200万回インサート文を投げることになるので、うまいこと考えないとと騒いでいたら。汎用機しか知らない人に、「200万件レコード追加するだけでしょ。そんなのなんでしんどいの？」と言われた。

レコード数６億件（RDBMS）

とあるシステムの設計をしていて、毎日30万件以上、月1000万件、年間１億２千万件、と試算した。少なくは無いがものすごく多いとも思わない。
５年分くらいはデータを保持したいので、６億件１テーブルに保持したいといったら、基盤チームからやめてくれと懇願されました。1レコードはそんなに大きくはないので1kバイトないくらい。仮に1kバイトとして、5年で大体600Gくらいかな。別にかまわないと思うのだけど。
6億件全体をこねこねすることもないのでパフォーマンスも問題ない。Insertもパーティショニングをつかえば問題ないと思います。
世の中的には、どうなんでしょうか？

AIの活用が今後増えていくと思いますが、そういった素データの保持が重要な気がします。今回のケースは本当に保持が必要か再検討しますが、600Gぐらいでうろたえるなと思いました。

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を思い出してみたい。