セコイアセコイアデータベースSequoiaDB]テック| SequoiaDB分散トランザクションの実装原理はじめに

分散トランザクションの背景

より成熟したとなり、分散データベース技術の発展に伴い、分散データベースのための業界の要件は、コアトレーディング業務へのエッジのこのタイプを読み取るために大規模なデータ・ストレージ・ソリューションとビジネスの変革を満たすためだけでした。分散データベースのコアを使用すると、このような取引のニーズを満たすために必要な場合、それは、従来のリレーショナル・データベースと一致して、分散トランザクションを改善する必要が占めています。それはまた、必要に応じて、取引の標準的な定義を満たし、ACID特性ことをするために、従来のリレーショナルデータベーストランザクションのような分散トランザクションを実現する必要があります。

データは、データベースには大きな困難をもたらした分散トランザクションを実現するために、このストレージ・アーキテクチャマルチマシンマルチノード分散ストレージで配布しました。操作データトランザクションは、トランザクションの動作が実行さまで異なる記憶場所へのデータの分布、及びネットワーク異なるディスクに配置異なるマシンの格納場所と組み合わされる場合。

取引の基本的な考え方

2.1トランザクションの使用シナリオ

バンキングアプリケーションは、古典的なケースで、トランザクションアプリケーションの必要性を説明することができます。銀行は（チェック）のアカウントテーブルをチェックし、データベースには2つのテーブルを持っていると仮定し、貯蓄は、テーブル（保存）を占めています。今、彼女の普通預金口座LiLeiチェック口座振替から200元に、あなたは少なくとも3ステップの操作で完了する必要があります。

1.チェックチェック勘定残高は200以上です。

2.減算当座預金口座の残高から200元。

預金口座200の残高を追加します。3.。

ステップが失敗した場合すべての操作を単一のトランザクションにパッケージが実行されている、それはすべてのステップが完了しているロールバックします。トランザクションの操作は、一般的にSTART TRANSACTION文は、トランザクションを開始します使用し、COMMIT文とトランザクション全体が行われた変更を元に戻すROLLBACK文でトランザクション全体を永続的にデータを修正するために提出した、またはロールバック。サンプル総務SQL操作は次のよう：

START TRANSACTION;SELECT balance FROM check WHERE customer_id = 10233276 ; UPDATE check SET balance = balance - 200.00 WHERE customer_id = 10233276; UPDATE save SET balance = balance + 200.00 WHERE customer_id = 10233276; COMMIT;

この運転トランザクション転送クラス交換のための銀行のためのシナリオを使用しなければならないが、実際の生産環境、はるかに複雑よりもトランザクション操作の複雑さインチ

2.2トランザクションの概念と機能

トランザクションがアクセスする一連の操作であり、そのようなSQL CRUD操作のポートフォリオの様々なタイプなど、コレクション内のデータ項目、様々な種類のデータベースを操作します。これは通常、トランザクションと終了トランザクション文を始めることで定義されます。

トランザクションデータベースシステムは、次の機能が含まれている必要があります：

アトミック（原子性）：データベース内のすべてのトランザクションでの操作や実行がすべて成功するか失敗します。
一貫性（対応）：操作の前と後の取引、データの整合性が一致している必要があります。
分離（隔離）：複数のユーザデータベースへの同時アクセスは、ユーザが各トランザクションのデータベースを開いたとき、操作データが他のトランザクションによって妨害することができません。システムを感じていない各トランザクションは、同時に他のトランザクションを実行する必要があります。
永続性（耐久性）：トランザクションが正常に完了した後、それはシステム障害がトランザクションには影響しない場合でも、永続的でなければならないデータベースに変更されます。

トランザクション分離レベル

トランザクションの分離のために、内部および外部のトランザクションへの変更を定義し、特定のルールの数を含む、分離レベル4種類のSQL標準定義は、表示されていないれ、表示されています。ここでは4分離レベルは以下のとおりです。

READ UNCOMMITTED（コミットされていないコンテンツを読みます）

READ UNCOMMITTED分離レベルでは、すべてのトランザクションがコミットされていないトランザクションの結果を「見る」ことができます。コミットされていない、とも呼ばれる「ダーティリード」を読みます

READ COMMITTEDは（読み取り提出）

ほとんどのデータベース・システムのデフォルトの分離レベルは、コミット読み取りされます。それ以前に分離され、単一の定義を満たしている：最初に1つのトランザクションでは、唯一の「参照」任意のデータを送信する前に開始されてからの取引を行うために会社を変更することが提出されました変更は表示されません、しない限り提出。この分離レベルは、「反復可能読み取り」操作をサポートしていません。ユーザーが結果を確認するために、二度同じ文を実行し、この手段が異なっています。

