RDBMSの時代の終わりが見えてきた - きしだのはてな
クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleのMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonのSimpleDB。どれも、基本的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB
mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 － TechTargetジャパン
日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率（ログイン間隔が3日以内）は約62％と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP（OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python）」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア（以下、OSS）でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている（広告配信など周辺機能では
Martin Fowler's Bliki in Japanese - トランザクションレス
http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新：Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって（私もそうだが）トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
YourSQL VS Oracle VS GFS - アンカテ
梅田さんから「シリコンバレー精神」の献本をいただきました(ありがとうございます)。 それで、このエントリは書評ではなくて、ここからインスパイアーされた話。 結論から先に言えば、「EXITの前後でストレージ・エンジンに関わる技術に注目すると、その会社の実態に迫りやすい」という仮説。 EXITとは、ものすごくおおざっぱに言えば、会社を上場すること。 つまり、創業者の私物であったベンチャー企業が社会の公器になること。社会がその会社と契約を交わすこと。「これこれのことを責任持ってやってくれるなら、それなりの金を渡すよ」 その契約の代理人となるのが、日本では株式市場しかない。それに対しシリコンバレーでは、もちろん市場も機動的だけどそれ以外にも、大企業による買収とか、すでに公開している企業との合併とかいろいろな代理人がいる。 多くの場合創業者は会社に残るのだろうが、その役割の中に完全に変化する部分があ
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ABD（はぶにっき 2006/9/30)
not found
リレーショナル・データベースの世界