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

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

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

暮らしカテゴリーの変更を依頼記事元:

koduki.hatenablog.com

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

300usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

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

300 users

koduki.hatenablog.com

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント55件

注目コメント
新着コメント

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

cobol

2019/06/18リンク

その他

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

システム開発

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

プログラミング

2022/02/15リンク

その他

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

2019/06/20リンク

その他

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

2019/06/19リンク

その他

UDONCHANふむぅ

2019/06/19リンク

その他

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

COBOL

2019/06/19リンク

その他

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

考察

2019/06/19リンク

その他

mattn面白い。

2019/06/19リンク

その他

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

2019/06/19リンク

その他

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

2019/06/19リンク

その他

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

2019/06/19リンク

その他

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

2019/06/19リンク

その他

yo_waka面白かった

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

ocaesar歴史は繰り返す

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

munyaXなお、今後の保守…。

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

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

2019/06/18リンク

その他

F-SQUARECOBOLは死なない、と思う

2019/06/18リンク

その他

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

cobol

2019/06/18リンク

その他

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

2019/06/18リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「なぜRDBからCSV + ...」が注目されています。

気持ちをシェアしよう

ツイートする

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

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