自動ニュース作成G
なぜRDBからCSV + COBOLに変更する事でコスト削減と高速化を同時に実現出来たかの考察
http://koduki.hatenablog.com/entry/2019/06/17/182326
2019-06-19 04:52:17
>さて、この記事の驚きポイントは「1億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。
> 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ!」とか「RDBをファイルに変えるなんてとんでもない」とか思う人も多いんじゃないでしょうか。とりあえず私は思いましたw
>しかし実際に高速化はありえるのか、その理由を分析していきましょう。
・RDB使わずの高速化は単純にハードが新しくなったせいじゃないの?コストって何のコストだろうな。10年後にCOBOLの保守要員集めるコストなんかは考えたのか?SQL書き直したらしいから開発費ではないだろうし、RDBやUNIXのライセンス料とかだったりして。もしくはデータセンターにあったものをオフィスに置いたとか。
・業務系システムだと、膨大な件数を処理するバッチでは、DBのインデックスを一旦解放したりデータをSAM化して高速化するのって普通にやってたけどな。最近はハードの高性能化でそういう小細工はやらなくなってきたけど。
・記事を読んだけど、遅いのはRDBのテーブル設計が悪いように思う。「複雑な条件判定ビジネスロジックが幾重にも使われてる」というのなら、そのロジックの計算値を入れるフィールドを加えてインデックス張るべきでは。
・これ(一部かも知れんけど)請け負ったのはCOBOL専門のプロフェッショナル集団なのか。そんな会社があるんだねぇ https://www.microfocus.co.jp/about/
・まさかEBCDIC?w >*1:COBOLの場合は文字列や数値をテキストとして内部データも保持してるので結果として一部をのぞいてテキストになります。ASCIIかはさておき<
・マイクロフォーカスは昔からあるよ、DOS版COBOLとか出してたとこでしょ あとこのシステムって元々COBOLからRDBにシフトして元に戻したんじゃないの? だからテーブル設計がしょぼいんだと思うなあ
・件数や環境にもよるが高速化ではRDBがネックになる。出来るならテキストファイルのみ、横引きが必要なら連想配列。これに向くと大概速度が数十倍になる。よくあるのが現3万件の銀行支店をRDBで横引きせず、初期処理で連想配列に取り込むと数十倍速くなったりする。
・またRDBではないが、一般PCはGDIが遅いので、プログレスバーのリフレッシュを100回とかに固定するとまた数十倍速くなったりする。同様に、カウントUP表示などもある程度の素数毎にリフレッシュすることで同様に早くなる。つまり【COBOLとかJAVAとかツールは関係ない】【UNIXとかWindowsとかも関係ない】ハードやサーバ/ネットを理解してどう設計するか次第。
・そもそもMySQL登場時やSSD登場時にも度々言われているとおり、RDBというのはHDDに大量のデータをコスパよく保存してアクセスするための技術。ギガバイト単価が十分低下すればRDBには不要な機能が数多くある。もはやテーブル設計などという考え方が古いともいえる。
・そういえばキーバリューストアが流行ったときも似た議論があったな。何度となくそいういう議論がありながら未だにそれらはスルーされて有り難がって正規化などをして客から金を取っている。どうせ、INTとVARCHARしか使ってないくせに。ま、RDBは儲かるからな。
・RDBとCSVの違いというより単純に技術力の違いかなと思った
・それで「ぼったくり」会社が、ぼったくった金で買収して、その買収した製品にまたぼったくりするのを繰り返す。
・主な高速化の要素は、要件定義が「オフラインバッチ処理でいい」って事に気づいたってことだな。恐らく前のシステムは要件定義段階でオンライン処理も考慮されてたのでは。RDBMSはオンラインで並行処理時の堅牢性が考慮されてる。逆にWEBでのサービスみたいにオンラインでCRUD処理が並行要求されるとこにCSV使ったら悲惨なことになる
・RDBだってファイルシステム使ってるんだから。汎用より専用の方が早いのは当然。RDBは素人がデータ扱うために作られた仕組みだよ。データ扱うAPIを用意すればいいのに、SQLなんてクソ言語用意したのがダメ。動的SQL死すべし。
・#14 RDPと名のつく前の初期のRDB型というのがあった頃、SQLはなくて検索メソッドで物理レコード番号の羅列が取得できる物だった。並替云々もできた。ただ、指摘どおり向かない方々が足ひっぱりまくってた。
・RDBって仕事してる感出すには便利だからね。無能世代が何も考えずによくぶち込ませたもんだ。平成に比べると日本のITも改善が進んできているとは思う。
・#16 2ヶ月前まで平成だったのに、この2ヶ月でそんなにデータストレージ周りの環境って変わったのですか?記事の案件はホスト上でオフライン処理だからいいけど、オンライン処理で並列に要求が飛んできてリレーションが必要でトランザクション処理も要求されてる場合でもRDBMS使わずにデータ保存周りをフルスクラッチで構築してるんですか?
・#17 まずはそういうくだらないツッコミとムダに横文字を並べる頭の悪いコメを止めてくれるかな?
・第三者だけど、#16のほうがアホっぽく見えるよ
・#17 そもそも並列に要求が飛んでくることでどうしてリレーションが必須だと判断したのか? あとトランザクションの不要論はアトミックの議論まで遡るから20年前のMySQLのドキュメントでも読んどいて。
・#20 そんな風には書いてないよ。落ち着いてちゃんと読み返してみて>そもそも並列に要求が飛んでくることでどうしてリレーションが必須だと判断した
・並列な処理は直列化してもサービスを維持できるのではないか、何故リレーションが必要なのか正規化なんて不要ではないのか、トランザクションは大半ベタな単ロックで置き換えられるのではないか。それらを根本から考えるのがエンジニアリングであって、RDBMSの機能をありがたくそのまま使うのはユーザーもしくはオペレーターだろう。
・https://enterprisezine.jp/dbonline/detail/9450 FacebookはデータベースをInnoDBからMyRocksへ移行中
・#22 直列化 => それで性能が出るのなら。直列化にすればコードはシンプルになるけど、主にI/O待ちなどで性能でないから隠蔽するのに面倒でも並列化しますよね。 単ロック => すみません、単ロックなるものがいかなるものなのか私には分かりません https://bit.ly/2x7vYl4 https://bit.ly/2FkIGRG https://bit.ly/2WVSyfM この単は単方向リストとかのSingly?それとも別の単でしょうか?
・#23 すみませんが、あなたのこれまでの一連の発言とFacebookがMySQLのストレージエンジンをInnoDBからMyRocksへの移行する事がどう関連するのか私にはわかりません。#16と関連するならFacebookは仕事してる感を出すためにMyRocksを作ったことでしょうか?それともMyRocksにすると突然正規化は不要になりリレーションが不要ということになるのでしょか?
・(#25の続き) 私からすれば、facebookはRDBMSの使用を仕事してる感でなくガチ使用で、適材適所で使ってればfacebookクラスでもRDBMSは役立つ道具だし、これからもfacebookは適材適所でRDBMSの使用が向くワークロードならを使い続けるつもりだって記事にしか見えませんね
・まず、随分頑張って正当性を主張しているようだがキミの個別の状況など知らない以上、折り合うことはない。そしてそもそも #16 のコメそのものが自分で言うのもなんだが相当乱暴な『雑感』なわけで、それに対するツッコミとしてはそうとうズレていると思わざるを得ない。
・その上で言うが、facebookはかつてnosqlと呼ばれたアプローチにに古くから取り組んでいて、今のnosqlのアプローチはRDBMSでnosql的なエンジンをラッピングして扱いやすくするというもの。これをもってRDBMSだというなら、#17を読み返してみるといい。
・facebookが仕事してる感出してるとは言わない。だが、俺が担当している仕事で #16 見たいなコメントと設計が上がってきたら俺は突き返すよ。まさに考えが足りない。それでも「やっぱり必要」と言われたらOKするだろう。昭和の時代は2回突き返して3回目でOKというのが良くあるマネジメントだったらしいから俺は優しい方だ。
・少し前までPCIEに接続されたフラッシュメモリの上で直接データを扱うなんてアプローチもあった。この扱いづらいアプローチはNVMeで接続されたストレージ上にRDBMSでラッピングされたNoSQLのテーブルを保存するという誰でも扱えるソリューションに今はなっている。キミがIO待ちとかテーブルの正規化とか考えてる間に、テスト実装くらい終わるだろう。
・時代はいずれインメモリ型DB(メインメモリ上に全データを常駐させるデータベース)になると思う。更にメインメモリの不揮発性化が進めば、SSDなどのようにわざわざディスクを模倣する必要もなく、OSからアプリまでメインメモリのみで動作すれば良くなる(ディスク等は元々補助記憶目的)。
・特に事務処理データなどのようなG単位程度しか必要なければ、先に実現すると思う。大容量データを必要とする処理のみディスクが残るのだ思う。ただ長期保存やバックアップで残るかもしれない。
・ハードなんかどんどん意識しなくなってきてるのに、uembovが前時代的すぎてヤベー。
・sdvqva(=zaivxu)はイタイね。論語読みの論語知らず的な、単語は知ってるけど単語の意味を理解してない的な。高い確率で開発や運用の実務経験ないでしょ。じゃなきゃ「単ロック」とか「nosqlのアプローチ」とか「nosql的なエンジン」などの意味不明な作文はしない。多分、自称セキュリティー・コンダクター http://mubou.seesaa.net/article/10976839.html 的な奴でしょ
・#27 自分の正当性というか君がアホっぽい書き込みしてるから突っ込んでるだけだよ。しかも自分のコメントを自分で突き返すとかわけのわからない事書いてるし
・#34 セキュリティーコンダクター!懐かしい! 私は昔ハッタリだけで顧客に寄生してたダメなコンサル屋を思い出してた
・#34 悪いがお前らよりは仕事してたと思うぞ。人をディスってる前に何か具体的な反論でも書き込めよ。
・#34 未だに分かっていないようだから解説してやる。MySQLはフロントエンドとデータの保存部分が分離されていて昔からNoSQLをラッピング出来るように作られている。トランザクションのないテーブルとか、メモリだけで運用するテーブルとか。MySQLではこれをストレージ"エンジン"と呼んでいる。
・せっかくだから俺も想像でお前ら(?)をディスってやるよ。DBとかいってオラクルだけ使ってロクな苦労もしてない、ツッコんだ考察もしないエンジニアもどきが。ソラリスの上に乗ったsymfowareのお守りでもやらされたら、直ぐにRDBMSなんて置き換えたい気持になるわ。
・連日の昼間多連投が途絶えたと思ったら復活したか。いろいろ突っ込まれたから言葉のレクチャーを受けてきたのかな?今まで「NoSQL」を「nosql」とイタイ作文をなおしてて偉いね
・#37 いままで数回突っ込まれてるのに頑なに避けてる「単ロック」なる謎のワードの解説はまだ?
・#38 ストレージエンジンをどや顔で「お前ら知らなかったろ?」的に語っておりますが、#25で使っている通り既知ですしMySQL触ったことあるエンジニアなら知ってて当然です。そもそもDB(not RDBMS)を知ってれば「nosqlのアプローチ」とか「nosql的なエンジン」などと謎の作文はしません
・それと#30でドヤ顔的に語ってるアプローチはFusion-ioのioDriveが出回り始めたときにどこのスタートアップも一度はやったこと。で、君はPCIEでフラッシュメモリ使えばIO待ちを考える必要はないとし、直列処理を正当化してるが、現代のCPUから見ればDRAMでさえも遅いのに、それよりも遅いフラッシュメモリ使っててなんで不要と言えるのか説明してみ
・#39 全く外れ。Oracleは顧客からの指定以外で使わない。MySQLはinnodbのbugfixやボトルネック部分のpatchを書た事ある。後でコミュニティに投げて本体に取り込まれたのもある。ストレージエンジンは当時のMySQL(5.6?)でもGISの対応あったけど難ありで、自前でデータストア用意してそれをプラグインAPI使ってストレージエンジンとしてMySQLから使えるようにしてた
・#37 おまえが具体的なツッコミをスルーして逃げてるからオカシイ奴だって事になってるんだよ。「単ロック」ってなんだよ?さっさと得意のドヤ顔妄想作文しろよ
・#41 単ロック ごめんなさい「純」が抜けてました。これで満足かな?よほどこだわってる見たいというかそこしかツッコみどころがないのか。
・#42 知ってて当然なら、では「謎の作文」というのは貴方の理解力が足りないか単なるレッテルですね
・#43 最初からそう反論すれば多少は話になったものを。現実問題としてHDDのIO待ちで困ることはあってもメモリのIOで困る状況なんてほぼないし、そのレベルになるとどっちにしてもスクラッチだよね?RDBMS入れてすむとは思えんが?だいたい「俺は○○の用途で使っていたからそれではダメだった」と何故最初から言わなかった?それが#22であり#29だ。
・#44 で「Oracleは顧客からの指定以外で使わない」というほどOracleの弱点は感じながら、#16に噛みついわけだ?決断を押しつけられる経験もしたのに? ま、単に「高いからMySQL」とかいう話かもしれんが。
・あと疑問なのは、なら何故「NoSQLも今やRDBMSの一部に過ぎない」と反論しなかったのか。今読み返したら、それで俺を黙らせることも出来たと思うがな。それをしたくないほどRDB的な手法にこだわりがあるなら、もはや具体的な用途を例示するしかない。
・44じゃないけど そりゃ#16のボケを読んだらツッコまずにいられないでしょ!平成が終わってから2ヶ月立ってないのに遠い昔のように語っちゃてるんだもん
・俺は引退したが元は証券のエンジニアだった。今や金融よりも複雑な業務システムは多々ある(例えば航空とか)とは思ってはいるが、そこまで固執するほどの用途が世の中にどれほどあるのか。程度問題とは言え理解に苦しむ。
・#51 平成も30年続いたんだからさ。前期中期後期くらいあって、ざっくり#16みたいに書いてもいいじゃん。そこは勘弁してよ。というか、ツッコミ部分がそこだけだったら大人しくしてたわ。
・戦争前後で大きく変わった昭和に比べると、平成はほとんどが「失われた○○年」に占められているから大きく区分するのは難しそう。
・#46 41じゃないけど、二人のやり取りに興味津々なので横から 単純ロックってのはなんなんだろ? 単純にDBM全体でロックしちゃうってことかな?ずいぶんと豪快な気がする… でも、そもそも直列化してるという主張ならロックしなくていいのでは?(I/O待ちでブロックされて後続のリクエストが糞詰まりになる気がするけど)
・#48 NANDフラッシュメモリレベルだとOSSのRDBMSでも性能向上の余地があるくらい、まだまだI/Oがボトルネックですよ?I/O待ちで困らないレベルならいちいちスクラッチでDBMS作ってRDBMSの皮被せなくても、もともと既存のRDBMSで十分耐えられる負荷なのでは?
・#49 オラクルDBを選ばないのはライセンスの問題かと。OSSは必要に応じて必要最低限の手入れで実装できる。手を入れられないと他の部分も含めて実装しなきゃいけなくなる。実際#44の内容はそういう使い方をしてる事を示唆してるし、FacebookのMyRocksも参照性能を犠牲にしても更新性能を上げたいという要求からの実装だし
・#50 そもそもNoSQLってワードがイマイチでは? あれは技術用語でなくRDBMSをそれが適さない領域まで杓子定規に使ってたことに対するアンチテーゼ的なマーケティング用語でしょ。 様々なレイヤー、特徴が千差万別、多様なものを一括りに語れる言葉だと意味が広範すぎて曖昧すぎるかと。昔ならいざ知らず、今は技術者同士の会話では使わないのでは?
・あえて合わせてNoSQLという用語を使うなら「今や」も何も、「昔からRDBMSはSQLというDSLに基づいて内部ではNoSQL対してデータ処理をしてる」と言えるかと
・#16みたいに、フェイスブックのようなエンジニアが何千人もいるような会社を引き合いに出して無能扱いされても困るよ。PayPayのサービスだって3ヶ月で作ったんだろ?ありモノをうまく組み合わして早く形にすることが優れたエンジニアじゃん
・#60 ありモノをうまく使えず、作るモノもチープ。低レベルな開発力は金の力でスケールアップすることでカバー。他者を無能世代とくさすが、実は自分が無能なくせに無駄に声がでかい厄介者として扱われてたことは引退しても気づかない、あぁ悲しい元証券のエンジニア
・読み返してみたけど、元証券エンジニアはこの恨みが消えないのねby#60>ソラリスの上に乗ったsymfowareのお守りでもやらされたら、直ぐにRDBMSなんて置き換えたい気持になるわ。
・いつまでこれ、書き込み続けるの? ここまでのコメで何かのキーワードがよほど「刺さった」んだろうと思っちゃうわ。 「もはや具体的な用途を例示するしかない」にまともな答えがない限り、想像でディスる合戦するしかないよね。まぁそれもそれで面白いか。
・#61 オラクル使ったら「上手くありものを使った」とか、どっちが金満なんだよ……。
・おお。元証券エンジニアのxaimpaさんがいらっしゃった。
・#60 組み合わせる技術が不適切ではないかといってるの。なぜそこでRDBというパーツを組み合わせたのか「もはや具体的な用途を例示するしかない」と書いたのだがな。例えば、MySQLに1テーブルにIDだけ振ってあとはインデックスも貼らずにvarcharなんてシステムはこの世には大量にあるがそれでも#17のような状況をクリア出来る案件はいくらでもあるわけだ。
・だがそれをもって「RDBを使っている」なんて普通はいわないだろう。旧来的なRDBの手法が未だ具体的に有効な環境がどれほどあるか、あるいは一例でも具体的に示せば、想像でディスる合戦よりは有意義だったろうにな。
・だがここで何より需要なのは、古の技術論よりも他人をディスっていた方が面白いとい言うことだ。 #62 読み返してみたけど、俺のコメの恨みが消えないのね。
・#62 普通は一度酷い思いをしたら「自分が何か改善しよう」とか「旧来的な手法のどこかに誤りがあったのではないか」とか考えるの。恨み上等。人を恨むよりは技術を恨んだ方がいい。ところが世の中にはそれをせず、自分が味わった苦労と手法を次の世代にも味あわせないと気が済まない人間がいる。これもまた恨みの対象だよね。
・#68 書き込んだの19 33 60だけだから、特に恨みも何もないかと…
・いまどきRDBMS使うのに他の選択肢があるのになんで元証券エンジニアさんは馬鹿の一つ覚えに相手がオラクルしか使えないと思いこんでるんだろ?#44の人は客指定以外で使わないって書いてあるし、自分でも#49で書いてるよ?痴呆?昭和生まれのエンジニアさんは昔にオラクルと歌舞伎町の美人局にぼったくられた怨みのばかり思い出しちゃうのかな。ご愁傷様 Ω\ζ°)チーン
・#71 他人をディスっていた方が面白いという点には同意頂けたようで大変ありがたく「もはや具体的な用途を例示するしかない」をスルーしている点はもう忘れるとして、そのコメの末尾ヤツが『2ch系サイトの投稿・スラング持込』に当らないことを解説して頂けませんか?詳しいでしょ?
・人の質問をスルーしといて自分の質問は答えてもらえると思えるその傲慢さは昭和生まれ特有のもの?
・#73 人の質問をスルーしといて自分の質問は答えてもらえると思えるその傲慢さは昭和生まれ特有のもの?
・オウム返ししかできなくなったか。元証券のエンジニア哀れ
・#75 毎日丹念に煽っていくスタイル。怖い。
・二日間の書き込んだだけで、#16から書き込みし続けてる自分を差し置いて「毎日丹念に」とか言っちゃう元証券のエンジニア滑稽
・#77 おはようございます。今日も恨の文化の体現、お疲れ様です。
・7payの素敵なお仕事も元証券のエンジニアさんのですか?
・#79 おはようございます。大昔に息子に外されてるよ?っていうか知ってんだったらそっちニュースでコメしたら?
・今回やらかしたとこより無能だから外されたの?
・なんだ知らんのか。ならこれ以上言うつもりはない。おやすみなさい。
・真っ昼間に寝るなんて変わった生活スタイルですね。夜間警備のバイトに備えての仮眠ですか?エンジニアとして解雇されても食ってかなきゃいけないから大変ですね
・ホント、どうでもいいとこにツッコむときは活き活きしてるな。。。
・国語も技術もツッコミどこ満載だから、ボケてると思ってみんなツッコミ入れてるんだよ。がんばれ自ニュのアイドル
・#85 いやお前「ボケてる」って気付かずにツッコんでるだろ、そもそも。。。
・元証券のエンジニアさんは呆けるのか。ネット越しのテキストのやり取りで、ましてや医者じゃないし、まさか痴呆症患者だなんて思わなかったは。気付けなくてゴメンね
・#87 おはようございます。冗談を冗談と分からないのは発達障害らしいですよ。気付ける医者に相談してきてはどうでしょうか?