タグ

トランザクションとCAP定理に関するhondamsのブックマーク (5)

  • DBトランザクションメモ(Hishidama's database transaction Memo)

    いずれにしても、そのレベル(範囲)において、整合性がとれていなければならない一連(ひとかたまり)の処理を意味する。 レベルの違いを除けば、欲しい機能(トランザクションに求めれられる事)は同じ。 すなわち、一連の処理中に同じデータに対して他の処理が更新をかけることが無いようにしたい。 一連の処理が途中で中断された場合、半端な状態になるのは困るので、何らかの対処が欲しい(トランザクション処理開始前の状態に戻るとか)。 当ページで扱いたいのは、データベースが持つ仕組みとしてのトランザクション。 特に、それを使ってどうプログラミングするか・その為にどういう設計が必要か、という考察。 RDBのトランザクションの使用方法 リレーショナルデータベース(RDB)においてデータ(テーブル)を更新するには、トランザクションを使用する。 DBアクセスする為には、クライアントからDBへ接続(connect)する。

  • 結果整合性(Eventual Consistency)についての分かりやすいプレゼン資料

    クラウドとキーバリュー型データベースなどの登場によって注目を集め始めたのが、これら分散システムの基礎的な理論ともいうべきCAP定理と結果整合性(Eventual Consistency)です。それぞれがどういうのものなのか? を分かりやすく解説したプレゼンテーションの資料がSlideshareで公開されています。 作成者はRESTエバンジェリストの山陽平氏。4月17日に行われたyokohama.pm横浜Perlモンガーズのテクニカルトーク)で行われたプレゼンテーションの資料です。

    結果整合性(Eventual Consistency)についての分かりやすいプレゼン資料
  • クラウド上のリレーショナルデータベースはなぜ難しいのか? BASEとCAP定理について

    今週18日からマイクロソフトがラスベガスで「MIX09」を開催します。Windows 7やWindows Azureが発表された昨年秋のPDC(Professional Developers Conference)とは異なり、MIXはWebデザイナーとWebデベロッパー向けのイベントです。 ところで、デザイナーとデベロッパー向けのイベントといえばアドビシステムズのイベントが有名。その名称はたしか「MAX」ですよね......。 さて。MIX09ではWindows Azureの料金体系の発表があるかもしれないといわれています。もし発表されれば、IT系メディアのヘッドラインを飾ることでしょう。 僕が注目しているのは、先日「マイクロソフトがクラウドでリーダーシップを握る可能性が高まる」で書いた、SQL Server完全互換の「SQL Data Services」(SDS)についての具体的な内容の

    クラウド上のリレーショナルデータベースはなぜ難しいのか? BASEとCAP定理について
  • yohei-y:weblog: CAP と BASE について調べたこと

    時系列で 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る CAPとBASEの基礎ができる http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/ 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表 CAP は Brewer 予測として知られるようになる この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化 ここで Brewer の CAP が晴れて定理となった この間、よくわからず 2007年-: eBay の

  • NoSQL登場の背景、CAP定理、データモデルの分類

    その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLORM(Object-Relational Mapping)では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ

    NoSQL登場の背景、CAP定理、データモデルの分類
  • 1