REPEATABLE READ（再読み込みすることができます）

問題を解決するためのREPEATABLE READ分離レベルは、READ UNCOMMITTED分離レベルを引き起こしました。これは、データが読み込まれたときに、同じトランザクション複数の同時インスタンスは、それが行「を参照してください同じ」になることを保証します。マジック読書（ファントムリード）：しかし、理論的には、それは別の厄介な問題につながります。ユーザは、ファントムを読み取ることを意味するが、範囲内の新しい行を挿入することによって、データ行の範囲、別のトランザクションを読み取る簡単に言えば、ユーザが範囲データ列を読み出すとき、「新しいを見つけますファントム「行。データベースのストレージエンジンは、MySQLのInnoDBのファルコンなどの問題を、読んでファントムを解決するために、マルチバージョン同時実行制御（マルチバージョン同時実行制御）機構とすることができます。

SERIALIZABLE（直列化可能）

SERIALIZABLE分離レベルは、問題ファントムリードを解決するように、互いに競合することができなくなって、トランザクションによってソートに強制され、最高レベルです。簡単に説明するとは、SERIALIZABLEは、データ読み出しの各行にロックされます。このレベルでは、タイムアウトやロック競合現象の多くにつながる可能性があります。データベース・アプリケーションはほとんどのユーザーが、この分離レベルを選択見ません。しかし、安定性のデータは、還元を強制的に同時の必要性のためにユーザのアプリケーション場合、そのような分離レベルを選択することができます。

分散トランザクション

この基本的な技術思想の実装はACID特性がある一方で、分散トランザクションは、そのトランザクションの原子性、一貫性、独立性、耐久性を確保する必要が実装します。

することにより、プロトコルトランザクション原子性、一貫性、および耐久性を「2フェーズ・コミット（2フェーズ、2PCをコミット）」。
分離レベルの実装は、典型的に保証するために、マルチバージョン並行処理制御機構を使用します。マルチバージョン同時実行制御方法は、一般に「スナップショット分離（スナップショット分離）」技術を用いています。

以下は、簡単に最初の二つの概念です。

3.1 2フェーズ・コミット

二相（二相コミット、2PC）コミットトランザクションのコミットと設計時の一貫性を維持するために、分散型システム・アーキテクチャ内のすべてのノードに基づくプロトコルを可能にすることです。

二相コミットアルゴリズムは、以下の仮定に基づいて設立されました：

分散システムは、そこにトランザクション・コーディネータ、トランザクション・マネージャのような他のノードとしてのノードであり、ネットワークのノード間で通信することができます。
すべてのノードは、先行書き込みログ（書き込みログ先行）を使用して、ログが書き込まれ、すなわちノードは、ログデータを見えなくするために損傷が生じない場合であっても、信頼性の高いストレージ・デバイスに開催されました。
すべてのノードは損傷がまだ回復することができた後も、永久的な損傷はありません。

二段階の次の段階は、アルゴリズムが記載されてコミット。

第一段階（要求フェーズコミット）

すべてのトランザクション・マネージャー・ノードのコミットを行うと、各管理ノード事務の応答を待つようになったことができるかどうか聞いてトランザクションコーディネータノード。トランザクションマネージャのノードが実行照会が開始され、情報のログ元に戻すとやり直し情報を書き込むまで、すべてのトランザクション操作。

問い合わせを開始するトランザクションマネージャトランザクションコーディネータノードに応じて、各ノード。トランザクションマネージャノードのトランザクション操作が実際に正常に実行された場合は、「はい」というメッセージを返し、トランザクション・マネージャー・ノードでのトランザクション操作は、実際の実装に失敗した場合、それは「一時停止」メッセージを返します。時には、また、投票フェーズの第一段階として知られている次のコミット操作を継続するか否かの投票に各トランザクションマネージャという。

（実施段階を提出する）第二段階

成功した場合

対応するメッセージトランザクションコーディネーター・ノードは、すべてのトランザクションマネージャから取得した場合には「同意」されています。

すべてのトランザクション・マネージャー・ノードに「正式に提出した」ノードを要求1.トランザクションコーディネータ。

2.正式なトランザクションマネージャノード操作の完了、およびリリースのリソースは、トランザクションの期間中に占領しました。

3.トランザクションマネージャノードは、トランザクション・コーディネーター・ノードに「完了」メッセージを送信します。

すべてのトランザクション・マネージャー・ノードからのフィードバックに「完全な」メッセージである4.コーディネータノードは、トランザクションを完了します。

