アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
検索速度向上に30億って… (スコア:2, すばらしい洞察)
Re:検索速度向上に30億って… (スコア:0, 参考になる)
大阪府の人口より大きな数字ですよ。
実際の話30億が無茶に高いなんておもえませんな。
大規模開発の経験ないと安く見積もってしまうんだろうなぁ・・・
100人以上のSE部隊で1フロアびっしり埋め尽くされた中でのシステム開発なんて大規模なものを一度でも経験してみりゃ人件費考えただけでも桁の違いに気づくでしょうね。
Re:検索速度向上に30億って… (スコア:2, すばらしい洞察)
まともなシステム開発の経験がないと理解できないのは仕方がないが、
知ったかかまして恥ずかしくないのかね。
ちなみに常時100人以上がフロア占領してると、賃料いれても10億/年いかねぇぞ。
何年かけて直すつもりだ?
#こんなコメントに参考までついちゃうのはどうにかならんものか
Re:検索速度向上に30億って… (スコア:5, すばらしい洞察)
しかも顧客番号で検索して、現行システムより40秒以上て・・・
顧客番号といったら普通ユニークキーなわけで、どうやったらユニークキーによる検索でそれだけの時間がかかるような糞システムを作れるのかさっぱり理解できませんね。
インデックスを全てオンメモリで処理できるだけのメモリをサーバに積むとして、顧客番号が12桁の文字型と仮定しても1000万件でたったの120MB、かなり余裕を見てメモリを256MBも増設したとして、今時256MBのメモリなんてサーバ用の高級品でも10万円もしないでしょう。
読み込むのも今時のHDDだと120MBのデータをHDDから全て読み出したとして5秒もかかればかなり遅い方なわけですから、
基本設計がまっとうに行われていたら10秒もあれば応答するシステムが作れますね。
ちなみに、私が仕事で顧客情報のDBを作った時が氏名50桁住所100桁くらいだったから諸々の属性情報を多めに見積もって顧客一件300byteと仮定したら
1000万件で3GB、
端末とサーバは1000Baseで結ばれているとして3GBの転送にかかる時間は
3000*8/1000 = 24秒
実際には帯域の半分くらいしか使えないとすると48秒
48秒ということは
> 顧客番号で検索して、現行システムより40秒以上
にだいたい合致するではないですか!!!
謎は全て解けた !!!!!
結論:このシステムを組んだ奴はデータベースの正しい使い方も知らないド素人
Re:検索速度向上に30億って… (スコア:2, すばらしい洞察)
過去の取引情報(数年分
設置してある設備情報(及び履歴
設備情報から故障履歴DB、販売DBとリンク
それ以外にも東京ガスのインフラを管理するシステムのようなもの接続していたりすればいくらでも情報は増えると思うけど。
これだけでも何十倍にも情報量が増えると思う。
Re:検索速度向上に30億って… (スコア:1)
それは個々の顧客を選択してから「詳細情報」として引っ張り出してくるなどの遅延処理を行って無駄なクエリーは発生させないのが普通でしょう。
適切なインデックスが設定されていれば顧客に付随する情報を顧客コードを指定して取ってくるなんてのはたいして時間がかかる話ではありませんので。
Re:検索速度向上に30億って… (スコア:0)
> 指定して取ってくるなんてのはたいして時間がかかる話ではありませんので。
○○機器を使っていて、故障が発生していて、まだ未対応で、なおかつ空いている
工事担当者が担当できそうな地域エリア、の顧客一覧を知りたいなどの要件を
要件定義時にばっさり切り捨てられる交渉スキルがあれば、「必ず顧客コードを
指定してください」っていうシンプルなシステムを作れるでしょうね。
Re:検索速度向上に30億って… (スコア:1, すばらしい洞察)
Yahoo! ニュースの記事では
> しかし運用テストの結果、オペレーターが顧客番号を打ち込んでから、
> 顧客データが呼び出されるまでに現状より約40秒長く時間がかかることが発覚。
これだと顧客番号だけで検索してるっぽいぞ。
Re:検索速度向上に30億って… (スコア:0)
>工事担当者が担当できそうな地域エリア、の顧客一覧を知りたいなどの要件を
それはコールセンタが使うシステムではありませんね。
#なぜごめんなさいの一言がいえないのか
Re:検索速度向上に30億って… (スコア:0, フレームのもと)
あなたが作ったから、情報量が増えたら検索速度が遅くなるような糞システムが出来上がったんですか?
RDB触ったことあるのかなぁ?
過去の取引情報数年分って、今回のシステムは何のためのシステムなのか理解してますか?
#こんなのにすば洞つけんなよ、晒し意図か?
Re:検索速度向上に30億って… (スコア:0)
・ちゃんとインデックスを張ってあってその辺の関連情報を取ってくるviewをきちんと作ってある
・viewを使って検索するやつが間抜けなリニアサーチ
とかね。見積りとしては結構いい感じじゃないのかな。てかさー、そういう発言しちゃうって事はあんたviewとかしらんし複数人で開発とかもしたことないでしょ。
Re:検索速度向上に30億って… (スコア:1, 興味深い)
某社のRoHS対応請け負いましたが、各部品にユニークキーが無く、惨憺たる開発でした。
Re:検索速度向上に30億って… (スコア:1, すばらしい洞察)
> まーさーかー、カーソルをループ回して頭から最後まで自前のコードで舐めてるんじゃなかろうな。
そのまさかの可能性がきわめて高い、ということです。
そんな腐れコードをたった40秒かそこらでこなしてしまう今時のハード事情ってすごい。。。
Re:検索速度向上に30億って… (スコア:1)
(中の人だったら確実に「中の人なのでAC」してる)
リンク元の記事によると
> 同社は顧客対応を迅速化するため、03年から60億円を投じて、コールセンターでの問い合わせ内容などを管理するシステムと、販売代理店が行う機器の販売、修理などの情報を管理するシステムの2つを統合する作業を自社で進めていた。
> しかし運用テストの結果、オペレーターが顧客番号を打ち込んでから、顧客データが呼び出されるまでに現状より約40秒長く時間がかかることが発覚。
ということですが、私の発言は全て上記引用からの推測です。
・二つのシステムの統合なんだから、中身がわからなくても新システムの応答時間は常識的に現状システム+αになるだろうと推測できる。
・普通、減価償却の関係でこういったシステムは3年とか5年とか10年とか使われる。つまり現行システムのハードは少なくとも3年前の代物。
・ムーアの法則によるとCPUの性能は2年で倍になる。システム全体の性能も2年で倍、とはいかないが3年だと確実に倍にはなっている。
・初期予算30億、追加予算30億の時点でDBサーバが一台こっきりの予算しかないなんてありえない。
・既存システムのアップグレードに際しての性能見積は新規開発の場合に比べるとはるかに簡単。
既存システムのアップグレードという非常に性能見積がやりやすい状況で、予算も潤沢にあり(初期予算30億はいいとして追加で30億とれるって何?)、しかも年々ハードウェアの性能は向上している、なのに「現状より約40秒長く時間がかかる」なんておかしいだろ、ということです。
新規システムで応答時間が40秒だったら私だってここまで馬鹿にしません。
#で、個人的な経験則として、こういう場合は誰かが信じられないミスを犯しているケースである確率がかなり高い、といったあたりから親コメントのような結論に
Re:検索速度向上に30億って… (スコア:0, フレームのもと)
複雑な業務系にたずさわったことがないのがバレバレですな。
現実的な話、1000万件の顧客情報を 1000万レコードで管理できると思ってる?
世の中、サルでもできる EC サイト構築ばかりじゃあないんですよ。
Re:検索速度向上に30億って… (スコア:1, すばらしい洞察)
そこが検索処理のボトルネックになることがわかっているとすれば、
1000万レコードで管理できるように設計するものじゃないの?
Re:検索速度向上に30億って… (スコア:1)
30億は大企業の基幹システムとして高すぎるとは思いませんが、それでも地銀、中堅証券クラスの投資じゃないですか。
ガスのシステムってどのあたりがそれほど複雑なのでしょうか。
金融システムに比べると、顧客と外部の会社との取引や顧客間の取引というものが(あまり)ないという時点でかなり楽なシステムですよね。
証券口座や銀行口座は一つのDBにしないと厳しいところがありますが、こういうのは比較的簡単に顧客番号でディスパッチしてDBを分散できそうです。
Re:検索速度向上に30億って… (スコア:0)
Re:検索速度向上に30億って… (スコア:1, おもしろおかしい)
Re:検索速度向上に30億って… (スコア:0, フレームのもと)
1000万件の顧客情報に全体で何億、何兆のレコードを費やそうが、
それの管理(Index)は1000万レコードで出来ないと困ります。
どうやらそこが貴社の開発チームのネックみたいですね...。
Re:検索速度向上に30億って… (スコア:0, フレームのもと)
あなたが触った(≠携わった)のは複雑な業務系じゃなくて、腐った業務系なだけでしょ。
顧客情報周りの扱いがどういうものなのか理解できてないからそんな発言が出るんだよ。
Re:検索速度向上に30億って… (スコア:0)
>複雑な業務系にたずさわったことがないのがバレバレですな。
>現実的な話、1000万件の顧客情報を 1000万レコードで管理できると思ってる?
>世の中、サルでもできる EC サイト構築ばかりじゃあないんですよ。
なぜかマイナスモデされているが、私も同意。
あくまで一例ですが、コアなテーブル同士なのになぜか複数サーバに分かれていて通信コストを考えないとかいう設計をすると簡単にパフォーマンスは落とせます。
「コアなテーブルなのになぜか複数サーバに分かれて」なんてクレージーだ?
まぁある意味そうなんだ
Re:検索速度向上に30億って… (スコア:0)
1000万件程度のDBでよほどアホな問い合わせしても、通常そんなかからん。
DBの問い合わせ使ってないか、使い方間違ってるんだろね。
Re:検索速度向上に30億って… (スコア:0)
ソンナバカナ・・・
Re:検索速度向上に30億って… (スコア:0)
関係者の話によると完全にはずれです。
誰かが推察してますがCRM関連ですね。
1000万行のテーブルの検索だけで済んだら楽なモンです。
1000万行あるって事はそれに見合った負荷や付属情報があるっことくらいてすぐに分かりそうなモンだけど
DBのみに原因を帰結させるって分散処理が一般化して
十数年経つのに未だにプロセス指向的にしかシステム見れない人が
多いって事なんだろうか?
Re:検索速度向上に30億って… (スコア:0)
えーっと、つまり、
「顧客の夢いっぱい、機能満載の動かないコンピュータ」
というパターンでしょうか?
技術を知らない営業がよく作るという。
ほんとうは契約ができた時点で失敗することが確定しているのだが、
技術を知らない営業はそれを理解する能力がないし、責任者は
責任をとりたがらないから問題はひたすら先送りにされる。
その結果が30億の損失なら、まだ安い方じゃないかな。
#ちなみにこの損失には過労死や自殺者に支払われる生命保険や
#何かは含まれておりません。
Re:検索速度向上に30億って… (スコア:0)
Re:検索速度向上に30億って… (スコア:0)
あと、タレコミにあったニュースをちゃんと読んでれば自明のことだが、「40秒以上遅くなった」と言っているのは<b>運用テスト</b>でのこと。
対してコメントなどで「2秒で終わる」ってのは、単体テストか、せいぜいが結合テストの話でしょ?
最初っから前提が違ってるんじゃ、話がかみ合わないよね。
Re:検索速度向上に30億って… (スコア:0)
このシステムは1万人も同時アクセスするようなシステムじゃないし、
運用テストでかかっている時間は、本来のα+40secであって、
結合テスト以降のαの部分はそのままだよ。
Re:検索速度向上に30億って… (スコア:1)
オブジェクト指向DBとか、XMLDBとかだと、どうなんでしょうね。
そのあたりのデータベースを無理矢理使って、やっぱRDBだよねー。
で、作り直し。といったパターンもあるかも。
Re:検索速度向上に30億って… (スコア:1)
吐き気が... (スコア:0)
そんな量のデータを突っ込むと想像しただけで気持ち悪くなる。
Re:検索速度向上に30億って… (スコア:0)
それとoodbはVersion管理が大変だと思う
まぁ~一度走り出したら変更がいらないシステムでは問題ないでしょうね~
Re:検索速度向上に30億って… (スコア:0)
100人x100万(人月)で12億ですね
しかもかなり大雑把な単価ですし、
工数は人月積み上げだけじゃないですよね
あとフロアに100人いる場合は大抵外にも…
もちろんHW、SW抜き…
仮定にたいしてあれこれ言うのは意味がないですが、
これが言いたかったんですよ。
知ったかかまして恥ずかしくないのかね。
Re:検索速度向上に30億って… (スコア:0)
#ん?単位は円じゃなくてウォンっすか?
そもそも人月持ち出してるけど、破綻したプロジェクトに100人突っ込んだって(良いか悪いか別にして)100人分の金はもらえないのよ。
開発用のHWやSWなんて全て用意してもらえると思ってるのかねぇ?
あなた、小規模プロジェクトのマネージメントどころか、メンバーとしてすら参画したことないでしょ?
知ったかかまして恥ずかしくないのかね。
Re:検索速度向上に30億って… (スコア:0)
コスト積み上げ方式が定着しているお役所なんてどうでしょう。
Re:検索速度向上に30億って… (スコア:0)