パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

東証システム、構築は10年前ですでに耐用年数もオーバーしていた」記事へのコメント

  • 約定件数 (スコア:1, おもしろおかしい)

    by Anonymous Coward
    > 約定件数の1日当たりの上限を500万件に引き上げる

    350万件(400万件?)から500万件って、10年たってもあまり変わらないんですね。
    素人の目でコンピュータの成長を見ていると、今なら5億万件ぐらい処理できそうな気がするんですが…
    • Re:約定件数 (スコア:3, 興味深い)

      by nq (16642) on 2006年01月22日 21時34分 (#868964) 日記
      タレこみ人ですが、処理件数というのが、処理のためのメモリーとかスループットで決まっているのではなく、一日分の記録件数で決まっているのがまず驚きました。
       システム増強といっても、単にハードディスクの容量を増やして、それに対応してプログラムの配列の上限チェックを変更しているぐらいと想像しますが、それで2倍程度にしか増えない、ということにまた驚きます。技術的進歩を考えれば、100倍ぐらい、楽々増やせるはず。

       素人考えですが、500万件の売買記録にどれぐらいの記憶容量が必要かと勘定してみると、銘柄コード、取引時刻、売り手コード、買い手コード、株数、取引価格という6つのlong int で済むとすると 48 byte * 5M = 240 MByte ですか。
      売り手、買い手をコード化せずにすべて100字ずつぐらい使って、さらにいろいろな付加情報をつけて、データベースのインデックスつけたりして、この20倍、一件あたり 1 kByte 使っても、5 GB で足りますね。10年前の汎用機で5GB HDD というのは極端に小さいものではなかったかも知れません。

      しかし、現在なら、その10倍の50 GBに拡張しても今のノートPCにも入るぐらいの容量です。

      こう数えてみると、東証のシステムは、現代においてコンピュータを日常的に使う者の想像を絶した貧弱なものと思われます。
      親コメント
      • Re:約定件数 (スコア:5, 参考になる)

        by von_yosukeyan (3718) on 2006年01月23日 1時33分 (#869105) ホームページ 日記
        >処理件数というのが、処理のためのメモリーとかスループットで決まっているのではなく、一日分の記録件数で決まっているのがまず驚きました

        これには二つの理由があります
        一つは、東証の現行の市場業務系システムが構築された90年代後半は、証券自由化前後で取引がまだ立会い取引が残っていた時代で、不況で取引が低迷していた頃にシステム企画がなされたという点です。オンライン取引が普及していない頃の話で、取引量も現在のように多くなく、札幌や福岡など他市場のシステムを東証のシステムと共同化することが大きな目的の一つでした。従って、企画の時点で、取引が(立会いなど)物理的に制限される取引が前提で行われたので、一日の総取引件数がシステム要件とされたのでしょう

        もう一つは、今回の記事で問題になっているのは、取引の約定処理を行う市場業務系システムではなく、約定した取引を決済機関(証券保管振替機構とみずほコーポレート銀行兜町証券営業部など清算銀行5行)で決済処理を行うための、清算指図(DVP)を作成処理するためのシステムです。従って、処理はオンライン処理ではなく、バッチ処理が大半です。また正確に言えば、この清算システムを運用しているのは、東京、大阪、名古屋、福岡、札幌の各取引所とJASDAQが共同出資して作った株式会社日本クリアリング機構が運用するシステムです
        親コメント
      • by ribbon (11750) on 2006年01月22日 21時48分 (#868976) 日記
        > しかし、現在なら、その10倍の50 GBに拡張しても今のノートPCにも入るぐらいの容量です。

        確かにそうなんだけど、昔のコンピュータに最新式のHD
        は付かないんじゃないかな。
        OSが管理できる最大サイズ、とかハード的なインタ
        フェースの問題とか。

        たとえば、10年前のPCに、最新式の、500GのHDは繋がら
        ない(認識しない)でしょ。BIOSの制限とかで。
        それと同じで、拡張しようにも出来なかったのでは
        ないかなあ。
        親コメント
      • Re:約定件数 (スコア:2, 興味深い)

        by Anonymous Coward on 2006年01月22日 22時41分 (#869003)
        日本の開発者ってやたらとCHARやVARCHARにしたがる人が多いと思いませんか?
        IDにしても英数字を入れるから絶対にCHARだと言い張る人が多くて頭が痛いです。
        DBのマニュアルには数値型を使ったほうが速いと書いてあるのですが、なぜ容量が余計に必要なCHARにしたがるのかよくわかりませんが、そのような傾向があるようです。
        #少なくとも某社の人たちは。
        親コメント
        • Re:約定件数 (スコア:2, 興味深い)

          by minek (14559) on 2006年01月22日 23時00分 (#869011) 日記
           だってさ。9(n)にするとさぁ、数字しかはいんないじゃない? X(n)にしとくとさぁ、いざというときに16進数に逃げる余地がね……。

           でも、集計や計算の必要のない識別子はchar(n)でよいと思いますけど。なんでもかんでもvarchar(n)は、行連鎖を引き起こす危険性があるので好きではないですが。速いからといって、ビット型で構成されたデータベースを使いたいとは思いませんし、適材適所でしょう。
          # という判断を標準で殺している場合がある、というのは同意。
          ## そして、現場に任せたらそれ以上にひどいことになる、というのも同意。
          ## フラグの判定を半角スペースとNullでやるのはやめて……。
          親コメント
        • Re:約定件数 (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2006年01月22日 23時31分 (#869027)
          だまされていませんか?CHARであろうが、BINARYであろうが、検索は同じ速度でやってくれますよ。INDEXを張ってなかったとかそういうことではありませんか?
          親コメント
        • 二進数浮動小数点数として扱われてしまうと困るときには、わざわざ文字列にして格納していたと伝え聞いています。でもいまちらっとSQL-92の頃の本を見てみたら、DECIMALとかNUMERICとかありますね。
          --
          屍体メモ [windy.cx]
          親コメント
          • COBOL-Sにおいては、固定小数点数9(n)V(m)と数値9(n+m)をデータ上で見分けることはできません。レイアウト上のお約束で、そこに小数点がある、と思って読んでいるだけです。REDEFINEしてしまえば、まったく別の型で読むこともできますし……。
            # 浮動小数点と通貨型の話はWindows以降の話だと思ってた。
            親コメント
        • by ryokiwind (22763) on 2006年01月23日 11時44分 (#869240)
          開発者は数値メインで使いたいと思いますよ。
          index張るにしても、色々と数値の方が扱いやすいですから。
          問題は設計者だと思います。

          客の要望が幾ら文字列IDじゃなければ駄目とか言ってきたとしても
          たとえば、内部でアスキーコードに変換して数値処理するとか
          隠蔽してしまえば客にはわかりません。
          親コメント
          • by Anonymous Coward
            システム全体が自システムだけで完結するんならソレでもいいのだけどね…。
        • by Anonymous Coward
          >日本の開発者ってやたらとCHARやVARCHARにしたがる人が多いと思いませんか?

          いや、現場ではシーケンスIDにVARCHARなんて使いたくはないんですが…
          (ORDER BY TO_NUMBER(x)なんてやるのよっ!)
          DBセンタの人々が
          「NUMBERはつかっちゃだめよーん」
          だってさ…

          #おかげでエンティティBeanが作れなくて泣き目を見たのでAC
        • by Anonymous Coward
          大抵のDBではNUMBERは2進化10進数(2桁で1バイト)だろうから、情報量に対する容量はむしろ不利じゃないか?
      • いろいろと意見もあるようですが、わたしもnqさんとソックリな計算をして、自分のサイトに記事を書いてしまいました。
        東証の取引システムのハードディスクが500MBやそこらだと推測される件 [knoa.jp]
        親コメント
      • Re:約定件数 (スコア:1, 興味深い)

        by Anonymous Coward on 2006年01月22日 23時27分 (#869022)
        リアルタイム系とは別に帳票系のシステムが場が
        閉まってからバッチ処理するんじゃないでしょうか。

        確定報が証券会社に伝わってから、証券会社側でも
        一日分の取引を確定するシステムが動くと思われるので
        全件処理を有る一定の時間で行う必要があるんでしょうね。

        株券実券の管理を証券会社でも東証でもない所が
        管理したりもするので、普通のシステムのようには
        いかないと思いますが。

        あと、10年前のメインフレームの動いている環境って
        今見ると結構びっくりすると思いますよ。
        親コメント
        • Re:約定件数 (スコア:1, 興味深い)

          by Anonymous Coward on 2006年01月23日 1時10分 (#869092)
          > あと、10年前のメインフレームの動いている環境って 今見ると結構びっくりすると思いますよ。

          フリーアクセス床から下に落っこちるとコンクリの床まで90cmくらいあって、骨折か捻挫は確実って? 床から空調の風がびゅうびゅう吹き出してるって? 19インチラックなんていっこも見当たらないゼとか?
          親コメント
      • Re:約定件数 (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2006年01月23日 1時08分 (#869090)
        とりあえず、株数と取引価格にゃlong intは使いたくないな。
        親コメント
      • by Anonymous Coward
        >一日分の記録件数で決まっているのがまず驚きました。

        後で検証できるようになってないと怖いと思いませんか?
        外部からの注文を全部マッチングさせるわけですから、間違っていてもどこが間違っていたのかを突き止められるようになっていないと。

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...