失敗

メッセージが「サスペンド」またはトランザクションコーディネータ・ノードである第1段目のすべてのトランザクション・マネージャ・ノード復帰に対する応答である場合は前問い合わせの第1段階で、すべてのトランザクション・マネージャ・ノードタイムアウトを応答メッセージを取得できない場合。

1.すべてのノードにノード「ロールバック」トランザクションマネージャを要求するトランザクションコーディネータ。

元に戻す情報は、ロールバックを使用する前に、トランザクションマネージャノード2に書き込まれ、リソースを解放は、トランザクションの存続期間中に占有されています。

3.トランザクションマネージャノードは、トランザクション・コーディネーター・ノードに「ロールバック、完全な」メッセージを送信します。

すべてのトランザクションマネージャの帰還ノードに「ロールバックの完全な」メッセージによって、トランザクション・コーディネータノードの後4.トランザクションを取り消します。

時には、またどのような結果に関係なくので、完了段階の第二相と呼ばれる、トランザクションコーディネータは、この段階では、現在のトランザクションを終了しなければなりません。

トランザクションコーディネータ及び概略的なトランザクションマネージャとの間の通信の流れ：

二相の最大の欠点は、アルゴリズム嘘をコミット：その実行途中のノードがブロックされています。すなわち、各ノード間の他のメッセージを待っている間、それは何もできません。ケース内のノードが他のノードにブロッキング状態に応答メッセージを待つために、リソースを占有している場合に特に、占有のノードのリソースにアクセスするための第3のノードの試みは、ノードは、連帯して秋になり状態を遮断します。

また、トランザクションコーディネータノードを示しているトランザクションマネージャノードは常にトランザクションマネージャに応じて、すべての情報を得ることができないの崩壊や他のトランザクションコーディネータにつながった場合に登場した場合、そのトランザクションコーディネーターをノードと他の操作を提出するトランザクションマネージャ私たちは有効にするには、独自のタイムアウトメカニズムトランザクション・コーディネータに依存することができます。しかし、多くの場合、タイムアウトメカニズムを有効にするには、トランザクションコーディネータは、トランザクションマネージャが操作をロールバックすることを示します。このようなA戦略より保守的。

3.2スナップショット分離

スナップショット分離（スナップショット分離）技術は、マルチバージョン同時実行制御を実現する技術の一つです。これは、技術政策の前提は、データの各バージョンをサポートする必要があり、トランザクションが正常に各書き込み操作を提出された後のデータ（更新、挿入、削除）は、データの新しいバージョンを生成します。書き込み操作が成功した後に、データの新しいバージョンを生成します提出される概念があります。書き込み動作が正常に送信されていない前に、データへの変更は力ではありません。

スナップショットスナップショットそれは何ですか？これは単に、特定の時点でのデータベース内のT1のデータのすべての最新バージョンのコレクションです。例えば、以下のように3つだけそのようなデータベースレコードが存在し、その場合に時間スタンプT1は、状態は次のとおりです。

即ちROW1 [バージョン10]、ROW2 [バージョン= 1]、ROW3 [バージョン= 19]時刻T1において、スナップショットデータベースで形成されています。T1とT2との間に書き込みが正常に送信されない場合、数分後に、時刻T2まで、データベースの状態をスナップショットとスナップショット時間T1 T2時間が等しいこと、変更されていません。別の数分後に、時刻T3、T2とT3との間に、ROW2の更新操作、ROW3に削除操作と正常に送信挿入操作ROW4あり、データは、状態データベースなります：

即ちROW1 [バージョン10]、行2 [バージョン= 2]、ROW3 [バージョン= 20]、ROW4 [バージョン= 1]時刻T3において、データベースのスナップショットを構成しています。各レコードバージョンの変更は同じではありませんので、データのバージョンが状況を変更することに注意する必要があります。

また、データ要件の複数のバージョンでは、削除は本当にROW3を削除したが、ROW3の新しいバージョンを生成されていないことをしてくださいノート。実際の実装では、データベースは必ずしもヌル例に割り当てられた値以上と同じではありません、あなたは特別なフラグのロゴを使用することがありますが、これは、「削除」バージョンです。

時間からスナップショット意味をなさない話に永遠にスナップショットと、特定の時間に関連しました、。時間の期間は、データベースは、任意の書き込み操作が成功し提出しなかった場合には、この時間、いつでもデータベース・スナップショットは同じです。だから、我々はそれを言うことができ、正常に送信書き込みトランザクションを含むそれぞれが、異なるスナップショットのデータベースを形成します。多くの実装、データベース、直接、代わりに上記の数値例のバージョンスタンプで。

