発表者として参加させていただきました。 発表資料はこちらです（自分でも忘れそうなのでブログにリンク貼っておく） 外部キー制約に伴うロックの小話 from ichirin2501 外部キー制約に伴うロックの小話 追記: 2015/08/22 ブログでも補足したほうが良いかな、と思ったので今更追記することにしました。 どういう資料？ 外部キー制約で発生するロックのお話です。前提として、MySQL(5.5.28)のInnoDBストレージエンジン、トランザクション分離レベルはREPEATABLE-READ, READ-COMMITEDです。上記は検証環境ですが、MySQL5.1 ~ 5.7でも変化していない挙動のはずです。また、InnoDBのロックはインデックスレコードロックなので、インデックスに対する理解が必要不可欠です。発表時間も20分程度ということもあって、その辺りをある程度理解されてる方が
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表 米Googleは現地時間2017年2月14日、ミッションクリティカルなアプリケーション向けの分散リレーショナルデータベース（RDB）「Cloud Spanner」を発表した。現在、公開ベータ版を提供している。 Googleによると、Cloud SpannerはACIDトランザクションとSQLセマンティックをサポートし、トランザクションの一貫性を保証する一方、水平スケーリングと高可用性を実現する。「一貫したトランザクションの従来データベースか、拡張性とデータ分散のNoSQLかで悩む必要がなくなる」とGoogleは述べている。 GoogleはCloud Spannerの利点として、シャーディングやクラスタリングを行わずにRDB管理システムをスケールアウトし、NoSQLデータベースに移行す
第3回 AOPでプログラムをシンプルにする
株式会社DTS ネットワーク事業本部所属。Struts/Springベースのフレームワーク開発，プロジェクト支援に携わる。 今回は，Springで提供されているAOP機能（以下，SpringAOP）について説明します。最初にAOPとは何なのか，どんなメリットがあるのかを簡単に説明します。次に，AOPの基本的な使い方を，サンプルを使って説明します。あなたが普通の業務開発者であるならば，このAOPの使い方を覚えるだけで十分でしょう。 最後に，AOPを自分で作る（正確には「アドバイス」というものを作ります）という，少し高度なことに挑戦します。こちらはAOPを自作する必要が出たときに読めばよいと思います。それでは，さっそく始めましょう。 AOPとは AOPとは，アスペクト指向プログラミング（Aspect-Oriented Programming）のことで，オブジェクトが本来するべき処理と，本来する
WEB開発で必ずついて回るのが、Submitボタン二度押しや戻るボタンを押されるなど、勝手な画面遷移をされないような配慮です。Strutsでは同期トークンという機能でこれらの考慮をサポートしてくれます。 実際にサンプルで、ある画面でSubmitを二度押ししたとき、それを検知して二つ目のリクエストをエラーではじくという事を考えてみます。 同期トークンとは † 同期トークンの機能とは以下の通りです。 あるアクションで、サーバ上でユニークなID(以下、トークン)を生成し、返却するhtmlにhidden等で仕込んでおく そのアクションで、トークンはSessionにも格納しておく 次のリクエストにはhidden内のトークンが飛んでくる 次のアクションで、hiddenパラメタ内のトークンとSessionのトークンが等しいことを確認する 等しければ、正しいリクエストということで処理する。Session内
CakePHPで複数テーブルに対するトランザクションを使う場合 - takami_hiroki’s blog
CakePHPでトランザクションを使用する必要があったのですが、一般的に用いられている方法だと、複数のテーブルを1つのトランザクションとして更新したい場合、コントローラ内での実装がとても分かりにくくなると感じ、異なる実装方法をとってみたので、ご紹介します。 一般的な実装方法とその課題 一般的な実装方法としては、app/models/app_model.phpに、下記のようなトランザクション管理用のメソッドを追加することが多いと思います。基本的に、各モデルクラスは、AppModelクラスを継承しているため、これらのメソッドをどのモデルからも利用可能になります。 function begin() { $db = & ConnectionManager::getDataSource($this->useDbConfig); $db->begin($this); } function commit
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
今月から社内勉強会は、社員が持ち回りで講師を担当することになりました。 初回のテーマは「MySQLのトランザクション」です。 MySQLにほぼ限定した形でトランザクションについて発表をしました。 資料は以下の5章立てになっています。 1.トランザクションとは 2.ストレージエンジン 3.トランザクションの開始と終了 4.ACID特性 5.オートコミット 日頃の業務では、実行したSQLの動作確認をした際に、意図した結果が得られない場合に処理を戻せるように、「begin」で書き始めてトランザクションを開始するようにしています。 しかし、そもそもトランザクションは「失敗した時に戻すための機能」ではありません。 普段から使ってはいるけれど深くは知らなかったトランザクションについてちょっとだけ知識を深めるよい機会になったと思います。 なお、「2.ストレージエンジン」の中で、MySQLで利用できるスト
こちらはブロックチェーンアドベントカレンダー12日目の記事です。 https://qiita.com/advent-calendar/2017/blockchain 今年は価格の暴騰以外にも色々と話題を事欠かないBitcoinですが、その中でもSegwit、Segwit2Xは記憶に新しいのではないでしょうか。 Bitcoinにかぎらず、多くの暗号通貨はそのスケーラビリティに上限があり、それらに対して幾つかの解決策を見出そうとしているのが現状となります。今回はそのスケーラビリティに対する現状について、特にパブリックなチェーンに対するものを中心にまとめてみようと思います。 そもそもBlockchainのスケーラビリティとはVISAカードなどが対処しているトランザクションは秒間4000~6000と言われていますが、Blockchainはその仕組み上、マイナー（PoSではバリデーター）の数が増えて
20140711 MySQL Casual Talks vol.6 / 続・Amazon RDS Casual Talks
(解決済み) DBIx::TransactionManager + File::RotateLogsで意図せずトランザクションが終了してしまう件 - Hateburo: kazeburo hatenablog
DBIx::TransactionManager 1.13で子プロセスでrollbackを実行しないような変更が入っています。 https://metacpan.org/release/NEKOKAK/DBIx-TransactionManager-1.13 TengやDBIx::Sunnyなどでトランザクションを使用し、File::RotateLogsでログを書き出している場合はバージョンアップをお勧めします。 経緯など 某サービスにおいて、DBIx::TransactionManagerを使ってトランザクションを実行している箇所で9時にトランザクションが意図せず終了するという問題がありました。 コードにするとこんな感じ my $rotatelogs = File::RotateLogs->new( logfile => '/path/to/access_log.%Y%m%d%H%M',
この手の「俺は今からこれを読んでログを残すぜー！」的宣言は過去に何度かやって当然失敗してきたのでそんなに期待しないで頂きたい。 Principles of Distributed Database Systems これは御徒町と名乗るトランザクションおじさんが主導して僕も便乗させていただいている本。分散データベースの歴史をANSIの頃からちょいちょい触れながら、どういう風に最適なクエリを実行できるかにフォーカスしている感じの本。SQLとかクエリプランニングとか最適配置とか集合の分割とかそういう話が多く、CAP定理とかトランザクションとかはあまり出てこない。途中までしか読んでないのでそんな印象だけど、今後どうなるかな…？！ 860p Principles of Distributed Database Systems 作者: M. Tamer Oezsu,Patrick Valduriez出
こんにちは市丸です。 Zynga Japanでは単純なPrimaryKeyをキャッシュする際、symfonyのPeerをオーバーライドし自動的にキャッシュ＆クリアしています。 UserPeer.php class UserPeer extends BaseUserPeer { public static function retrieveByPK($pk, PropelPDO $con = null) { if (!$data = /* Cacheからとるよ */) { $data = parent::retrieveByPK($pk, $con); /* "User_$pk"みたいなキーでCacheするよ */ } return $data; } public static function doInsert($values, PropelPDO $con = null) { /* Ca
Part1 トランザクション管理とは何か
日頃，システム構築の開発現場において「トランザクション」という言葉をたびたび耳にします。Part1では，トランザクションの初歩の初歩から分散トランザクション技術までを解説していきましょう。 企業における業務処理の多くは，「確実に遂行されること」が求められます。例えば，「本日の取引は10件で，たぶんすべて成功したと思います」という報告ではなく，「本日は10件の取引を行い，すべて成功裏に完了しました」という報告が必要なわけです。 業務はITを活用することにより効率的に進められますので，ITの世界ではそれぞれの取引が確実に「成功する」ことを保証する仕組みが必要になります。この取引のことを「トランザクション」と言います。具体的には，データベースにアクセスする処理を処理1，処理2，処理3のようにつなげて呼び出す「一連の処理」（処理の固まり）です（図1）。 トランザクションは，次の4つの特性をすべて保
基礎から理解するデータベースのしくみ（11）
表1●トランザクション処理の分離レベルと，それぞれで発生する可能性がある現象。分離レベルは下に行くほど高くなります マルチユーザー環境では新たな問題が発生 ここまでの説明は基本的に，一人のユーザーがデータベースにアクセスしていることを前提にしていました。しかし実際には，複数のユーザーが同時にデータベースにアクセスすることはよくあります。むしろ，受発注システムや座席予約システムなど，実用データベース・アプリケーションのほとんどは，複数のユーザーが同時に使うことを前提にしていると言ってよいでしょう。こうしたマルチユーザー環境では，ユーザーが一人のときには無かったさまざまな問題が起こります。 例えば，ユーザー1がトランザクションの途中で特定のレコードの内容を変更したあとで，別のユーザー2がそのレコードを読み込んだとしましょう。そのあとでユーザー1がトランザクションをロールバックしたら，ユーザー2
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL の Repeatable Read と RocksDB の楽観的トランザクション解説 こんにちは技術研究グループ・テクニカルディレクターの波多野です！ 普段は社内のインフラ、特にデータベース関連の技術的な問題を解決するのを仕事にしています。 弊社ではリレーショナル・データベースとしてはオープンソースの MySQL をとてもよく使っていますが、そんなオープンソースのデータベース界隈で最近よく目にするようになって来たのが 楽観的トランザクション(Optimistic Transaction) という技術です。今回はトランザクション処理の歴史的なところに触れながら、RocksDB に代表される楽観的トランザクションについて簡単に解説したいと思います はじめに MySQL を使っているとデフォルトでは REPEATABLE READ のトランザクション分離レベルになっていて、トランザク
<Insert Picture Here> MySQLパフォーマンスチューニング概要 日本オラクル MySQL Global Business Unit Copyright© 2011, Oracle. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文
米Google（グーグル）は2022年5月に開催した年次カンファレンス「Google I/O 2022」で、新しいデータベース（DB）サービスである「AlloyDB for PostgreSQL」を発表した。 グーグルが2022年5月12日（米国時間）に発表したAlloyDB for PostgreSQLは、同社が独自に開発したDBのサービスで、オープンソースソフトウエア（OSS）のリレーショナルDB（RDB）である「PostgreSQL」と互換性がある。ユーザーはPostgreSQL用のSQLクエリーや拡張機能がそのまま利用できる。 AlloyDB for PostgreSQLの特徴は、トランザクション処理（OLTP）性能とデータ分析（OLAP）性能を両立した点だ。グーグルによればAlloyDB for PostgreSQLは標準的なPostgreSQLに比べて、同じ数のCPUを使用する
DDDにおいて、なぜ複数の集約にまたがってトランザクションをかけてはいけないのか（multiple aggregates in one transaction） - pospomeのプログラミング日記
DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる
開始コマンドがDBMSによってバラバラなのは、標準SQLで明確に決まっていないためです。中にはOracleやDB2のように、データベースへ接続したら自動的にトランザクションが始まることになっているため、開始コマンドのないDBMSもあります。確かに、最初に暗黙に開始されれば、そのあとは終了文だけあれば区切りはわかる（終了文が次のトランザクションの開始文も兼ねる）ので、合理的といえば合理的です。 構造的な単位としてのトランザクション 一方でDBMSの側から見ると、トランザクションは2つの重要な機能に関係しています。それが、「データの復旧」と「同時実行制御」です。まずは、前者から見ていきましょう。 トランザクションは復旧の単位 障害発生前に終了したトランザクション データベースに限らず、システムというのは使い続けていればどこかのタイミングで障害に見舞われます。なるべく障害に遭遇しない堅固なシス
スレッドプールのサイズを調整する
この他にも "サービスを受けるのを待つ人が，キューの中に立っている平均時間はどれくらいか？" といったような疑問に，Littleの法則で答をだすといった内容のゲームは，他にもたくさんあります。 図１. Littleの法則 同じようにLittleの法則は，スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは，リクエストの到着率と，サービスに必要な平均時間を測定することです。そうすれば，これらの値をLittleの法則に挿入して，システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ，その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には，問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合，まず最初に判断しなければならないのは，もっと大きな
はじめに なんか真面目な話にしてしまった事を軽く後悔してます。 なんか空気読めて無くてごめんなさい。 このネタって恐らく7,8年前には語り尽くされた感ありますが、最近DBの質問をよくうけて且ついろんな製品を組み合わせて云々かんぬんみたいな相談があったりで、自分で喋っててアレ？そうだっけか？みたいな疑問が起きたりで頭の整理の為に書きました。 おっさんの理解はこの程度ですが、間違ってたら優しく突っ込んでください。 おっさんはこの業界に入ったばかりの頃、ACIDと初めてきいたときにインコグニートが浮かんだくらいのおっさんです。 そんなおっさんなりに今まで学習した内容をまとめてみました。 ACID特性 トランザクションシステムはもっとこうよっていう特性です。 逆にいうとコレがないとトランザクションとしては信頼できないっていうものです。 MySQLやPostgreSQL,Oracle等の関係データベ
multiversionの基礎 自分用のMulti Version Concurrency Controlのまとめ MVCCの基礎理論をまとめておく。今後はここを参照する。 基本的にTX本とCC本から必要な部分をまとめている。 （一回まとめてるけど、Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道 前回はそもそもCSRとの混線を防ぐという意味だったので、今回はもっと基本的なところからさらに。今回はCSRとの関係はガン無視。） 前置き：自分の考えを記録的に 基本的にMulti Version Concurrency Control （以下MVCC）は理論先行だった。これはMVCCのオーバへードがsingle-versionのパフォーマンスを凌駕できなかったことによる。以下の理由によりMVCCが今後は伸張すると考えている。 1.メモリー
Microservices の裏で動く Microservices を Go で開発している話 | メルカリエンジニアリング
Mercari Advent Calendar 2018 の 25 日目はメルカリ JP の Microservices Development Team の @codehex がお送りします。 これまで私達は Microservices を開発している旨を様々なテックイベントやカンファレンスで話してきました。中でも Mercari Tech Conf 2018 で Monolith なアプリケーションから Microservices へ移行するために、私達がどうしているかという話が目立っていたと思います。 そのうちの一つである Listing Service という出品機能の Microservice の話がありました。 資料の内容をまだ知らない方のために、本記事を理解するために補足します。 メルカリでは Microservices を基本的に Google Cloud Platform
モデルでbegin()とかやってはいけない気がする。 Overloadableを継承してるので、メソッドが定義されていない場合は call__()がコールされる。 ベヘイビアとか登録してたらそっちが呼ばれるけど、通常は使わないと思うので データソースのquery()が呼ばれる。 query()内では、メソッドをテンプレートとして引数をバインドしてSQLとして呼ぶと思うので、 begin()とかやると、"BEGIN"というSQLがコールされる。 PostgreSQLだとまさにこれはトランザクション開始のコマンドなので 動作してるように見えると思われる。 でもね。データソースにはちゃんと begin() commit() rollback() っていうメソッドがあるからこっちを使うはず。 モデルのsaveAll()内でもそうしてる。 ということで、モデルにメソッドがないのが困ったけど、以下で解
はてなブログ | 無料ブログを作成しよう
ハリイカの焼売と中華炒め ハリイカをよく、見かけるようになりましたよ。生け簀で、泳いでいたものを一杯購入しました 立派な大きな墨袋や肝は冷凍保存して 柔らかな身は季節のお豆、お野菜と合わせて中華の炒めものに。新鮮なにんにくの茎は刻み、香り高く食欲そそられますね 下足はミンチにし…
「グローバルトランザクション」という言葉の意味について、昨日の飲み会で議論になったので、まとめ。 グローバルトランザクションと分散トランザクション グローバルトランザクションは、分散トランザクションと同義です。グローバルトランザクションは複数のリソースマネージャを含むトランザクションを指します。一方、ローカルトランザクションは単一のリソースマネージャ（DB等）のみで構成されるトランザクションを指します。 http://download.oracle.com/docs/cd/B14117_01/java.101/b10979/xadistra.htm#i1066628 A distributed transaction, sometimes referred to as a global transaction, is a set of two or more related transac
排他って何だろう
福岡寿和 FUKUOKA，Toshikazu 富士通SSL はじめに 同時にひとつの資源を複数のプログラムから使おうとしたときは，必ず「排他」というものが必要です．今回は，いろいろある排他問題の中から，RDBMSの世界での「排他」，特にレコード変更（挿入・更新・削除）に関係するものに注目してみます．なお，今回のリストプログラムは，Oracle Objects for OLEをミドルウェアとして，Oracle7またはOracle8をターゲットにしています．また，事前にリスト1を実行して，テスト用のテーブルを作成してください． リスト1：サンプル用定義スクリプト DROP TABLE VBMArea CASCADE CONSTRAINTS; CREATE TABLE VBMArea ( AreaCode CHAR(2) NOT NULL, AreaName VARCHAR2(10) N
トランザクション分離レベルの種類 ANSI/ISO SQLでは、以下のように定義されています。 ロストアップデートについては特に策定されていないと思いますが、一覧に加えておきます。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロストアップデート read uncommitted 高 起きる。 起きる。 起きる。 起きる。 read committed ｜ 起きない。 起きる。 起きる。 起きる。 repeatable read ｜ 起きない。 起きない。 起きる。 起きる。 serializable 低 起きない。 起きない。 起きない。 起きない。 ただし、ANSI/ISO SQLはあくまで仕様であって、実装・動作は各データベース毎に異なります。 MySQLの場合は以下のようになります。 分離レベル 性能 ダーティーリード ファジーリード ファントムリード ロス
データベースコンサルタントのノウハウちょい見せ ACIDを超える概念か？ 新しいトランザクションの考え方 - BASE
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります DB使いであれば、ACID(Atomicity、Consistency、Isolation、Durability)は当たり前の考えかと思います。実は、DBMSならACIDが当たり前というのは、思いこみと言っても良いのです。少なくとも、ACID以外の考え方が存在するのは事実です。 今回は、そんな考え方である、BASE(Basically Available、Soft state、Eventually consistent)を紹介します。クラウドなどの世界で徐々に広がりつつある、トランザクションの考え方です。 この記事は、「BASE: An A
基幹系システムでCloud SQLは使えるか試してみた：Google Cloud SQLは基幹系で使えるのか（後編）（1/4 ページ） 生産管理システムで「再帰呼び出し」の速度を検証 グーグルはGoogle App Engine（以下、GAE）から利用できるRDB（MySQL）の「Google Cloud SQL」（以後Cloud SQL）の提供を“Limited Preview（限定プレビュー）”としてアナウンスしています。前回の「」では、ローカル環境でCloud SQLを動かすための準備・設定などを中心に見てきました。今回は、下記の3つのポイントを中心に見ていきます。
レプリケーション設定 - phpspot
レプリケーションの設定をするには、まずコピー元であるマスターとコピー先であるスレーブにマシンを分けて考えます。マスター、スレーブ、それぞれに別の設定が必要です。 その設定は以降に書きます。 マスターのマシンで以下のSQL文でユーザを追加する。 mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@"192.168.1.0/255.255.0.0" IDENTIFIED BY 'pass';
Ground-SunLight
— y2sunlight ,Since 2019-10-02 Ground Sunlight は「Windowsで作る - PHPプログラミングの開発環境」をテーマにしたサイトです。 オープンソースを利用している全ての人達に祝福を！
MySQL + InnoDB で SELECT ... FOR UPDATE 使ったときのメモ - ねじろぐ @drillbits
登場人物 どりるび：SIer時代はDBチームにDBを任せ、その後はゆるふわKVSを使いつづけることでRDBとの戦いを避けてきた。罪深い。 あらすじ のっぴきならない事情で、一意制約がかけられないにも関わらずテーブルに同一のデータを存在させたくないってことがあった。 例示であり実際のコードや所属する団体とはアレです。 user カラムはid（AUTO_INCREMENTなプライマリキー）とscreen_nameとis_deleted screen_nameの重複したデータは作りたくないが、例外としてis_deleted＝TrueなものはOK こんなかんじ ID screen_name is_deleted 1 ibusem False 2 d_osamu True 3 d_osamu True 4 d_osamu False で これだとアプリケーションレベルで存在チェックをかけた後にインサ
いろんなAnomaly - Qiita
昨日様々なトランザクション分離レベルに付いて書いた。 AnomalyとはSerializableでない実行を引き起こす異常状態パターンのことを言う。 弱い分離レベルほどAnomalyが起きやすい。 これから図を交えながらAnomalyについて説明する。 図中の「W(x)」は「xに何らかの値を書き込む」、「R(x)」は「xの値を読む」をそれぞれ意味する。 分かりやすいようにReadは青、Writeは赤色で統一する。 また、Anomalyの被害に遭うのは常にT1に統一する。 Cはコミットを意味する。 Dirty Read Anomaly 未コミットな値を読んでしまうAnomalyの事。Readがロック関係なしに値を読んでしまう場合などに起きる。 T1が書き換えられる最中のxの値を読んでしまっている。もしT2が途中でアボートしたらT1はどこにも存在しない値を読んだ事になってしまう。 READ U
トランザクションとは - IT用語辞典
概要 トランザクション（transaction）とは、商取引、売買、執行、取扱、議事録などの意味を持つ英単語。ITの分野では、取引記録など一般的な意味の他に、ソフトウェアがデータを処理する際、互いに関連・依存する複数の処理をまとめ、一体不可分の処理単位として扱うことを指す場合が多い。 データベースシステムや業務用ソフトウェアなどでよく用いられる概念で、金融機関のコンピュータシステムにおける入出金処理のように、一連の操作を全体として一つの処理として管理することを「トランザクション処理」（transaction processing）という。 ひとつづきのトランザクションとして登録された複数の操作は、必ず「すべて成功」か「すべて失敗」のいずれかとなるようシステムによって実行状態が管理される。処理の開始後、途中でいずれかの操作が失敗したら、それまでに行われた操作を取り消して最初からやり直す制御が
TiKVにおけるトランザクションとMVCCの話
はじめに PingCAPの小板橋です。はじめまして！ TiDBの入門記事から上級者編まで幅広く取り扱う本アカウント第5回目は「TiKVにおけるトランザクションとMVCCの話」についてをまとめていきたいと思います。 TiKVの仕組み まずは、TiKVの仕組みについてを見ていきましょう。 全体のTiDBクラスターのアーキテクチャについては、下記の記事をご覧ください。 TiDBクラスターにおけるデータレイヤーにあるストレージノードとしてTiKVと呼ばれるものがあります。 TiKVは、分散型のキーバリューデータベースになり、ACIDに準拠したトランザクションAPIを提供しています。このTiKVの裏には、RocksDBとRaftコンセンサスアルゴリズムによって動作しています。 Raftコンセンサスアルゴリズムについては、また別の記事で深ぼっていきます。(こちらはこちらでお楽しみに！) RocksDB
データベースの同時実行性の定義データベースにおける同時実行性は、同時に共有データにアクセスしたり、 共有データを変更したりする複数プロセスの機能性として定義することができる。 互いにブロックすることなく同時に実行できるユーザプロセス数が多いほど、 データベースシステムの同時実行性は高いといい、データの変更プロセスによって、 他のプロセスがその変更データを読み取りできなかったり、 データの読み取りプロセスによって、他のプロセスがそのデータを更新できない場合、 同時実行性が低いという。また、複数プロセスが同じデータを同時に変更しようとすると 常にデータの整合性が損なわれるような場合も、同時実行性が低いと言える。 同時実行性が低くなる状況に対処する方法データベース システムで同時実行性が低くなる状況に対処する方法は、 使用している同時実行制御がオプティミスティック(楽観的)*1かペシミスティック
バージョンはSpring4.2.X系 Springでのトランザクション管理 Springのトランザクション管理は大きく分けて以下の2つの管理方法が存在する。 1.プログラミングによるトランザクション管理 プログラミングによってトランザクションを手動管理する方法。以下のようなイメージでトランザクション制御コードをソースコード内に記述する。 transactionManager.begin(); transactionManager.commit(); transactionManager.rollback(); ソースコード内にトランザクション制御コードも入りこむため、見通しが悪くなったり制御を間違えるとバグの温床にもなったりするので、極力使うべきではない。 2.宣言的トランザクション管理 「あるメソッドを呼び出したときにトランザクションをかける」と宣言する方法。以下のようなイメージでメソッ
RDBMS/SQL の話のなかで、基礎的な知識として必ずでてくる(であろう) 4 種類のトランザクション分離レベル (transaction isolation levels) ですが、腑に落ちたことがなく気持ち悪い印象をもっていました。そこで、差異を正しく理解すべく、 Bernstein さん、 Jim Gray さんたちの論文を読んでみました。個人的に興味のある点は、 Phantom Read とは何か? と Snapshot Isolation はどの程度の隔離レベルか? という 2 点です。 PostgreSQL のトランザクション分離 PostgreSQL は read committed と serializable のトランザクション分離レベルを実装しています。 In PostgreSQL, you can request any of the four standard t
![[database] トランザクション分離レベルのメモ - いたわさににほんしゅ](https://cdn-ak-scissors.b.st-hatena.com/image/square/4394835a1249a3eb6177a5b0ecddf83d2da32974/height=288;version=1;width=512/http%3A%2F%2F4.media.tumblr.com%2Ftumblr_ksb99wiA0A1qz5rvdo1_400.jpg)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「外部キー Night」に参加してきた - ichirin2501's diary
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表
Struts/同期トークンで二度押しなどをチェックする - きのさいと
分散合意アルゴリズム Raft を理解する - Qiita
社内勉強会(1) – MySQLのトランザクション | アロハ技術者ブログ
暗号通貨のスケーラビリティについて考える
mysqlcasual6-next-key-lock
技術書を読む読む詐欺 - kuenishi's blog
ウノウラボ Unoh Labs: MemcacheとMySQLのデータ不整合をPropelPDOで解決してみる
先進事例に見る経営とIT 〈攻める〉 ANA、脱メインフレームで70億円削減へ
(pdf) MySQLパフォーマンスチューニング概要 - Oracle
グーグルのHTAP対応PostgreSQL互換DB「AlloyDB」、データ分析性能は最大100倍
第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ（1） | gihyo.jp
おっさんがACIDとかBASEとかまとめておく。 - Qiita
multi-versionの基礎 - 急がば回れ、選ぶなら近道
CakePHP 1.2 でトランザクション - bobchinの日記
グローバルトランザクション／分散トランザクションについて - スティルハウスの書庫の書庫
tree-tips: MySQLのトランザクション分離レベル | MySQL
基幹系システムでCloud SQLは使えるか試してみた
トランザクション同時実行時の問題とトランザクション分離レベル - Bug Catharsis
Springでトランザクション管理 - Qiita
[database] トランザクション分離レベルのメモ - いたわさににほんしゅ