Optimistic Concurrency Controlについて - Qiita
コミットまでロックを獲得せずに実行する方式の並行制御方式。 まず、更新のたびにバージョン番号が増加する複数のデータを読む際、読んだデータのバージョン番号とデータのペアで手元で保持しておけば、再度読んだ時にバージョン番号の変動を確認すれば値が書き換わっていないかを検出できる。 この図の中の緑色の領域の中で値が変わっていない事をバージョン番号から保証できる。 これは対象となるデータがいくつに増えても同様である。 こうすれば複数の値を論理的に一瞬で読めた事になる。これを一般にスナップショット読み出しと言う。 これに2PLを組み合わせる事で、トランザクション中で読み書きする値に一切ロックをかけずにコミット時のバージョン比較で代用できることになる。 Optimistic Concurrency Control(OCC)はこの考え方を拡張したもので、トランザクション実行中は 値を読み出す時はバージョン
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
バッファ管理とWAL - Qiita
データベース内のデータはページ単位でHDD内に配置され、ページ単位でメモリにバッファ及びキャッシュとして複製される。 HDD内のデータにアクセスする際は一旦メモリにページごと複製してからアクセスするわけだが、メモリ内におけるページの量は一般にHDDに置けるページ量より小さい（そうでない前提での話題はまた後日）。 LRU どのページをメモリに写し、どのページをHDDに置くかというのは、基本的にディスクアクセスの量を最小化する方向に最適化をする。 その際にはLeast Recently Used(LRU)という方法でキャッシュを管理する事が常套手段である。 それは「一番最近からみて使われた頻度が一番少ないページを解放して、そのメモリ領域を新たなディスクページの為に使いまわす」という戦略である。 具体的な実装方法としては双方向線形リストを使う。 新たにページをメモリに複製した際、双方向線形リスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