每个事务在启动时，都会记录当时的时间作为启动时间戳Start-Timestamp。该事务只能读取启动时间戳那个时刻的数据快照。然后每个事务在提交时，会记录当时时间作为提交时间戳Commit-Timestamp，当该事务成功提交后，会形成一个Commit-Timestamp的数据快照。后续启动的事务才能看到该事务写的数据（如果该事务有写操作）。

上图中，三条横线代表三个事务。事务T2是看不到事务T1写的任何数据的，因为事务T2启动时，事务T1还没有提交。而事务T3可以看到事务T1和事务T2写的数据，因为它启动的时候，事务T1和事务T2都提交了。

快照隔离（Snapshot Isolation）需要通过锁机制来防止写冲突，对于读操作，不加锁。如果多个事务同时写一个数据，锁机制保证最多只有一个事务能提交成功。由于对读操作不加锁，Snapshot Isolation的性能会显著提高。

SequoiaDB 分布式事务实现

4.1 基本概念和定义

为了实现分布式事务，巨杉数据库通过采用全局时间来实现全局事务对跨数据分片的事务的协调和管理。基于此需求，为了确定全局时间，巨杉数据库定义了时间戳的相关概念与定义，引入了时间戳管理机制。具体的定义如下：

LLT(Local Logical Timestamp)：每个节点（CATALOG、COORD、DATA）维护自己的本地逻辑时间（最小单位：microsecond）
ULT(Universal Logical Timestamp): 定义CATALOG主节点的本地时间为全局逻辑时间（最小单位：microsecond）
LRT(Local Real Timestamp)：本地UTC时间

为了保证整个集群全局时间的一致与准确，协调节点（COORD）和数据节点（DATA）需要定时与编目节点（CATALOG）的主节点进行时间同步。而同步时间定义了以下规则：

1. CATALOG主节点的LLT(即ULT)通过所有机器的CPU Tick计算

2. 其它节点的LLT通过与CATALOG主节点进行同步ULT来维护

3. 同步的间隔为ULTSyncInterval（默认：60秒）

4. 同步结果需要使用差小于全局容忍误差ULTTolerance（默认： 1ms）

5. ULTTolerance根据时间差同步、网络状态进行动态调整

全局时间的定义及规则确认之后，则可以将其用于分布式事务的实现当中。分布式事务采用二段提交机制实现，结合二段提交的原理，定义了以下几类事务时间：

TBT(Transaction Begin Timestamp)：事务开始时间
TPCT(Transaction Pre-Commit Timestamp)：事务的预提交(precommit)时间
TCP(Transaction Commit Timestamp)：事务的提交时间

其中，同一个事务的TBT和TPCT之间需要有一个事务时间间隔，此间隔取当时ULTTolerance。事务时间间隔也可以定义为不同节点发起的事务时间之间的最小可以容忍的误差。即如果两个不同节点的事务时间之间相关小于事务时间间隔，即认为这两个事务时间有误差的情况下相等。

4.2 二段提交实现

巨杉数据库对于分布式事务采用的是经典二段提交(2PC)方式实现的。其采用全局时间来实现全局事务的统一协调管理，使分布式集群中的不同节点进行事务的统一操作。在整个事务操作过程中，客户端发起的事务分为三个部分：

第一部分：事务开始。在这一部分的操作中，客户端向数据库服务器发起“事务开始”的请求。数据库服务器结合其本地逻辑时间生成一个事务开始时间，并记录在案。

第二部分：事务的增删改查操作。此部分是整个事务原子包的系列操作，它包含增删查改四类基本数据操作。在执行事务原子包里面第一条SQL语句时，分布式集群需要判断和校验协调节点和数据节点之间的时间差值。如果此差值大于延时容忍值，则要求COORD节点、DATA节点向CATALOG主节点发起时间同步，然后再重新发起SQL操作。如果时间差在容忍范围内，则直接执行。第一条事务操作执行成功后，说明时间比对成功，接下来的操作则直接执行。

第三部分：事务完成。此部分为事务的结束部分。在此部分中，整个事务执行完成，开始发起事务提交的操作。此操作进入事务的二段提交阶段，即先预提交，预提交成功之后再提交一次，整个提交流程才完成。

巨杉数据库事务实现的具体流程如下图：

4.3 并发控制技术

巨杉数据库对于多版本控制（MVCC）技术是通过采用事务锁、内存老版本以及磁盘回滚段重建老版本的设计来实现。此架构设计的理论基础是通过对内存结构的合理利用，存储数据和索引的老版本信息，从而实现数据的快速的并发访问。

