EN: |+| [Music] JA: |+|[音楽] EN: |+| We have briefly gone through TiDB server. JA: |+|TiDBサーバーを簡単に紹介しました EN: |+| We have introduced its server modules and its stateless nature. JA: |+|私たちは、そのサーバーモジュールとステートレス性を紹介しました。 EN: |+| Now let's proceed to the architecture of TiKV cluster. JA: |+| さて、次はTiKVクラスタのアーキテクチャに進みましょう。 EN: |+| Let's dig a little deeper into key value pair domain. JA: |+|キーと値のペアのドメインを少し深く掘り下げてみましょう。 EN: |+| We already learned TiKV is a key value model. JA: |+|私たちはすでに TiKV がキーバリューモデルであることを学びました。 EN: |+| TiKV provides an order traverse method. JA: |+|TiKVは順序付けトラバース方法を提供しています。 EN: |+| Key value pairs in the map are ordered according to the binary order of the key, meaning you |+| can seek the position of the key and then continuously call the next() method to get |+| the larger key in increasing order. JA: |+|キーと値のペアは、キーのバイナリ順に従って順序付けられるため、|+|キーの位置を検索して、NEXT()メソッドを連続して呼び出すことで、|+|増加する順序でより大きなキーを取得できます。 EN: |+| In order to implement horizontal scaling, storage data will be spread across multiple |+| nodes. JA: |+|水平スケーリングを実装するために、ストレージデータは複数の|+|ノードに分散されます。 EN: |+| TiKV divides the entire KV space into many segments according to the key range. JA: |+|TiKVは全体のKVスペースを、キーの範囲に応じた多数のセグメントに分割します。 EN: |+| Each segment is a series of consecutive keys. JA: |+|各セグメントは連続したキーのシリーズです。 EN: |+| A region has several segments. JA: |+|一つのリージョンには、複数のセグメントがあります。 EN: |+| The default size of one region is 96 megabytes. JA: |+|1つのリージョンのデフォルトサイズは96メガバイトです。 EN: |+| Each region can be described as the start key and end key with left close and right |+| open interval. JA: |+|各リージョンは、左側が閉じていて右側が開いた区間で、|+|開始キーと終了キーで記述されます。 EN: |+| Region is also a replication unit. JA: |+|　リージョンはまた、レプリケーションの単位でもあります。 EN: |+| Each region has its own Raft replication group. JA: |+|各リージョンには、固有のRaftレプリケーショングループがあります。 EN: |+| Just like the region 1 shown in the slide. JA: |+|スライドに表示されているリージョン1と同様です。 EN: |+| Each region has its own leader and follower nodes. JA: |+|各リージョンには、固有のLeaderノードとFollowerノードがあります。 EN: |+| Raft is a consensus protocol. JA: |+| Raftは分散合意プロトコルです。 EN: |+| Raft provides several important functions, such as leader election and member change |+| management. JA: |+|Raftは、Leader選出やメンバー変更のような重要な機能を|+|提供します。 EN: |+| Concretely, Raft is responsible for adding replicas, deleting replicas, transferring |+| leaders, log replication, etc. JA: |+|Raftは具体的にはレプリカの追加、レプリカの削除、Leadersの移行、|+|ログのレプリケーションなどを担当しています。 EN: |+| When TiKV uses Raft data replication, each data changed will be placed in a Raft log. JA: |+|TiKVがRaftデータレプリケーションを使用するとき、変更されたデータはすべてRaftログに配置されます。 EN: |+| Following Raft log replication function, the data is securely and reliably synchronized |+| to each node of the replication group. JA: |+|Raftログレプリケーション機能に従い、データは安全かつ信頼性の高い方法で、|+|各レプリケーショングループのノードに同期化されます。 EN: |+| According to the Raft protocol, it is only necessary to synchronously replicate to majority |+| nodes within the Raft group to safely affirm that data has been written successfully. JA: |+|Raftプロトコルでは、Raftグループ内の過半数のノードに同期的にレプリケーションするだけで|+|データが正常に書き込まれたことを安全に確認できます。 EN: |+| TiKV does not write a data directly to the disk, but saves the data in RocksDB, which |+| is responsible for the data landing. JA: |+|TiKVはデータを直接ディスクに書き込まず、データを保管するためにRocksDBを使用し、|+|RocksDBがデータの配置を担当しています。 EN: |+| RocksDB is a single instance KV storage engine, open-sourced by Facebook. JA: |+|RocksDBは、FacebookによってオープンソースでリリースされたシングルインスタンスのKVストレージエンジンです。 EN: |+| It was forked from Google's LevelDB originally. JA: |+|元々はGoogle LevelDBからフォークされたものです。 EN: |+| RocksDB can meet various requirements from TiKV as a single instance persistent engine. JA: |+|RocksDBは単一のインスタンスの永続エンジンとして、TiKVの様々な要件を満たすことができます。 EN: |+| By distributing and replicating data by region, TiKV has become a distributed key value system |+| with a certain disaster recovery capability as long as the majority TiKV nodes are alive. JA: |+| リージョンごとにデータを分散・複製することで、TiKVは分散型のキーバリューシステムとなり、|+| 過半数のTiKVノードが稼働している限り、確かな災害復旧能力を持つようになりました。 EN: |+| Any minority node failure does not break the data consistency. JA: |+| どんな少数ノードの障害でも、データの整合性は崩れません。 EN: |+| Now it's demo time again. JA: |+|今回のデモの時間です。 EN: |+| I'm going to kill my TiKV server instance in the playground and see what happens. JA: |+| 私はプレイグラウンドのTiKVサーバーインスタンスを停止して、何が起こるか見てみます。 EN: |+| Let's check the status of the playground. JA: |+|プレイグラウンドの状態をチェックします。 EN: |+| This time my target is the TiKV instance. JA: |+| 今回のターゲットは TiKV インスタンスです。 EN: |+| Please be noted my simple applications are still running. JA: |+|私のシンプルなアプリケーションはまだ動作していることに注意してください。 EN: |+| Just a heads up, there are two roles in my simple application. JA: |+|ただお知らせしておきますが、私のシンプルなアプリケーションには2つのロールがあります。 EN: |+| One keeps inserting randomly generated planet data into the planet table, while the other |+| keeps reading the data and does some simple calculation. JA: |+|片方はランダムに生成された惑星データを惑星テーブルに挿入し続け、|+|他方はデータを読み取って単純な計算を行います。 EN: |+| Detailed descriptions of my simple application can be found in the previous lecture. JA: |+|シンプルなアプリケーションの詳細は、前回の講義で見つけることができます。 EN: |+| Let me kill one TiKV instance. JA: |+|TiKVのインスタンスを1つ停止します。 EN: |+| Looks like nothing happened from the application side. JA: |+|アプリケーション側からは何も起こらなかったように見えます。 EN: |+| Based on this result we can tell that killing one TiKV node does not affect my application. JA: |+|この結果に基づくと、1つの TiKV ノードを停止することは私のアプリケーションに影響がないと言えます。 EN: |+| This behavior benefits from two facts. JA: |+| この挙動は2つの事実に基づいています。 EN: |+| Firstly, the default count for reading replicas in my example is three, with one TiKV node |+| gone, two are still alive. JA: |+|最初に、私の例では読み取りレプリカのデフォルトカウントは3であり、1つのTiKVノードがなくなり、|+|2つがまだ生きています。 EN: |+| Thus, the majority is still alive. JA: |+|したがって、過半数は依然として生きています。 EN: |+| According to Raft protocol, the leader is there, no matter whether it was a newly elected |+| leader or not, the leader is working so the system is open for read and write. JA: |+|Raftプロトコルに従って、新しく選ばれたLeaderかどうかに関わらず、Leaderはそこにあります。|+|Leaderが動作しているため、システムは読み取りと書き込みが可能です。 EN: |+| Secondly, because the TiDB servers decoupled communication between the client application |+| and the TiKV server. JA: |+|第二に、TiDBサーバが、クライアントアプリケーション|+|とTiKVサーバー間の通信を分離しています。 EN: |+| The SQL layer in the middle actually hides |+| the TiKV node failure for the front-end application. JA: |+|SQL レイヤーは、実際にはフロントエンドアプリケーションに対して |+|TiKV ノードの障害を隠蔽します。 EN: |+| However, from the operation point of view, if this is a production environment you already |+| received an alarm about the unfortunate change in the back end, which is one TiKV node was |+| down. JA: |+|しかしながら、運用の観点から言えば、もしプロダクション環境であれば、|+| すでにバックエンドの不運な変更に関するアラームを受け取ったはずです。|+|つまり、1つのTiKVノードがダウンしたことを意味します。 EN: |+| You can config to react automatically or manually. JA: |+|自動化するか、手動で対応するかを設定できます。 EN: |+| The most important thing is that your application feels nothing. JA: |+|最も重要なことは、あなたのアプリケーションに何も感じさせないことです。 EN: |+| I am not going to kill one more TiKV instance again, similar to what I did on TiDB instance |+| before. JA: |+|TiDBインスタンスの場合と同様に、追加で一つのTiKVインスタンスを|+|停止するつもりはありません。 EN: |+| Because by doing this, it will break the majority rule in Raft protocol. JA: |+|これを行うと、Raftプロトコルの過半数ルールが破れてしまうためです。 EN: |+| You will need database operation skills to recover the cluster. JA: |+|このクラスタを回復するには、データベース操作スキルが必要です。 EN: |+| Remember TiKV cluster is a stateful JA: |+|TiKVクラスタは状態を持つことを覚えておいてください。 EN: |+| We cover TiKV cluster recovery skills in TiDB administration course in database operation |+| learning path. JA: |+|データベース運用学習コースの中の、|+|TiDBの管理コースでTiKVクラスタの回復スキルをカバーします。 EN: |+| Please check the training catalog on education portal website for details. JA: |+|教育ポータルのウェブサイトでトレーニングカタログの詳細について確認してください。 EN: |+| Let's go up one level from Raft protocol. JA: |+|Raftプロトコルから1つ上のレベルに上がりましょう。 EN: |+| Let's talk about MVCC which means multiversion concurrency control. JA: |+| MVCC、即ちマルチバージョン同時実行制御について話します。 EN: |+| The version number comes from timestamp oracle. JA: |+|バージョン番号はTimestamp Oracleから取得されます。 EN: |+| When a row or a key value pair is updated, both old and the new entries are stored in |+| TiKV. JA: |+|行またはキーの値ペアが更新されると、古いエントリと新しいエントリの両方が|+|TiKVに格納されます。 EN: |+| Essentially it is implemented by adding the version number after the key. JA: |+| 基本的には、キーの後にバージョン番号を追加することで実装されています。 EN: |+| The older version entries can be used to support various scenarios like flashback query, flashback |+| table, and most importantly, the concurrent operations. JA: |+|以前のバージョンのエントリーを利用することで、フラッシュバッククエリ、フラッシュバック|+|テーブルなどのさまざまなシナリオをサポートでき、最も重要なことに、並行操作を行うことができます。 EN: |+| Imagine there are two sessions updating the value of a key at almost the same time. JA: |+|同じキーの値を更新する2つのセッションがほぼ同時にあると想像します。 EN: |+| Please note that for timestamp oracle or TSO, there is never a concept call the same time. JA: |+|Timestamp Oracle、略してTSOに関しては、同時という概念は存在しないことに注意します。 EN: |+| The different two changes always have different version numbers. JA: |+| 異なる2つの変更には常に異なるバージョン番号があります。 EN: |+| However in SQL layer TiDB still has the flexibility |+| to implement the pessimistic and the optimistic |+| transaction lock. JA: |+|しかし、SQLレイヤーでのTiDBは、|+|悲観的および楽観的なトランザクションロックを実装する柔軟性を|+|まだ持っています。 EN: |+| We will cover these two locks in TiDB specific features course. JA: |+|TiDB 固有機能コースで、これら2つのロックについて説明します。 EN: |+| Another key feature provided by TiKV is the operator push down and the distributed SQL. JA: |+| TiKVが提供するもう一つの重要な機能は、オペレータのプッシュダウンと分散SQLです。 EN: |+| Because of the parallel execution nature, it can improve query performance. JA: |+|並列実行の性質のため、クエリのパフォーマンスを向上させることができます。 EN: |+| As we mentioned before, TiKV nodes are workhorses for distributed SQL. JA: |+| 前述のように、TiKVノードは分散SQLのための実行部隊となります。 EN: |+| As shown on the slide the query needs to fetch the count from all planets that are in category |+| 1. JA: |+|スライドに示されているように、クエリはカテゴリー 1 に属する全ての惑星から数を|+|取得する必要があります。 EN: |+| To avoid a large number of RPC calls between the TiDB and the TiKV servers, the predicate |+| condition category ID equals 1 in the query will be pushed down to the storage node for |+| processing. JA: |+|TiDB サーバーと TiKV サーバーの間の多数の RPC 呼び出しを避けるため、|+| カテゴリ ID が 1 である場合、というクエリ内の述語条件が、|+|ストレージノードにプッシュダウンされて処理されます。 EN: |+| In addition to that, aggregate function count can also be pushed down to the storage nodes |+| for pre-aggregation. JA: |+|その上で、集計関数のcountもストレージノードにプッシュダウンして、|+|事前集計を行うことができます。 EN: |+| Thus, each TiKV node only needs to return one count. JA: |+|従って、各TiKVノードは1つのカウントのみを返すだけで済みます。 EN: |+| Then, total counts are summed up by the SQL layer which is the TiDB server, so that only |+| valid rows are returned and the meaningless network transfers are avoid. JA: |+|その後、合計数は TiDB サーバーである SQL レイヤーによって集計されるため、|+| 有効な行のみが返され、無意味なネットワーク転送が回避されます。 EN: |+| Let’s now compare TiDB's architecture with the ones of traditional databases. JA: |+| 今度は、TiDBのアーキテクチャを従来のデータベースと比較してみましょう。 EN: |+| Both TiDB and many traditional monolithic, or non distributed, databases support ACID |+| and strong consistency. JA: |+|TiDBと多くの伝統的なモノリシックまたは非分散型のデータベースは、|+|ACIDと強い一貫性をサポートしています。 EN: |+| However, TiDB has a distributed architecture. JA: |+|しかし、TiDBには分散アーキテクチャがあります。 EN: |+| It decouples the SQL layer, storage layer and the management layer. JA: |+| SQLレイヤー、ストレージレイヤー、管理レイヤーを分離します。 EN: |+| Thus, TiDB is able to elastically scale in and scale out, with almost zero impact on |+| your business. JA: |+|したがって、TiDBは弾力的にスケーリング・インとスケーリング・アウトを行うことができ、|+|またあなたの業務への影響はほぼゼロです。 EN: |+| TiDB is also highly available. JA: |+|TiDBも高い可用性があります。 EN: |+| It supports automatic fail-over. JA: |+|自動フェイルオーバーをサポートしています。 EN: |+| A few failed replicas will be totally transparent to your business. JA: |+| 数個のレプリカの障害は、あなたのビジネスにとって完全に透過的です。 EN: |+| Scaling up TiDB is also very convenient. JA: |+|TiDBのスケーリングも非常に便利です。 EN: |+| There is no need to change your business logic or add sharding keys. JA: |+|あなたのビジネスロジックを変更する必要はありませんし、シャーディングキーを追加する必要もありません。 EN: |+| TiDB is also designed to deal with highly concurrent situations. JA: |+| TiDBは、高い同時実行の状況に対処するように設計されています。 EN: |+| It can handle more concurrent reading and writing requests than traditional databases. JA: |+|従来のデータベースに比べて、より多くの同時読み書きリクエストを処理できます。 EN: |+| Traditional databases also have some attempts to scale out. JA: |+|伝統的なデータベースにも、スケールアウトの試みがあります。 EN: |+| This slide shows one of those attempts: Multi Nodes Shared Storage Architecture. JA: |+|このスライドは、その試みの1つを示しています：複数ノード共有ストレージアーキテクチャ。 EN: |+| The high level idea of this architecture is to put existing hardwares together to act, |+| as if it is a better hardware. JA: |+|このアーキテクチャの高レベルのアイデアは、既存のハードウェアを組み合わせて、|+|より優れたハードウェアのように振る舞うことです。 EN: |+| It is actually not scaling out. JA: |+| これは実際にはスケールアウトではありません。 EN: |+| It is still a means of scaling up. JA: |+|依然としてスケールアップの手段です。 EN: |+| However, no matter how many nodes are configured for the cluster, the data is stored on the |+| shared storage and the heartbeat in the middle is responsible for transmitting memory-level |+| buffer cache as well, which is an obvious bottleneck. JA: |+|しかしながら、クラスタに構成されたノードの数に関わらず、データは共有ストレージに保存され、|+| ミドルウェアのハートビートが、メモリレベルのバッファキャッシュを伝送するための責任を負っており、|+|これが明らかなボトルネックとなっています。 EN: |+| Moreover, this solution is very expensive, due to some special hardwares, such as network |+| connections, are needed. JA: |+|この解決策には、ネットワーク接続などの特殊ハードウェアが必要なため、|+|非常に高価です。 EN: |+| Another more popular way is to use sharding. JA: |+|もう一つのより一般的な方法はシャーディングを使用することです。 EN: |+| Data is put into multiple traditional databases according to the shard key. JA: |+|シャードキーに従って、複数の従来型データベースにデータが格納されます。 EN: |+| It is not uncommon in the real-world to have more than 50 shards of a database. JA: |+|実際の世界では、データベースのシャードが50以上あることは珍しいことではありません。 EN: |+| By doing this, the database management system can no longer provide ACID properties for |+| cross sharding transactions. JA: |+|このようにすると、データベース管理システムは、クロスシャーディングトランザクションにACIDプロパティを|+|提供できなくなります。 EN: |+| The application has to implement ACID logic for cross sharding transactions by themselves. JA: |+|アプリケーションは、クロスシャーディングトランザクションのためにACIDロジックを自分で実装する必要があります。 EN: |+| It is a nightmare for operations and management. JA: |+|運用と管理にとっては悪夢です。