トランザクションの最先端研究 | 分離レベルの追跡・究明―TiDBの分離レベルを理解する（上） - Qiita
はじめに 「トランザクションの最先端研究」は、トランザクションに関する最先端の研究内容を皆さんと共有することを目的とします。トランザクションは内容の専門性が高いことから、本稿では順を追った説明を行っていくこととします。後の内容を理解するための土台とするため、まずはトランザクションの基礎理論から話を進めていきます。本稿には次の三つの目的があります。 トランザクションの独立性を明らかにし、よくある認識の誤りについて説明すること。 トランザクションの複雑性について理解し、これを簡略化できるようにすること。 最先端の研究の焦点について理解し、業務・研究に関する示唆を得ること。 最初に共有する内容は、トランザクションの分離レベルの定義に着目したものです。後の内容は全てこれに基づくものであり、分離レベルの最新の学術的定義は広く受け入れられているものではないため、本稿では分離レベルの定義が提示された順に
ざっくり理解するPaxos - 小野マトペの納豆ペペロンチーノ日記
ゴールデンウィーク中、Appleがオープンソースとしてリリースした分散データベース FoundationDB のドキュメントを読んでいました。なかなか面白いデータベースだと思うのでこれについては別途書きたいですが、それはそれとしてFoundationDBでは、分散環境下でACIDトランザクションを実現するために、分散合意プロトコルとして有名なPaxosを採用しているようでした。 PaxosはGoogleのChubbyやCassandraのLight Weight Transactionなどで使われていますが、僕はいまだにPaxosがどのように動作するのかあまりよく分かっていませんでした。良い機会だと思い、FoundationDBの技術を理解するためにも連休の後半でLeslie LamportによるPaxosの論文の一つ Paxos Made Simple を読み、何となくわかった気持ちにな
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として扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
L'eclat des jours(2008-11-20)
_ ACIDからBASE ちょっと勉強。 BASE：ACIDの代わりをどうぞ 要約(のつもりだったがのりで)抄訳：（誤読は十分あり得る） これまでは垂直拡散（うまい訳はなんだろう？ vertical scaling）ってのがひとつの方法だった。よりパワフルなマシンへ移行するという道筋だ。何より簡単だってのがいいところ。でも、問題がある。どこまででもでかくできるわけでもないし、何より金食い虫だ。 それに対して水平拡散（horizontal scaling）ってのもある。いや、でもこれは複雑になる。この場合は、2次元で考えるといいね。横方向は機能分割。縦方向は断片化だ。Oracleのパーティショニングあたりとかかな。 機能分割はいいんだけど、そうなると1つのトランザクションが複数のデータベースサーバーをまたがる必要が出てくる。 エリック?ブルーワっていうバークレーの先生で、インクトミの首席サイ
続ACIDからBASE - L'eclat des jours(2009-11-13)
_ 続ACIDからBASE 以前、acmqueueのBASEに関する記事の前半だけを勝手翻訳したが、続きをwinplusさんが翻訳してくれた。 実のところ、2フェーズコミットという技術は早すぎた自動化だと思う。えらく大層なことと複雑な仕組みではあるけれど、さっきまでオンラインだったシステムは直後もオンラインだろうという程度のあやふやな確信に頼って自動化しているだけのものだ。 よく似たシステムに、同時期にでてきたRPC（ORPCもそうだ）がある。 前提が高信頼性が確保できるクリーンルーム内の複数のノードから構成された分散システムだとしか思えない。それにしてもマシンは落ちるしネットワークは切れる。2フェーズコミットは、絶対に通信が可能だということと相手のプロセス（マシン）が落ちないことを前提としたシステムだという矛盾がある。SYNに対するACKを2時間待ってしまえばすでに成り立たないのだ。 早
分散トランザクションに挑戦しよう！
では、複数のデータベースに対してアクセスする場合、どのようにすれば原子性を保証できるのでしょうか。これを解決するのが、図 2 に示す 2 フェーズコミットと呼ばれる方法です。 2 フェーズコミットでは、図 2 のようにトランザクションのコミット処理を 2 段階のフェーズにわけることによって原子性を保証します。ちなみに図 2 の UML 表記は、厳密ではありません。どのようなメッセージが交換されるのかについてのみ注目してください。 第 1 フェーズでは、まず、各データベースに対してコミットできる状態であるかどうかを確認するための準備 ( 図 2 の prepare ) の指示を送ります。これを受けた各データベースは、コミットできる状態かどうかをアプリケーションに伝えます。この処理を「投票する」と呼びます。コミットができる状態であれば、コミット予定の内容を確定させた後、アプリケーションに対して
日本プログレス株式会社データディレクト製品 サポートサイト — JTA（Java Transaction API）について
Java Transaction API（JTA）は、アプリケーションが、分散トランザクション（ネットワークでつながれた複数のコンピュータリソース上のデータにアクセスして更新するトランザクション）を実行できるようにします。JTA は、トランザクション・マネージャと、分散トランザクション・システム関連のアプリケーション、アプリケーション・サーバやトランザクションの影響を受ける共有リソースへのアクセスを制御するリソース・マネージャとの間の、標準 Java インタフェースを指定します。本ドキュメントでは、このプロセスの概要と、DataDirect JDBC ドライバがどう関連しているかについて説明します。 目次はじめに データベース・アクセス 最も簡単な例：アプリケーションからデータベース アプリケーション・サーバ 分散トランザクションとトランザクション・マネージャ 分散トランザクション処理 J
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
