とあるシステムの設計をしていて、毎日30万件以上、月1000万件、年間１億２千万件、と試算した。少なくは無いがものすごく多いとも思わない。
５年分くらいはデータを保持したいので、６億件１テーブルに保持したいといったら、基盤チームからやめてくれと懇願されました。1レコードはそんなに大きくはないので1kバイトないくらい。仮に1kバイトとして、5年で大体600Gくらいかな。別にかまわないと思うのだけど。
6億件全体をこねこねすることもないのでパフォーマンスも問題ない。Insertもパーティショニングをつかえば問題ないと思います。
世の中的には、どうなんでしょうか？
AIの活用が今後増えていくと思いますが、そういった素データの保持が重要な気がします。今回のケースは本当に保持が必要か再検討しますが、600Gぐらいでうろたえるなと思いました。
2017年3月5日日曜日
2017年1月21日土曜日
RDBMSの機能と活用について
自分は、とある場所で勉強会を月１回主催しています。毎回色々なテーマで勉強をするのですが、その中で思ったことがあります。
アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。
今自分が直面している課題は、
何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。
要件はたったそれだけなのですが、実現にはいくつかのやり方があります。
パターン１ データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）
パターン２ データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）
パターン３ SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）
パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。
現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）
今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）
また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。
それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。
よって、今年の目標は、RDBMSを極めることとした。
アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。
今自分が直面している課題は、
何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。
要件はたったそれだけなのですが、実現にはいくつかのやり方があります。
パターン１ データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）
パターン２ データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）
パターン３ SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）
パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。
現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）
今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）
また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。
それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。
よって、今年の目標は、RDBMSを極めることとした。
2017年1月9日月曜日
2016年振り返りと2017年目標と予測
久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。
2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。
さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。
人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。
2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）
とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）
自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？
2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。
さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。
人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。
2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）
とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）
自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？
2016年12月4日日曜日
ExcelのCSVの取り扱いについて（苦労した）
テストデータを作っていて、苦労したので記録しておく。
バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）
”ABC","¥123,456","XYZ"
みたいな形。
このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。
ABC,"¥123,456",XYZ
つまり
バージョンはExcel2010だった。
データはCSVで数行のデータをコピペして、ところどころ値を変えて１万行くらいに増殖させようとしていた。CSVなので下記のような形。
（CSVにもいろいろ方言はあるが）
”ABC","¥123,456","XYZ"
みたいな形。
このCSVをExcelで編集して「CSV」形式で保存しても勝手に下記のような形式に変換される。
ABC,"¥123,456",XYZ
つまり
- 勝手にダブルクォートを削除する。
- 全部削除ならまだ統一感があるが、データ内にカンマ「,」が含まれているとその列のダブルクォートは残す。
テストデータとしては、全部ダブルクォートで囲みたいので、sedで編集した。
小さな親切、大きなお世話だ。
2016年11月25日金曜日
MariaDBについて勉強した
久しぶりに勉強したシリーズ。
といっても前から存在は知っていて最近ちょっと使い始めたところ。MySQLは、オープンソースのデータベースとしてよく知られているが、サン・マイクロシステムズが、オラクルに買収されてしまったため、元々のMySQLの開発者が将来に懸念を抱き（オラクルは、オープンソースを潰すことで有名だ）、ソースコードをフォークして作ったRDBMSだ。
MySQLとAPIの互換性があり、ドライバなどはほぼそのまま使える。
オラクルだと有償の機能（スレッドプール）が、タダで使える。
互換性を意識しつつ、より良い機能という方針で開発が進んできたが、バージョンが上がるにつれて、だんだんと本家MySQLと機能差がでてきたようではある。
なぜMariaDBを勉強したかというと、再度RDBMSを勉強し直し、DOA（データオリエンテッドアプローチ）、データモデリングを勉強し直したいと思ったからだ。商用のデータベースにお金を払うほどお金持ちでは無いので、取りあえずオープンソースでと思った次第。取りあえずリレーショナルシップだけ実現できればと思って、調べ始めたが驚いた。
参照整合性制約
ストアドプロシージャ
トリガ
チェック制約
ドメイン（カラムに色々と制約を仕込むことができる）
などなど
普通に使いそうな機能は一通りあった。
20年前くらいにORACLE7.3を使っていたが、もうとっくにその機能は超えているのだろう。ガンガン使ってみてDOAを思い出してみたい。
といっても前から存在は知っていて最近ちょっと使い始めたところ。MySQLは、オープンソースのデータベースとしてよく知られているが、サン・マイクロシステムズが、オラクルに買収されてしまったため、元々のMySQLの開発者が将来に懸念を抱き（オラクルは、オープンソースを潰すことで有名だ）、ソースコードをフォークして作ったRDBMSだ。
MySQLとAPIの互換性があり、ドライバなどはほぼそのまま使える。
オラクルだと有償の機能（スレッドプール）が、タダで使える。
互換性を意識しつつ、より良い機能という方針で開発が進んできたが、バージョンが上がるにつれて、だんだんと本家MySQLと機能差がでてきたようではある。
なぜMariaDBを勉強したかというと、再度RDBMSを勉強し直し、DOA（データオリエンテッドアプローチ）、データモデリングを勉強し直したいと思ったからだ。商用のデータベースにお金を払うほどお金持ちでは無いので、取りあえずオープンソースでと思った次第。取りあえずリレーショナルシップだけ実現できればと思って、調べ始めたが驚いた。
参照整合性制約
ストアドプロシージャ
トリガ
チェック制約
ドメイン（カラムに色々と制約を仕込むことができる）
などなど
普通に使いそうな機能は一通りあった。
20年前くらいにORACLE7.3を使っていたが、もうとっくにその機能は超えているのだろう。ガンガン使ってみてDOAを思い出してみたい。
2016年11月19日土曜日
IT開発におけるパフォーマンス問題について
最近また業務システムの設計をするようになった。
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか？それとも自分の考え方が間違っているのだろうか？確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか？
その時に、それまでの旧システムを維持・管理している方から言われてハッとしたことがある。古いシステムはいわゆるオフコンで、夜間にバッチ処理で150万件のレコードを処理して、1000万件のレコードを更新しにいっていると聞いた。
一方自分は、新しいシステムで旧システムで同じ時間で15万件を処理するためには、どうしたら良いかと悩んでいる。
旧システムよりは、ハードの性能は格段に上がっているはずで、新技術もいろいろあるはずなのに、なぜパフォーマンス問題に悩まなければならないのだろうかと思った。
技術チームにアドバイスを求めると、「RDBMS内でできることは、RDBMSにできるだけやらせてプログラム内で多段ループを組んでその中でSQLを投げることはやめなさい」と言われた。言われていることはわかるし、そうするつもりもなかったけれど、それでも15万件を処理するのに不安が残るねという話になった。
処理自体はいたってシンプルで、処理対象のレコードをいろいろな条件でとってきて、項目をいろいろ編集して別のテーブルに書く。コンピューターの一番得意な処理のはずなのになんで時間がかかってしまうのだろう。
もしかして一括大量処理には、いまだにCOBOLで汎用機やオフコンの方が向いているのだろうか？それとも自分の考え方が間違っているのだろうか？確かにCSVファイルを一括で処理したりするだけならばAWKの方が早かったりするのだけれでも。なんでもJavaというのが間違っているのだろうか？
2016年11月13日日曜日
IT開発プロジェクにおける計画外のタスクについて
また、みずほ銀行の基幹システム開発が話題になっている。本当か嘘かわからないが、工数の９割が進捗会議についやされているという噂を見た。また進捗会議にむけての会議もあるらしい。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。
通常計画フェーズにおいて、スケジュールを引く、ウォーターフォールだろうがアジャイルだろうが引くはずだ。形式は、ガントチャートかもしれないし、チケット形式かもしれない。とにかくやるべきことを明確にしようとするはずだ。
しかしながら、いざ計画から設計〜開発、テストとフェーズが進むと計画外のタスクが増えてくる。
内容は、問題解決のための活動が多いが、それ以外の活動もある。冒頭に述べた会議のための活動もその一つだ。またメンバー内での意識合わせもある。予期していなかった他チームからの依頼も非常におおい。資料をExcelで作成（Excelのほうが作るのに便利だと思ったから）していたら、別の人に見せるためにPowerPointに作り直してくれと言われることもある。なので似たような資料が増殖していくことが多い。どれが本物かわからない。その確認のためにまた作業が発生する。
そのように計画外タスクが増え続ける状況にもかかわらず、計画したタスクの期限は守れという。仕事量の総量は増え続けているのに期限を守れるはずもない。みずほ銀行の内部は、こういった状況になっているのではないかと想像する。
予算（人かける期間）は最初に決まってしまっているので、増えてしまった作業を計画に組み込むことができない。どうしようもないほど計画したタスクが遅れてしまった時には、「当初計画した」タスクは見直すが、よほど大きくかつ皆が必要だと認める作業は追加されない。資料の再生産や、会議のための会議は結構な作業量になるが、これをタスクと認めてくれるリーダーは少ない。これら作業量が臨界点を超えるとプロジェクトは失敗する。
登録:
投稿 (Atom)