CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性） 一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。 一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと
VOYAGE GROUP エンジニアブログ : MySQL InnoDBでのネクストキーロックの落とし穴
2010年06月30日14:34 カテゴリDB MySQL InnoDBでのネクストキーロックの落とし穴 はじめまして、株式会社ECナビ システム本部 情報システムグループの三浦と申します。 私は主にデータベースの運用、管理を行っています。 ECナビでは様々なサービスを展開しています。そしてそれと同じ数と言っても良い程のデータベースが稼動しています。 リレーショナルデータベースがメインでサービスを支えていますが、それを補う形でキーバリューストア的なデータベースも多数存在しています。 メインで活躍しているリレーショナルデータベースは用途によりOracle、MySQL、Netezza等と多岐に渡っています。 今回はMySQL InnoDBで実装されているネクストキーロックの落とし穴をデッドロックと絡めて説明したいと思います。 評価環境のMySQLのバージョンは5.1.39、トランザクション分離
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
IPA ISEC セキュア・プログラミング講座：C/C++言語編 第4章 不測の事態対策：レースコンディションの一般的対策
レースコンディションとは、並列動作する複数の存在（プロセスやスレッド）が同一のリソースへほぼ同時にアクセスしたとき、予定外の処理結果が生じる問題である データベース更新トランザクションの競合も、そのひとつの例である。あるトランザクションがひとつのレコードを読み取って処理し新しい値を書き戻そうとしているとき、その書き込みが終わる前に別のトランザクションが更新の目的で同じレコードからの読み出しを始めると、結果としてこのレコードには不適切な値が書き込まれることになる。 (1) インテグリティの喪失 並列処理の中で生じる問題にはさまざまなものがあるが、セキュリティ脆弱性の観点からは、レースコンディションを情報のインテグリティが損なわれる問題として捉えることができる。 例えば、あるプロセスPでは次のような手順の処理を行う。： これと並行動作するプロセスQがステップ1と2の間のタイミングで情報ソースを
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
Welcome back to the TRANSACTION! - 急がば回れ、選ぶなら近道
最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか？というお話から始めます。もう枯れてんじゃないか？今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの（RDBMSとは限りません）が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」
データベースの不整合（ロストアップデート）と戦おう！ - スマートフォンアプリ開発会社のエンジニアブログ
こんにちは。WEBチームの[twitter:@k2w4t4h]です。 最近ではプロジェクトのチェック役としてのお仕事も多くなってきました。 ガラパゴスには4KBもあるSQL文を平然と書いてくる人もいれば、そんなことはExcelでやればいいのにと思うことをDBでやっている人もいます。 そう、ガラパゴスは、OSSのDBだけでも、MySQL、PostgreSQL、Firebird、Memcachedなどを使用しており、DBが大好きな会社なんです。 DBでアルバイトが宗教戦争している会社も珍しいような（笑） しかし、そんなガラパゴスでも、トランザクションを使用していても起こってしまうDBの不整合は見落とされがちです。 そこで、トランザクション使用時に起こるデータベースの不整合を防ぐ方法について、社内研修を兼ねて、まとめてみようかと思います。 準備 こんなテーブルがあったとします。 CREATE T
データベース設計で派生関係は難しい - プログラマの思索
@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そんなトランザクションマネージャで大丈夫か？
分散キーバリューストア上でのトランザクションの実装
基幹系システムでCloud SQLは使えるか試してみた