|+|[音楽]TiDBサーバーを簡単に紹介しました

|+|私たちは、そのサーバーモジュールとステートレス性を紹介しました。

|+| さて、次はTiKVクラスタのアーキテクチャに進みましょう。

|+|キーと値のペアのドメインに少し深く掘り下げてみましょう。

|+|私たちはすでに TiKV がキーバリューモデルであることを学びました。

|+|TiKVは順序走査法を提供しています。

|+|キーと値のペアは、キーのバイナリ順に従って順序付けられるため、キーの位置を検索して、次の()メソッドを連続して呼び出すことで、増加する順序で最大のキーを取得できます。 |+| |+|

|+|水平スケーリングを実装するために、ストレージデータは複数のノードに分散されます。 |+|

|+|TiKVは、キーの範囲に従って、全体のKVスペースを多数のセグメントに分割します。

|+|各セグメントは連続したキーのシリーズです。

|+|一つのリージョンには、複数のセグメントがあります。

|+|1つのリージョンのデフォルトサイズは96メガバイトです。

|+|各リージョンは、左側が閉じていて右側が開いた区間で、開始キーと終了キーで記述できます。 |+|

リージョン is also a replication unit.|+|　リージョンは複製ユニットでもあります。

|+|各リージョンには、独自のRaftレプリケーショングループがあります。

|+|スライドに表示されているリージョン1と同様です。

|+|各リージョンには、独自のLeaderノードとFollowerノードがあります。

Raft is a consistency protocol.|+| Raftは一貫性プロトコルです。

|+|Raftは、Leader選出やメンバー変更のような重要な機能を提供します。 |+|

|+|Raftは具体的にはレプリカの追加、レプリカの削除、Leadersの移行、ログのレプリケーションなどを担当しています。 |+|

|+|TiKVがRaftデータレプリケーションを使用すると、変更されたデータはすべてRaftログに配置されます。

|+|以下のRaftログレプリケーション機能に従い、データは安全および信頼性の高い同期化が保証され、各レプリケーショングループのノードに同期化されます。 |+|

|+|Raftプロトコルでは、Raftグループ内の過半数のノードに同期的にレプリケーションする必要があります。これによって、データが正常に書き込まれたことが安全に確認できます。 |+|

|+|TiKVはデータを直接ディスクに書き込まず、データを保管するためにRocksDBを使用するため、RocksDBがデータの配置を担当しています。 |+|

|+|RocksDBは、FacebookによってオープンソースでリリースされたシングルインスタンスのKVストレージエンジンです。

|+|元々GoogleのLevelDBからfolkされました。

|+|RocksDBは単一のインスタンスの永続エンジンとして、TiKVから様々な要件を満たすことができます。

リージョンごとにデータを分散・複製することで、TiKVは分散型のキーバリューシステムとなり、大多数のTiKVノードが稼働している限り、ある程度の災害復旧能力を持つようになりました。|+| ただし、元の英語文に存在する場合は見えないものとして、記号「|+|」を翻訳結果に再度挿入する必要があります。

|+| どんな少数ノードの障害でも、データの整合性は崩れません。

|+|今回のデモの時間です。

|+| 私はプレイグラウンドのTiKVサーバーインスタンスを停止して、何が起こるか見てみます。

|+|プレイグラウンドの状態をチェックします。

|+| 今回のターゲットは TiKV インスタンスです。

|+|私のシンプルなアプリケーションはまだ動作していることに注意します。

|+|ただお知らせしておきますが、私のシンプルなアプリケーションには2つのロールがあります。

|+|ランダムに生成された惑星データを惑星テーブルに挿入し続ける一方、他方はデータを読み取って単純な計算を行います。 |+|

|+|簡単なアプリケーションの詳細な説明は、前回の講義で見つけることができます。

|+|TiKVのインスタンスを1つ停止します。

|+|アプリケーション側からは何も起こらなかったように見えます。

|+|この結果に基づくと、1つの TiKV ノードを停止すと私のアプリケーションに影響がないことがわかります。

|+| この動作は2つの事実に基づいています。

|+|最初に、私の例では読み取りレプリカのデフォルトカウントは3であり、1つのTiKVノードがなくなったため、2つがまだ生きています。 |+|

|+|したがって、多数派は依然として生きています。

|+|Raftプロトコルによると、新しく選ばれたLeaderであろうとなかろうと、Leaderはそこにいます。Leaderが動作しているため、システムは読み取りと書き込みが可能です。 |+|

|+|まず第二に、TiDBサーバは、クライアントアプリケーション|+|とTiKVサーバー間の通信を切り離しています。

|+|SQL レイヤーは、実際にはフロントエンドアプリケーションに対して TiKV ノードの障害を隠します。 |+|

|+|しかしながら、運用の観点から言えば、もしプロダクション環境であれば、すでにバックエンドの不運な変更に関するアラームを受け取ったはずです。つまり、1つのTiKVノードがダウンしたことを意味します。 |+| |+|

|+|自動化するか、手動で実行するかを設定できます。

|+|最も重要なことは、あなたのアプリケーションに何も感じさせないことです。

|+|TiDBインスタンスと同様に、再び一つのTiKVインスタンスを停止すつもりはありません。 |+|

