木走日記 - 抜本的改良は手遅れな東京証券取引所システム〜問われる技術立国日本の脆弱性
●実は手遅れな東京証券取引所のシステム処理能力拡大策 東証の社長が株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明したそうです。 【東証問題】「約定能力を700万件以上に引き上げたい」、西室社長兼会長が表明 東京証券取引所の西室泰三社長兼会長は1月19日、株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明した。現在のシステムでは、1日当たり450万件が限界。1月30日のシステム刷新で約定処理能力を500万件まで拡大するが、さらなるシステム拡張をしたいとの考えを示した。 東証は1月18日、ライブドアの強制捜査開始による影響で約定件数がシステムの限界に迫り、午後2時40分に東証1部・2部・マザーズ市場の全銘柄の取引を強制的に停止した（関連記事1、関連記事2）。当日の会見で、東証は「年内にも1日の注文処理能
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
[ぴ] - ライブドア 次世代テクノロジーセミナー
_ [システム運用] ライブドア 次世代テクノロジーセミナー わざわざ午後半したのに退社するのが遅れたり家に財布忘れたりで20分遅刻。 色々抜けがあるけどとりあえずざっくりとメモ。 使ってる OS はほとんど (9割方) FreeBSD 4、一部 Turbolinux 8 ・FreeBSD 4.x (5.x は Perl の扱いが…) ・Apache 1.3 (2.0は mod_perl の互換性が…) ・MySQL 4.0 (4.1は日本語の取り扱いが…) ・Perl 5.8 (これだけは最新の Stable でも問題ない)ライブドアは延べ13人の CPAN Author を輩出 (でも今残ってるのは3人だけ)オン・ザ・エッジ (後にエッジに改名) の頃は Total Internet Solution というキャッチで、主に Web サイト構築の受託。この中で、フレームワーク Sled
![[ぴ] - ライブドア 次世代テクノロジーセミナー](https://cdn-ak-scissors.b.st-hatena.com/image/square/d228e8be070c32c738781e15c25aeb18f4dc6807/height=288;version=1;width=512/https%3A%2F%2Fpmakino.jp%2Ftdiary%2Ftheme%2Fogimage.png)
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
Server File Cache → Storage
4. Server File Cache → Storage 図4. nfs request flow 本章では図4の赤い部分、 Server File Cache から Storage までの経路に焦点を当てる。 ここは最後のパス、 Storage と IO しなくてはいけない 場合に必ず通るパスである。 図上では Server File Cache, Local File System, Storage は 3つの異なるユニットであるかのように描画しているが、 実際にはこの3ユニットの性能と特性は互いに影響しあって 全体で1つの性能を引き出す。 このため、この3つのユニットはバラバラに評価するわけには行かない。 普通に言う場合は、 この3つのユニットの性能を逢わせて Local File System の性能 と呼ぶ。 広義の nfs では、 Storage の部分は他の物にもなりうる
パレートの法則 8:2の法則
パレートの法則（パレートのほうそく）は、イタリアの経済学者ヴィルフレド・パレートが発見した冪乗則。経済において、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとした。80:20の法則、ばらつきの法則とも呼ばれる。 パレートは所得統計を分析して、所得分布が安定的であり、時代によって変化しないという結論を出した。この結論からは、社会の所得格差は平等にならないが、不平等も強化されないことになる[1]。パレートの法則は、関数のパラメータ（パレート指数）によって所得分布を時間・空間的に比較したもので、貧困についての最初の数学的な研究ともいわれている[注釈 1][3]。 しかし、パレートが発表した当時から難点があった。パレートの法則は低所得層に当てはまらないという問題があり、パレート自身も認めていた[3]。パレートが用いた統計はイタリアやスイスのいくつかの都市と、プロイセン王国と
PofEAA's Wiki - CatalogOfPofEAA
原文: http://www.martinfowler.com/eaaCatalog/index.html Last Significant Update: January 2003 以下は、『Patterns of Enterprise Application Architecture (P of EAA)』で扱ったパターンの簡単なサマリである。 各パターンの概要をページ毎に載せているが、パターンは単独で用いられることを想定していない。これは、パターンに馴染みのある人向けの、単なる覚書のようなものである。これで気軽にオンラインでパターンを参照することが出来ましょうぞ。 将来的にここにコメントを追加するかもしれないが、とりあえずこれがうまく行くことを見守ろう。 David Heinemeier Hanssonが私のために素晴らしいダイアグラムを書いてくれたんだが……このVisioが吐いたG
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
