なぜRDBからCSV + COBOLに変更する事でコスト削減と高速化を同時に実現出来たかの考察 - ブログなんだよもん

そもそも既存はどんなロジック？ RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性 COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」

[programmablekinoko]

固定長レコード+バッチ処理だったら普通にコボルは無双すると思う

[hdampty7]

なんでもRDBを使えばいいとは思わないけど、こういうのってやってるうちに結局自前でDBを作ってるってことになってリレーション機能欲しいなって、気が付いたら初期のmysqlを作ってるってことになったりしないの？

[sho]

COBOLって出てきた時点で固定長だろうなとは思っていた。なるほどバッチという条件が加わるなら無敵だわね。

[rryu]

本来はRDBにした後に徐々にバッチ処理をやめてOLTPにしていきましょう的な感じだったのが頓挫したあげく元の構成に戻したみたいな感じなのだと思う。

[mkusunok]

興味深い分析。この手のマイグレーションを適切に判断できる人材ってだいぶ貴重では？

[inose660]

さすが。加えるなら『Javaじゃダメなの？』のところは、小数点演算の桁精度や四捨五入の切上げ・切下げルールがJavaだと言語仕様で大体決まってる一方、COBOLはコンパイラオプションで変わってくるので移植しづらい

[fusionstar]

そもそもなんで RDB にしちゃったの案件。 Windows より IBM i (AS/400) とかのほうが TCO 下がりそう。

[khtno73]

『RDBを使っていても単にキーでデータを取得する単なる箱になっている』90年代にメインフレーム/オフコン→ダウンサイジングでPCサーバ＋RDBMS移行あるあるなのかも。Oracleで言やR7.3.4以降の機能なぞ使ってないつう。

[igagurimk2]

保険料率計算って統計処理だから、ババっと一括で読み込んで処理するならファイルに保存しておいてお好きな言語で処理書くのは妥当な選択だよなぁ。

[nakag0711]

固定長ならC++でCreateFileMapping使って書けばもっと速く、寿命も長い

[Guro]

（書いてあることはわかる）（テキスト処理で済むならそれで）

[ginpei]

「RDBをCSVへ移行しコスト削減」の件を推測して解説。固定長データやバッチ処理という前提、検索条件の複雑性と現行のデータ設計等を考えるにまあ現実的な判断だと。本からは得られない本物の知見っぽい。

[fukken]

何もかも全てを変更できるならともかく、それが現実的でない、という条件ならそりゃ最適解は変わってくるよなぁ

[UDONCHAN]

ふむぅ

[masayoshinym]

SQLが7割って、そのSQLが複雑過ぎて遅かったっていうのもあるのでは。COBOLで処理するに当たって単純化した結果逆に速くなったとかもあるのでは。

[shimooka]

『新しいものが常に最適解とは限らない』マジでこれ。適材適所。

[mattn]

面白い。

[KoshianX]

なるほど全件読むし where 句で分岐できるような内容でもないとなると CSV のほうが遥かにマシな速度が出ると。うーん、もともとのデータの持ち方がアレだったのではという疑念はあるにせよ、そういうこともあるのか。

[uehaj]

「良いものと悪いものが混在しているより、悪いもので統一されている方が保守性が良い」の法則かな。/ BigDecimalの処理ならJavaよりGroovyがよい。ていうかJavaでは普通に地獄と化す。

[yogasa]

RDBなんてExadataにのしたら早くなるんでねーの？知らんけど。

[gui1]

bordereauの集計だけならそれほどCPUパワーいらないし。非定形系業務ないし。お好きにされればよいでしょう(´・ω・｀)

[yo_waka]

面白かった

[Harnoncourt]

バッチ処理系はCOBOLでやっているところも、情報分析系はRDBでゴリゴリ回すケースがほとんどではなかろうか。数百万件のデータをRDBで回してろくにパフォーマンスが出ないとかよくあるよね←弊社だけ？(；´Д｀)

[ocaesar]

歴史は繰り返す

[iwanofsky]

できるってこういうことだよなぁ。

[NOV1975]

そりゃ純バッチは純バッチでやるのが速いに決まってる。知らない人は多い。ただし制約も多いけどね。

[thekoruku]

HDFSの内部データ、PBのことを言っているなら、別に固定長ではない

[kinaco68]

COBOLは滅びぬ。何度でも蘇るさ

[atoh]

これからは70歳まで働きましょうって時代だから退役コボラー見つけてきたらいいんでね。

[munyaX]

なお、今後の保守…。

[n_231]

そりゃファイル処理にすれば速くなるのは分かるけど、今後メンテできんのかっていうのが

[t_yano]

全データロードがほぼ前提なら、COBOLがロードしやすい形式でダンプしたデータをロードしてフィルタかます方が速いって話ね。COBOLそういうの得意だもんな。

[memoyashi]

文字型とか数値型とか型をあまり意識せずrawデータ扱いなのも高速化の一因かも。

[sds-page]

RDB使ってるのになんちゃってKVS的に固定長突っ込んでたシステム20年くらい前に見た事ある

[F-SQUARE]

COBOLは死なない、と思う

[gayou]

時代に逆行してるのか、ある意味で先を行ったのかよく分からん。

[airj12]

処理量とデータ量と開発体制次第で十分あり得る選択肢 / でも自分には出来ないだろうなあ