DBトランザクションメモ(Hishidama's database transaction Memo)
いずれにしても、そのレベル（範囲）において、整合性がとれていなければならない一連（ひとかたまり）の処理を意味する。 レベルの違いを除けば、欲しい機能（トランザクションに求めれられる事）は同じ。 すなわち、一連の処理中に同じデータに対して他の処理が更新をかけることが無いようにしたい。 一連の処理が途中で中断された場合、半端な状態になるのは困るので、何らかの対処が欲しい（トランザクション処理開始前の状態に戻るとか）。 当ページで扱いたいのは、データベースが持つ仕組みとしてのトランザクション。 特に、それを使ってどうプログラミングするか・その為にどういう設計が必要か、という考察。 RDBのトランザクションの使用方法 リレーショナルデータベース（RDB）においてデータ（テーブル）を更新するには、トランザクションを使用する。 DBアクセスする為には、クライアントからDBへ接続（connect）する。
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。 まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。 DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。 他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。 ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択す
クラウド上のリレーショナルデータベースはなぜ難しいのか？ 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）についての具体的な内容の
【Google App Engine】 Entityとトランザクション３
Scaleするかどうか、それが問題だで主張したとおり、クラウドではスケールしなければ意味がない。以下は、GAEで大規模な処理をやって、特にトランザクション処理で悪戦苦闘した際のメモである。本日の発表資料＝＞ココにも含まれている。 大量データをINSERTできない件について 先日、Entityとトランザクション２において、Ownedな関連を使ったUpdateサンプルを紹介したわけだが、実はこれ、大量データをINSERTすると急激に遅くなるという問題を含んでいることがわかった。実際にテストしてみたところ、15000件を超えた時点でタイムアウトが頻発、15300件からはとうとう1件も登録できなくなってしまった。 com.google.apphosting.runtime.HardDeadlineExceededError: This request (c1fe232d20adabba) star
ACIDからBASE（勝手に後半） - winplusの日記
先日の記事で触れたL'eclat des jours(2008-11-20)の続きを、勝手に試みた。調子を合わせようとしたけれど無理。全然こなれないし、誤訳もいっぱいあると思うが、参考までに公開しておく。 BASE：ACIDの代わりをどうぞ ■Consistency（一貫性）のパターンいくつか ブルーワのいうとおりなら、BASEは、分散と可用性をとるかわりに、どこかで一貫性を諦めるしかない。これは難しい。というのも、ビジネス関係者も開発者も「一貫性がいちばん重要だ」というんだ。一時的な矛盾であってもエンドユーザに見えてしまうので、ビジネス関係者と開発者の両方で、どこで一貫性を諦めるかを決める必要がある。 図2はBASEが考える一貫性を説明するための簡単なスキーマだ。userテーブルは、売上総額と購入総額も含めたユーザ情報をもっている。売上総額と購入総額は現時点での合計額だ。transact
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