|+|これを行うと、Raftプロトコルの多数派ルールが破れるため、サインを見えなくする必要があります。

|+|クラスタを回復するには、データベース操作スキルが必要です。

|+|TiKVクラスタは状態を持つことを覚えてください。

データベース運用学習コースの中で、|+|TiDBの管理コースでTiKVクラスタの回復スキルをカバーします。元の英語文で|+|が存在する場合は、翻訳結果に再度挿入する必要があります。

|+|教育ポータルのウェブサイトでトレーニングカタログを詳細に確認します。

|+|Raftプロトコルから1つ上のレベルに上がりましょう。

|+| MVCC とはマルチバージョン同時実行制御を意味するので、そのことについて話します。

|+|バージョン番号はTimestamp Oracleから取得されます。

|+|行またはキーの値ペアが更新されると、古いエントリと新しいエントリが両方TiKVに格納されます。 |+|

|+| 基本的には、キーの後にバージョン番号を追加することで実装されます。

|+|以前のバージョンのエントリーを使用すると、フラッシュバッククエリ、フラッシュバック|+|テーブルなどのさまざまなシナリオをサポートでき、最も重要なことに、並行操作を行うことができます。

|+|同じキーの値を更新する2つのセッションがほぼ同時にあると想像します。

|+|OracleタイムスタンプやTSOに関しては、同じ時間という概念は存在しないことに注意します。

|+| 異なる2つの変更には常に異なるバージョン番号があります。

|+|しかし、SQLレイヤーでのTiDBは、悲観的および楽観的なトランザクションロックを実装する柔軟性をまだ持っています。 |+| |+|

|+|TiDB 特別機能コースで、これら2つのロックについて説明します。

|+| TiKVが提供するもう一つの重要な機能は、オペレータのプッシュダウンと分散SQLです。

|+|並列実行の性質のため、クエリのパフォーマンスを向上させることができます。

As we mentioned before, TiKV nodes are workhorses for 分散 SQL. |+| 前述のように、TiKVノードは分散SQLのための力強い支援力となります。

|+|スライドに示されているように、クエリはカテゴリー |+| 1 に属する全ての惑星から数を取得する必要があります。

|+|TiDB サーバーと TiKV サーバーの間の多数の RPC 呼び出しを避けるため、クエリ内の述語条件のカテゴリ ID が 1 である場合、ストレージノードにプッシュダウンされて処理されます。 |+| |+|

|+|その上で、集計関数のカウントもストレージノードにプッシュダウンして、事前集計を行うことができます。 |+|

|+|従って、各TiKVノードは1つのカウントのみを返す必要があります。

|+|それでは、合計数は TiDB サーバーである SQL レイヤーによって集計されるため、|+| 有効な行のみが返され、無意味なネットワーク転送が回避されます。

|+| 今度は、TiDBのアーキテクチャを従来のデータベースと比較してみましょう。

|+|TiDBと多くの伝統的なモノリシックまたは非分散型のデータベースは、ACIDと強い一貫性をサポートしています。 |+|

|+|しかし、TiDBには分散アーキテクチャがあります。

|+| SQLレイヤー、ストレージレイヤー、管理レイヤーを分離します。

|+|したがって、TiDBは弾力的にスケーリング・インとスケーリング・アウトを行うことができ、ほぼゼロの影響であなたのビジネスを拡大することができます。 |+|

|+|TiDBも高い可用性があります。

|+|自動フェイルオーバーをサポートしています。

|+| あなたのビジネスには、わずかな数の失敗したレプリカが完全に透明になるということです。

|+|TiDBのスケーリングも非常に便利です。

|+|あなたのビジネスロジックを変更する必要はありませんし、シャーディングキーを追加する必要もありません。

|+| TiDBは、高度に並行した状況に対処するように設計されています。

|+|従来のデータベースに比べて、より多くの同時読み書きリクエストを処理できます。

|+|伝統的なデータベースにも、スケールアウトの試みがあります。

|+|このスライドは、その試みの1つを示しています：複数ノード共有ストレージアーキテクチャ。

|+|このアーキテクチャの高レベルのアイデアは、既存のハードウェアを組み合わせて、より優れたハードウェアのように振る舞うことです。 |+|

|+| 実際にはスケーリングアウトしていません。

|+|まだスケーリングアップの手段として残っていると考えられます。

|+|しかしながら、クラスタに構成されたノードの数に関わらず、データは共有ストレージに保存され、|+| ミドルウェアのハートビートが、メモリレベルのバッファキャッシュを伝送するための責任を負っており、これが明らかなボトルネックとなっています。 |+|

|+|この解決策は、ネットワーク接続などの特殊ハードウェアが必要なため、非常に高価です。 |+|

|+|もう一つのより一般的な方法はシャーディングを使用することです。

|+|シャードキーに従って、複数の従来型データベースにデータが格納されます。

|+|実際の世界では、データベースのシャードが50以上あることは珍しいことではありません。

|+|このようにすると、データベース管理システムは、クロスシャーディングトランザクションにACIDプロパティを提供できなくなります。 |+|

|+|アプリケーションは、クロスシャーディングトランザクションのためにACIDロジックを自己実装する必要があります。

|+|運用と管理にとっては悪夢です。