明日のためにその１：トランザクション処理に依存しすぎない - masayang's diary
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） 分離レベルがデフォルト（read comitted）のままだと，恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか？ 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
FriendFeedにおけるMySQLへの大規模データ格納 - masayang's diary
非RDBだのKey-Valueだのと騒がしい今日この頃ですが皆様いかがお過ごしでしょうか。私は元気です。先日、ベイエリアクラウド勉強会で教えてもらったHow FriendFeed uses MySQL to store schema-less data(FriendFeed流・スキーマレスデータのMySQLへの格納)を適当に翻訳してみますよ。(原文はCreative Commonsライセンス) 背景 FriendFeedではすべてのデータをMySQLに格納している。利用者の増加に伴い、FriendFeedのデータベースも拡大してきた。現時点では2億5000万件以上の記事が登録されており、これにコメントやお友達一覧のお気に入りなどのデータが加わる。 データベースの急成長に伴ない、規模に関する課題にも段階的に対処してきた。基本的な対処はおこなってきたつもりだ。具体的には、読み取り専用スレーブの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