此架构的基本原则是：充分利用内存结构缓存老版本以提高读的访问速度，同时结合事务可视性条件和MVCC来满足全局事务的不同隔离级别（RC/RR）的访问要求。在MVCC的实现中，巨杉数据库也平衡兼顾运行时的效率和多版本存储空间的使用，以及回收的开销。

在多版本控制技术的事务锁实现中，RR（可重复读）配置下的读操作可以在使用完记录之后立即释放锁，不需要一直持有，直到事务提交或者回滚。但是写事务操作则需要一直持有插入、更改和删除的锁，直到事务完成提交或者回滚。巨杉数据库锁的实现是采用悲观锁机制，与传统关系型数据库的采用的主流锁机制类似。

在多版控制技术的实现中，除了引入悲观锁的机制以外，巨杉数据库还采用了内存老版本机制提升数据库并发访问及操作的能力。内存老版本是通过在记录锁上附加有一个存储原版本数据和索引相关的结构，于内存中存储了老版本的数据。

所有事务写操作（修改，删除，插入）会在该结构中保存一个事务开始前的记录的拷贝，还包含所有改动过索引的原始版本。当读者试图获取记录锁时，如果记录正在被修改，读者取锁失败时将通过回调函数获得该锁的老版本结构，从而获取上次提交后的数据。在事务提交时，释放记录锁之后异步回收存储老版本记录和索引的空间，用户可以选择打开异步删除涉及到的待删除数据。同时在该锁或记录被下一个写操作用到时，他们都会被同步回收。其中老版本的结构如下：

巨杉数据库在实现多版本并发控制技术时，除了采用事务锁和内存老版本机制外，还采用了磁盘回滚段对并发控制策略进行了完善与补充。众所周知，内存是高速存储设备，但是其存在存储空间比较小以及断电数据丢失的问题。针对此问题，磁盘回滚段机制通过将内存中的“老版本数据”持久化到磁盘上，保证数据库在掉电等异常情况下不会影响事务的正常操作。

回滚段使用系统集合空间，名为”SYSRBS”。另外，其内部会使用1个集合，命名格式为”SYSRBSXXXX”，其中XXXX为循环编号，范围为0~4096。同时，回滚段使用第一个集合（即：SYSRBS0000）存储RBS的元数据，包括当前RBS集合和最后空闲RBS集合。巨杉数据库会在启动时检查是否支持MVCC，如果支持，则会检查”SYSRBS”集合空间是否存在，不存在的话则会创建此集合空间，同时创建 SYSRBSCL0000 和 SYSRBSCL0001 集合。如果回滚段的集合空间和集合均存在，则会从 SYSRBSCL0000 中读取元数据信息，根据当前RBS集合和最后空闲RBS集合信息创建下一下 SYSRBSCLXXXX。

さらに高めるために読み出し速度、ジャイアントセコイアデータベースディスクメモリのロールバックを組み合わせ、以前のバージョンには、最新バージョンが古いレコードロックoldversionContainerにぶら下がっている、他の古いバージョンではディスク上に置きます。だから、古いバージョンに応じて、最も短い取引のためには、読み出し専用メモリ、ディスクを読み取らず、これ読み取り速度を提供します。マスターノードを考慮することは異常で、古いバージョンのロールバックデータの複数のバージョンを記録するために必要な制御もスタンバイノード、マスタノードリットルを、古いバージョンのロールバックによって再構成することができるスタンバイ・ノードに同期されます。

トランザクションIDは、グローバル最小トランザクションID（lowTranID）未満の場合、バックグラウンドの非同期スレッドのデータベースには、レコードとインデックス・ノードのメモリの古いバージョンをリサイクルする責任があります。RBSは、メモリー・スクラビングを書くときに、古いバージョンの古いバージョンを保存します。ディスククリーンアップの古いバージョンでは、最後の空き開始から（lastFreeCL）のコレクション、1最大トランザクションID（MaxGTID）比較表ずつ、グローバル最小トランザクションIDよりも小さい場合には、あなたがテーブルを削除することができます（つまり、SYSRBSCLXXXX）です。

概要

古いバージョンを再構築し、ロールバックトランザクションのロック、メモリ、およびディスクの古いバージョンを使用して、セコイアデータベースは、マルチバージョン同時実行制御技術を実現するために設計されています。データの複数のバージョンへの迅速な同時アクセスを可能にする、データとインデックスを格納するためのメモリ構造の使用の合理化のために、旧バージョンの情報を通じてこのデザイン。