前言
この記事はTiDBに関わる開発のニュースであり、創刊期ので、このシリーズの説明はここにします：
- 私は PingCAP で働いてのに、これは個人の理解だけ、オフィシャルの記事ではない。
- この記事はデータベースの技術の勉強材料で、ユーザーマニュアルではありません。
- 個人はまだ日本語を勉強中ので、完全な正しい説明をよくできない。質問や誤りやなんでもコメントを遠慮なくてお願いします。
-
TiDBは PingCAP から開発したオープンソースのデータベース、しかし PingCAP 以外の人間がその開発および実現の細分を理解は難しい。この現象の理由は複数があって、ここでは説明しません。このシリーズの目的は本気のオープンソースを目指します。 - 更新は不定期、そしてあまり詳しないです（興味があったら、リンクを開いてください）。
- できるだけ私の知識の範囲で、開発中の特性およびそのメカニズムを説明つもりです。
TiDB
Top-SQL(#24875)
SQL を実行のは遅い時、通常にデータベースは問題が出る、問題を解決ために、様々の情報が欲しい。Top-SQL はデータベースに最も遅い SQL のディテール情報を集まって、問題の解決をやすくなる。
Paging Coprocessor(#30578)
これは私が作った機能で、特別に説明しております
データベースの中に、一つのユーザーケースがある、インデックスでデータを読むこと。グローバルインデックスのデータベースでは、データを読んでために、通常に二つの読むことが必要です。インデックスを読んで、その結果によってデータを読みます。そのプロセスはシリアライズで、レイテンシがでる、もし Pipeline および Streaming でプロセス、並行することができる。Paging Coprocessor は大きなインデックス読む結果が分かれて、複数の返信で、Streaming とにっている効果が作る。
Lock View
トランザクションの間に競合ができたら、レイテンシがでる。その場合には、競合の様子を見ませんか。Lock View によって、今実行中のトランザクションがどのロックをブロックさせることを見ることができる。今は、現在実行中のトランザクションしかみえませんが、その歴史の競合を見ることはまだ計画中。
Avoid Data Inconsistency(#26833)
データの一貫性は正确の基本的な保証で、それを確保することは必要です。しかし今、データが一貫しない場合は、データを読むまでエラーが出ってこない。すなわち、エラーが出る時、そのエラーが作った時は昔の可能性がある。その機能はデータを書き込む時、一貫性をチェックして、一貫しない時、違うデータを書いて防ぐことができる。
TiKV
Raft Engine
Raft Engine は TiKV の Multi-Raft 専用のストレージエンジン。かつて、二つの RocksDB があって、データを書き込むのは二つのステップが必要です。先ずは、Raft の RocksDB に書き込んで、その後で全部のデータの RocksDB（KV RocksDB）に書き込む。Raft にとって、RocksDB は複雑すぎて、問題がある。例えば、WAL が一つの I/O depth しか利用できなくて、Write Stall が頻繁に出るから、Raft Engine は Raft にとって、もっと適合なエンジンです。
Dynamic Size Region
データを Raft アルゴリズムで処理で、並行することができない。そのために、Multi-Raft が作るが必要です。しかし、Raft Group の数量が多いすぎる時、ハートビートは性能をインパクトする。そこは矛盾の点があって、Region は大きい時、同じ Region で並行するコマンドは渋滞します。Region は小さい時、ハートビートは厄介です。この Dynamic Size Region のデザインで違う Region が違うサイズが出る、コマンドが多い Region は小さいので、コマンドが少ない Region は大きいです。
In-memory Pessimistic Locks
Pessimistic Lock は悲観的なロックで、楽観的なロックの向こうです。トランザクションの競合が高い時、楽観的なトランザクショは失敗するのは多いです。それに対して、悲観的なトランザクショは悲観的なロックを作って、悲観的なロックはトランザクションをコミット前さえ他のトランザクションをブロックすろことができて、失敗の可能性が減らす。しかし今では、RocksDB の Lock Column Family で悲観的なロックを書き込むことが必要です。In-memory Pessimistic Locks で悲観的なロックが RocksDB で入らなくてもいいのいで、悲観的なトランザクションの性能は大幅に上がります。