アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
約定件数 (スコア:1, おもしろおかしい)
350万件（400万件？）から500万件って、10年たってもあまり変わらないんですね。
素人の目でコンピュータの成長を見ていると、今なら5億万件ぐらい処理できそうな気がするんですが…
Re:約定件数 (スコア:3, 興味深い)
システム増強といっても、単にハードディスクの容量を増やして、それに対応してプログラムの配列の上限チェックを変更しているぐらいと想像しますが、それで2倍程度にしか増えない、ということにまた驚きます。技術的進歩を考えれば、100倍ぐらい、楽々増やせるはず。
素人考えですが、500万件の売買記録にどれぐらいの記憶容量が必要かと勘定してみると、銘柄コード、取引時刻、売り手コード、買い手コード、株数、取引価格という6つのlong int で済むとすると 48 byte * 5M = 240 MByte ですか。
売り手、買い手をコード化せずにすべて１００字ずつぐらい使って、さらにいろいろな付加情報をつけて、データベースのインデックスつけたりして、この20倍、一件あたり 1 kByte 使っても、5 GB で足りますね。10年前の汎用機で5GB HDD というのは極端に小さいものではなかったかも知れません。
しかし、現在なら、その10倍の50 GBに拡張しても今のノートPCにも入るぐらいの容量です。
こう数えてみると、東証のシステムは、現代においてコンピュータを日常的に使う者の想像を絶した貧弱なものと思われます。
Re:約定件数 (スコア:5, 参考になる)
これには二つの理由があります
一つは、東証の現行の市場業務系システムが構築された90年代後半は、証券自由化前後で取引がまだ立会い取引が残っていた時代で、不況で取引が低迷していた頃にシステム企画がなされたという点です。オンライン取引が普及していない頃の話で、取引量も現在のように多くなく、札幌や福岡など他市場のシステムを東証のシステムと共同化することが大きな目的の一つでした。従って、企画の時点で、取引が(立会いなど)物理的に制限される取引が前提で行われたので、一日の総取引件数がシステム要件とされたのでしょう
もう一つは、今回の記事で問題になっているのは、取引の約定処理を行う市場業務系システムではなく、約定した取引を決済機関(証券保管振替機構とみずほコーポレート銀行兜町証券営業部など清算銀行5行)で決済処理を行うための、清算指図(DVP)を作成処理するためのシステムです。従って、処理はオンライン処理ではなく、バッチ処理が大半です。また正確に言えば、この清算システムを運用しているのは、東京、大阪、名古屋、福岡、札幌の各取引所とJASDAQが共同出資して作った株式会社日本クリアリング機構が運用するシステムです
ハードディスクの容量 (スコア:3, 参考になる)
確かにそうなんだけど、昔のコンピュータに最新式のHD
は付かないんじゃないかな。
OSが管理できる最大サイズ、とかハード的なインタ
フェースの問題とか。
たとえば、10年前のPCに、最新式の、500GのHDは繋がら
ない(認識しない)でしょ。BIOSの制限とかで。
それと同じで、拡張しようにも出来なかったのでは
ないかなあ。
Re:約定件数 (スコア:2, 興味深い)
IDにしても英数字を入れるから絶対にCHARだと言い張る人が多くて頭が痛いです。
DBのマニュアルには数値型を使ったほうが速いと書いてあるのですが、なぜ容量が余計に必要なCHARにしたがるのかよくわかりませんが、そのような傾向があるようです。
＃少なくとも某社の人たちは。
Re:約定件数 (スコア:2, 興味深い)
でも、集計や計算の必要のない識別子はchar(n)でよいと思いますけど。なんでもかんでもvarchar(n)は、行連鎖を引き起こす危険性があるので好きではないですが。速いからといって、ビット型で構成されたデータベースを使いたいとは思いませんし、適材適所でしょう。
# という判断を標準で殺している場合がある、というのは同意。
## そして、現場に任せたらそれ以上にひどいことになる、というのも同意。
## フラグの判定を半角スペースとNullでやるのはやめて……。
Re:約定件数 (スコア:1, すばらしい洞察)
通貨用10進が無かった頃は (スコア:1)
屍体メモ [windy.cx]
Re:通貨用10進が無かった頃は (スコア:1)
# 浮動小数点と通貨型の話はWindows以降の話だと思ってた。
Re:約定件数 (スコア:1)
index張るにしても、色々と数値の方が扱いやすいですから。
問題は設計者だと思います。
客の要望が幾ら文字列IDじゃなければ駄目とか言ってきたとしても
たとえば、内部でアスキーコードに変換して数値処理するとか
隠蔽してしまえば客にはわかりません。
Re:約定件数 (スコア:0)
Re:約定件数 (スコア:0)
いや、現場ではシーケンスIDにVARCHARなんて使いたくはないんですが…
(ORDER BY TO_NUMBER(x)なんてやるのよっ!)
DBセンタの人々が
「NUMBERはつかっちゃだめよーん」
だってさ…
#おかげでエンティティBeanが作れなくて泣き目を見たのでAC
Re:約定件数 (スコア:0)
ハードディスクの容量について記事を書いてしまいました。 (スコア:2, 興味深い)
東証の取引システムのハードディスクが500MBやそこらだと推測される件 [knoa.jp]
Re:約定件数 (スコア:1, 興味深い)
閉まってからバッチ処理するんじゃないでしょうか。
確定報が証券会社に伝わってから、証券会社側でも
一日分の取引を確定するシステムが動くと思われるので
全件処理を有る一定の時間で行う必要があるんでしょうね。
株券実券の管理を証券会社でも東証でもない所が
管理したりもするので、普通のシステムのようには
いかないと思いますが。
あと、10年前のメインフレームの動いている環境って
今見ると結構びっくりすると思いますよ。
Re:約定件数 (スコア:1, 興味深い)
フリーアクセス床から下に落っこちるとコンクリの床まで９０ｃｍくらいあって、骨折か捻挫は確実って？ 床から空調の風がびゅうびゅう吹き出してるって？ １９インチラックなんていっこも見当たらないゼとか？
Re:約定件数 (スコア:1, おもしろおかしい)
Re:約定件数 (スコア:0)
後で検証できるようになってないと怖いと思いませんか？
外部からの注文を全部マッチングさせるわけですから、間違っていてもどこが間違っていたのかを突き止められるようになっていないと。
Re:約定件数 (スコア:0)