-
NewSQLとは何ですか
-
従来の SQL の問題
-
サーバーハードウェアをアップグレードする
-
データシャーディング
-
-
NoSQLの問題
-
アドバンテージ
-
欠点がある
-
-
新しいSQLの機能
-
NewSQL の主な機能
-
3種類のSQLの比較
-
TiDB はどのようにして生まれたのですか?
-
TiDB コミュニティ エディションとエンタープライズ エディション
-
TIDB のコア機能
-
水平方向の弾性膨張
-
分散トランザクションのサポート
-
金融グレードの高可用性
-
リアルタイムHTAP
-
クラウドネイティブな分散データベース
-
MySQLとの高い互換性
-
-
OLTP&OLAP（独学）
-
OLTP (オンライン トランザクション処理)
-
OLAP (オンライン分析処理)
-
機能の比較
-
設計角度の違い
-
-
TiDB の全体的なアーキテクチャ
-
TiDBのメリット
-
TiDB のコンポーネント
-
TiDBサーバー
-
PD（プレースメントドライバー）サーバー
-
TiKVサーバー
-
ティスパーク
-
ティフラッシュ
-
-
TiKVの全体構成
-
領域の分割と結合
-
地域のスケジュール設定
-
分散トランザクション
-
-
高可用性アーキテクチャ
-
TiDB 高可用性
-
PD の高可用性
-
TiKV 高可用性
-
-
アプリケーションシナリオ
-
MySQL の断片化とマージ
-
MySQL を直接置き換える
-
データベース
-
他のシステムのモジュールとして
-
-
アプリケーション
-
TiDB と MySQL の互換性の比較
-
TiDB でサポートされていない MySql 機能
-
自動インクリメントID
-
SELECT の制限
-
意見
-
デフォルト設定の違い
-
キャラクターセット
-
照合
-
大文字と小文字を区別
-
パラメータの説明
-
タイムスタンプタイプフィールドの更新
-
パラメータの説明
-
外部キーのサポート
-
TiDB は分散型 NewSQL データベースです。水平伸縮拡張、ACID トランザクション、標準 SQL、MySQL 構文、MySQL プロトコルをサポートし、強力なデータ整合性を備えた高可用性機能を備えており、OLTP シナリオだけでなく OLAP シナリオにも適したハイブリッド データベースです。
TiDB は、PingCAP によって独自に設計および開発されたオープンソースの分散リレーショナル データベースであり、オンライン トランザクション処理とオンライン分析処理 (HTAP) の両方をサポートする統合分散データベース製品です。レベルの高可用性、リアルタイム HTAP、クラウドネイティブ分散データベース、MySQL 5.7 プロトコルとの互換性、および MySQL エコロジー。目標は、ワンストップの OLTP (オンライン トランザクション処理)、OLAP (オンライン分析処理)、および HTAP ソリューションをユーザーに提供することです。TiDB は、高可用性、強整合性に対する高い要件、大規模なデータなど、さまざまなアプリケーション シナリオに適しています。
NewSQLとは何ですか
データベースは 3 世代にわたって開発されました。
-
SQL、MySQL などの従来のリレーショナル データベース
-
noSQL (MongoDB、Redis など)
-
新しいSQL
従来の SQL の問題
今世紀初頭からインターネットが急速に発展し始め、インターネットアプリケーションのユーザー規模やデータ量は増大し、24時間365日のオンライン利用が求められています。
この環境では従来のリレーショナル データベースがボトルネックになっており、通常は次の 2 つの解決策があります。
サーバーハードウェアをアップグレードする
パフォーマンスは向上しましたが、常に天井が存在します。
データシャーディング
分散クラスター構造を使用する
シングルポイント データベース上のデータを断片化し、安価なマシンで構成される分散クラスターに保存すると、スケーラビリティが向上しますが、新たな問題も生じます。
以前は 1 つのライブラリにあったデータが複数のライブラリにまたがるようになり、アプリケーション システムだけでは複数のライブラリで動作できなくなり、データベース シャーディング ミドルウェアを使用する必要があります。
フラグメンテーション ミドルウェアは、単純なデータ操作には問題ありませんが、データベース間の結合やデータベース間のトランザクションとなると頭の痛い問題になります。
NoSQLの問題
その後、従来の SQL の強力なトランザクション保証とリレーショナル モデルを放棄し、データベースの高可用性とスケーラビリティに重点を置いた noSQL が登場しました。
アドバンテージ
-
高可用性と拡張性、自動パーティショニング、容易な拡張
-
強い一貫性は保証されませんが、パフォーマンスは大幅に向上します
-
リレーショナル モデルの制約がない非常に柔軟な
欠点がある
-
強整合性は保証されておらず、通常のアプリケーションでは問題ありませんが、金融などのエンタープライズ レベルのアプリケーションでは依然として強整合性が必要なアプリケーションが数多くあります。
-
SQL ステートメントはサポートされておらず、互換性が大きな問題であり、NoSQL データベースごとにデータを操作するための独自の API があり、さらに複雑です。
新しいSQLの機能
NewSQL は、noSQL と同じスケーラビリティを提供し、依然としてリレーショナル モデルに基づいており、クエリ言語として非常に成熟した SQL を維持し、ACID トランザクション特性を保証します。
簡単に言えば、NewSQL は、NoSQL の強力なスケーラビリティを従来のリレーショナル データベースに統合します。
従来の SQL アーキテクチャ設計遺伝子には分散アーキテクチャはありませんが、NewSQL はクラウド時代に誕生し、本質的に分散アーキテクチャです。
NewSQL の主な機能
-
複雑なクエリとビッグデータ分析のための SQL サポート。
-
ACID トランザクションをサポートし、分離レベルをサポートします。
-
柔軟なスケーリング、容量の拡張と縮小は、ビジネス層に対して完全に透過的です。
-
高可用性と自動災害復旧。
3種類のSQLの比較
写真
TiDB はどのようにして生まれたのですか?
有名なオープンソース分散キャッシュ サービス Codis の作者であり、PingCAP の共同創設者兼 CTO である Huang Dongxu は、上級インフラストラクチャ エンジニアであり、分散ストレージ システムの設計と実装が得意であり、オープンソース愛好家の技術マスターです。今日、インターネットがこれほど繁栄しているにもかかわらず、データベースという曖昧で不確実な領域で、彼は依然として決定的な実践の方向性を見つけようとしています。公式の z 番号: code ape テクノロジー コラム、返信キーワード: 1111 に注目してください。Ali の社内 Java パフォーマンス最適化マニュアルを入手してください。
2012 年末まで、彼は Google が発表した 2 つの論文が自分の心の中で光を屈折させるプリズムのように見えました。これら 2 つの論文では、Google 内部で使用されている大規模なリレーショナル データベースである F1/Spanner について説明しています。F1/Spanner は、リレーショナル データベース、柔軟な拡張、グローバル分散の問題を解決し、大規模な運用環境で使用されています。「これが実現できれば、データ ストレージの分野にとって破壊的になるでしょう。」 Huang Dongxu 氏は完璧なソリューションの出現に興奮しており、これに基づいて PingCAP の TiDB が誕生しました。
TiDB コミュニティ エディションとエンタープライズ エディション
TiDBはコミュニティ版とエンタープライズ版に分かれており、エンタープライズ版ではサービスやセキュリティサポートを有償で提供します。
写真
TIDB のコア機能
水平方向の弾性膨張
TiDB の水平拡張は、新しいノードを追加するだけで実現でき、スループットやストレージをオンデマンドで拡張して、高い同時実行性と大量のデータのシナリオに簡単に対応できます。
TiDB のストレージとコンピューティングが分離されたアーキテクチャの設計のおかげで、コンピューティングとストレージは必要に応じてオンラインで拡張または縮小でき、拡張または縮小のプロセスはアプリケーションの運用および保守担当者にとって透過的です。
分散トランザクションのサポート
TiDB は標準 ACID トランザクションを 100% サポートします
金融グレードの高可用性
従来のマスター/スレーブ (MS) レプリケーション スキームと比較して、Raft ベースの多数決プロトコルは財務レベルの 100% データの強力な整合性保証を提供し、ほとんどのコピーを失うことなく自動障害回復 (自動フェイルオーバー) を手動で実行することなく実現できます。介入
データは複数のコピーに保存され、データ コピーは Multi-Raft プロトコルを通じてトランザクション ログと同期されます。ほとんどのトランザクションは書き込みが成功した後にのみ送信できるため、強力なデータの一貫性が確保され、データの可用性は影響を受けません。少数のコピーが失敗した場合。地理的な場所やレプリカの数などのポリシーは、さまざまな災害復旧レベルの要件を満たすためにオンデマンドで構成できます。
リアルタイムHTAP
典型的な OLTP 行ストレージ データベースとして、TiDB は強力な OLAP パフォーマンスも備えています。TiSpark を使用すると、ワンストップの HTAP ソリューションを提供できます。従来の煩雑な ETL プロセスを必要とせず、1 つのストレージで OLTP と OLAP を同時に処理できます。
行ストレージ エンジン TiKV と列ストレージ エンジン TiFlash の 2 つのストレージ エンジンを提供します。TiFlash は、Multi-Raft Learner プロトコルを通じて TiKV からデータをリアルタイムでコピーし、行ストレージ エンジン TiKV と列ストレージ エンジン TiFlash の間の強力なデータ一貫性を確保します。TiKV と TiFlash は、HTAP リソース分離の問題を解決するために、必要に応じて別のマシンにデプロイできます。
クラウドネイティブな分散データベース
TiDB はクラウド用に設計されたデータベースで、Kubernetes と密接に連携しており、パブリック クラウド、プライベート クラウド、ハイブリッド クラウドをサポートしているため、展開、構成、メンテナンスが非常に簡単です。TiDB の設計目標は 100% OLTP シナリオと 80% OLAP シナリオであり、より複雑な OLAP 分析は TiSpark プロジェクトを通じて実行できます。TiDB はビジネスに介入せず、従来のデータベース ミドルウェア、データベース サブデータベース、サブテーブル、およびその他のシャーディング ソリューションを適切に置き換えることができます。同時に、開発・保守担当者はデータベース規模の詳細を意識することなく事業開発に集中できるようになり、研究開発の生産性が大幅に向上します。
MySQLとの高い互換性
MySQL 5.7 プロトコル、MySQL の共通機能、および MySQL エコシステムと互換性があるため、アプリケーションを MySQL から TiDB に、コードを変更することなく、またはわずかな変更を加えて移行できます。
アプリケーションがデータ移行を簡単に完了できるよう、豊富なデータ移行ツールが提供されており、ほとんどの場合、コードを変更することなく MySQL から TiDB に簡単に移行でき、サブデータベースとテーブル分割後の MySQL クラスターもリアルタイムで移行できます。 TiDB ツールを通じて。
OLTP&OLAP（独学）
OLTP (オンライン トランザクション処理)
OLTP (Online Transactional Processing) はオンライン トランザクション処理です。OLTP は従来のリレーショナル データベースの主なアプリケーションです。主に基本的な日常のトランザクション処理に使用されます。入出金などの記録はリアルタイムで追加、削除、変更、確認されます。銀行に預けられた金額。支払いはビジネス取引です
オンライン トランザクション処理は、非常にトランザクション性の高いシステムです。一般に可用性の高いオンライン システムです。主に小規模なトランザクションと小規模なクエリに重点を置いています。システムを評価するときは、通常、1 秒あたりに実行されるトランザクション数と SQL 実行数に依存します。このようなシステムでは、単一のデータベースが 1 秒あたり数百または数千のトランザクションを処理することが多く、Select ステートメントの実行量は 1 秒あたり数千、場合によっては数万にもなります。典型的な OLTP システムには、米国の eBay のビジネス データベースなど、電子商取引システム、銀行、証券などが含まれます。これは非常に典型的な OLTP データベースです。
OLAP (オンライン分析処理)
OLAP (オンライン分析処理) はデータ ウェアハウスの中核であり、複雑な分析操作をサポートし、意思決定支援に重点を置き、直観的でわかりやすいクエリ結果を提供します。典型的なアプリケーションは、複雑な動的レポート システムです。
このようなシステムでは、ステートメントの実行時間が非常に長く、読み取られるデータも非常に大きいため、ステートメントの実行量は評価基準になりません。したがって、このようなシステムでは、何 MB/秒のトラフィックを達成できるかなど、ディスク サブシステムのスループット (帯域幅) が評価基準となることがよくあります。
機能の比較
OLTPとOLAPの特徴の比較
| — | OLTP | OLAP |
|---|---|---|
| リアルタイム | OLTP には高いリアルタイム要件があり、OLTP データベースは、トランザクション アプリケーションが単一のトランザクションをできるだけ早く処理するために必要なデータのみを書き込むことができるように設計されています。 | OLAP のリアルタイム要件はそれほど高くなく、多くのアプリケーションはせいぜい毎日データを更新します。 |
| データ量 | OLTP データの量はそれほど大きくなく、通常は数十のレコードの読み取り/書き込みのみを行い、単純なトランザクションを処理します。 | OLAPは動的クエリをサポートしているため、大量のデータを保持します。そのため、時系列分析など、ユーザーが知りたい情報を取得するために大量のデータを収集する必要があるため、処理されるデータ量が多くなります。 |
| ユーザーとシステムの方向性 | OLTP はトランザクションおよびクエリ処理において顧客指向です | OLAP は市場指向のデータ分析です |
| データベース設計 | OLTP はエンティティ関係 ER モデルとアプリケーション指向のデータベース設計を採用しています | スターまたはスノーフレーク スキーマと主題指向のデータベース設計を備えた OLAP |
設計角度の違い
| — | OLTP | OLAP |
|---|---|---|
| ユーザー | オペレーター、下級管理職 | 意思決定者、上級マネージャー |
| 関数 | 日常業務 | 分析の決定 |
| 主な仕事 | 追加、削除、変更 | お問い合わせ |
| DB設計 | アプリケーション指向 | 主題指向 |
| データ | 現在、最新の詳細、二次元、離散 | 歴史的な、集約された、多次元的に統合された、統合された |
| アクセス | 数十のレコードの読み取り/書き込み | 何百万ものレコードを読み取る |
| 雇用者 | 単純な事柄 | 複雑なクエリ |
| ユーザー番号 | 何千もの | 何百もの |
| DBサイズ | 100MB-GB | 100GB-TB |
TiDB の全体的なアーキテクチャ
TiDBのメリット
従来のスタンドアロン データベースと比較して、TiDB には次の利点があります。
-
優れたスケーラビリティを備えた純粋な分散アーキテクチャにより、柔軟な拡張と縮小をサポート
-
SQL をサポートし、MySQL ネットワーク プロトコルを公開し、ほとんどの MySQL 構文と互換性があり、ほとんどのシナリオで MySQL を直接置き換えることができます。
-
高可用性はデフォルトでサポートされており、少数のコピーに障害が発生した場合、データベース自体が自動的にデータ修復とフェイルオーバーを実行でき、これはビジネスに対して透過的です。
-
ACID トランザクションをサポートし、銀行振込などの強力な一貫性要件を持つ一部のシナリオに適しています。
-
データ移行、同期、バックアップ、その他のシナリオをカバーする豊富なツール チェーン エコロジーを備えています。
TiDB のコンポーネント
TiDB の水平拡張機能と高可用性機能を深く理解するには、まず TiDB の全体的なアーキテクチャを理解する必要があります。TiDB クラスターには主に、TiDB サーバー、PD サーバー、TiKV サーバーの 3 つのコア コンポーネントが含まれており、さらに、ユーザーの複雑な OLAP ニーズを解決するための TiSpark コンポーネントもあります。公式の z 番号: code ape テクノロジー コラム、返信キーワード: 1111 に注目してください。Ali の社内 Java パフォーマンス最適化マニュアルを入手してください。
コア設計の観点から見ると、TiDB 分散データベースはアーキテクチャ全体を複数のモジュールに分割し、各モジュールが相互に通信して完全な TiDB システムを形成します。対応するアーキテクチャ図は次のとおりです。
写真
建築
TiDBサーバー
TiDB サーバーは、SQL リクエストの受信、SQL 関連ロジックの処理、PD による計算に必要なデータを保存するための TiKV アドレスの検索、TiKV と対話してデータを取得し、最終的に結果を返す責任を負います。TiDB サーバーはステートレスであり、データ自体は保存せず、コンピューティングのみを担当し、水平方向に無制限に拡張でき、負荷分散コンポーネント (LVS、HAProxy、または F5 など) を通じて外部に統一アクセス アドレスを提供できます。
PD (配置ドライバー) サーバー
Placement Driver (PD と呼ばれる) はクラスター全体の管理モジュールであり、次の 3 つの主なタスクがあります。
-
1 つは、クラスターのメタ情報 (キーがどの TiKV ノードに保存されているか) を保存することです。
-
2 つ目は、TiKV クラスターのスケジュールと負荷分散 (データ移行、Raft グループ リーダーの移行など) です。
-
3 つ目は、グローバルに一意の増分トランザクション ID を割り当てることです。
PD は、Raft プロトコルを通じてデータのセキュリティを確保します。Raft のリーダー サーバーはすべての操作の処理を担当し、残りの PD サーバーは高可用性を確保するためにのみ使用されます。奇数の PD ノードを展開することをお勧めします
TiKVサーバー
TiKV サーバーはデータの保存を担当し、外部から見ると、TiKV はトランザクションを提供する分散型 Key-Value ストレージ エンジンです。データを格納する基本単位はリージョンであり、各リージョンはキー範囲 (StartKey から EndKey までの左閉右開区間) のデータの格納を担当し、各 TiKV ノードは複数のリージョンを担当します。TiKV は、データの整合性と災害復旧を維持するために、レプリケーションに Raft プロトコルを使用します。レプリカはリージョン単位で管理され、異なるノード上の複数のリージョンは互いのレプリカであるRaftグループを形成します。複数の TiKV 間のデータの負荷分散は PD によってスケジュールされ、これもリージョン単位でスケジュールされます。
ティスパーク
TiSpark は、ユーザーの複雑な OLAP ニーズを解決する TiDB の主要コンポーネントとして、TiDB ストレージ レイヤー上で直接 Spark SQL を実行し、同時に TiKV 分散クラスターの利点を統合し、ビッグ データ コミュニティのエコロジーに統合します。これまでのところ、TiDB は 1 つのシステムで OLTP と OLAP の両方をサポートできるため、ユーザー データの同期の問題がなくなりました。
ティフラッシュ
TiFlash は特別なタイプのストレージ ノードです。通常の TiKV ノードとは異なり、TiFlash 内ではデータが列の形式で保存され、その主な機能は分析シナリオを高速化することです。
TiKVの全体構成
従来のフルノードバックアップ方式とは異なり、TiKV はキーの範囲に応じてデータをほぼ均等なスライス (以下、総称してリージョンと呼びます) に分割し、各スライスには複数のコピー (通常は 3 つ) があり、そのうちの 1 つはリーダー、読み取りおよび書き込みサービスを提供します。TiKV は、PD を介してこれらのリージョンとレプリカをスケジュールし、データと読み取りおよび書き込みの負荷が各 TiKV に均等に分散されるようにします。この設計により、クラスター リソース全体が完全に活用され、マシンの数が増加しても水平方向に拡張できます。
写真
領域の分割と結合
リージョンのサイズが特定の制限 (デフォルトでは 144MB) を超えると、TiKV はリージョンを 2 つ以上のリージョンに分割して、各リージョンのサイズがほぼ同じになるようにします。これにより、PD のスケジュール決定がより容易になります。同様に、多数の削除リクエストによりリージョンが小さくなった場合、TiKV は隣接する 2 つの小さいリージョンを 1 つにマージします。
地域のスケジュール設定
データの一貫性は、Raft プロトコルを通じてリージョンとレプリカの間で維持されます。書き込みリクエストはリーダーにのみ書き込むことができ、大部分のレプリカに書き込む必要があります (デフォルト構成は 3 レプリカ、つまりすべてのリクエストです)少なくとも 2 つのレプリカに書き込む必要があります。成功) は、クライアントの書き込み成功を返します。
PD がある TiKV ノードから別の TiKV ノードへのリージョンのコピーをスケジュールする必要がある場合、PD はまずターゲット ノード上のこの Raft グループの学習者のコピー (リーダー データのコピー) を追加します。学習者コピーの進行状況がリーダー コピーにほぼ追いつくと、リーダーはそれをフォロワーに変更し、操作ノードのフォロワー コピーを削除して、リージョン コピーのスケジュール設定を完了します。
リーダー コピーのスケジューリング原理は似ていますが、ターゲット ノードの学習者コピーがフォロワー コピーになった後、リーダー転送が再度実行され、フォロワーが新しいリーダーになるための選挙を開始し、その後、新しいリーダーが決定されます。古いリーダーのコピーを削除する責任があります。
分散トランザクション
TiKV は分散トランザクションをサポートしています。ユーザー (または TiDB) は、これらの Key-Value が同じデータ スライス (リージョン) 内にあるかどうかを気にせずに、一度に複数の Key-Value を書き込むことができます。TiKV は、これらの読み取りおよび書き込みリクエストを 2 つの方法で保証します。フェーズコミット ACID 制約。
高可用性アーキテクチャ
高可用性も TiDB のもう 1 つの主要な機能であり、TiDB/TiKV/PD の 3 つのコンポーネントは、クラスター全体の可用性に影響を与えることなく、一部のインスタンスの障害を許容できます。以下では、これら 3 つのコンポーネントの可用性、単一インスタンスの障害の影響、および回復方法について説明します。
TiDB 高可用性
TiDB はステートレスであり、少なくとも 2 つのインスタンスをデプロイすることが推奨され、フロントエンドは負荷分散コンポーネントを通じて外部サービスを提供します。単一のインスタンスに障害が発生すると、このインスタンスで進行中のセッションに影響します。アプリケーションの観点から見ると、単一のリクエストの失敗が発生し、再接続後もサービスを引き続き取得できます。単一のインスタンスに障害が発生した場合は、再起動するか、新しいインスタンスをデプロイできます。
PD の高可用性
PD は、Raft プロトコルを通じてデータの一貫性を維持するクラスターです。単一のインスタンスに障害が発生した場合、インスタンスが Raft のリーダーでない場合、サービスはまったく影響を受けません。インスタンスが Raft のリーダーである場合、新しい Raft が生成されます。リーダーは再選され、サービスが自動的に回復されます。PD は選挙プロセス中は外部サービスを提供できません。この時間は約 3 秒です。少なくとも 3 つの PD インスタンスをデプロイすることをお勧めします。1 つのインスタンスに障害が発生した場合は、インスタンスを再起動するか、新しいインスタンスを追加します。
TiKV 高可用性
TiKV は、Raft プロトコルを通じてデータの一貫性を維持し (コピーの数は構成可能で、デフォルトで 3 つのコピーが保存されます)、ロード バランシングのスケジューリングに PD を使用するクラスターです。単一のノードに障害が発生すると、このノードに保存されているすべてのリージョンに影響します。リージョン内のリーダー ノードの場合、サービスは中断され、再選択を待ちますが、リージョン内のフォロワー ノードの場合、サービスは影響を受けません。TiKV ノードに障害が発生し、一定時間 (デフォルトでは 10 分) 以内に回復できない場合、PD はそのノード上のデータを他の TiKV ノードに移行します。
アプリケーションシナリオ
MySQL の断片化とマージ
写真
TiDB が適用される最初のタイプのシナリオは、MySQL のシャーディングとマージです。すでに MySQL を使用している企業では、サブデータベース、テーブル、シャード、ミドルウェアが一般的に使用されていますが、シャードの増加に伴い、クロスシャード クエリが大きな問題となります。TiDB はビジネス層で MySQL アクセス プロトコルと互換性があり、PingCAP はデータ同期ツール Syncer を作成し、Dongxu Huang の TiDB を MySQL スレーブとして使用し、メイン MySQL ライブラリの背後にある既存データベースのスレーブ ライブラリとして TiDB を接続できます。この層はデータを接続し、複雑なデータベース間、テーブル間、およびビジネス間のリアルタイム SQL クエリを直接実行できます。Huang Dongxu 氏は、「以前は、データベースには 1 つのマスターと複数のスレーブがありました。TiDB では、これを逆転させて、複数のマスターと 1 つのスレーブを実現できます。」と述べました。
MySQL を直接置き換える
写真
2 番目のタイプのシナリオは、MySQL を TiDB に直接置き換えることです。IT アーキテクチャが構築の開始時にサブデータベースとサブテーブルの問題を考慮せず、すべて MySQL を使用している場合、ビジネスの急速な成長に伴い、ますます大規模で同時実行性の高い OLTP シナリオが増えています。アーキテクチャの欠点を解決するには？
TiDB データベースでは、すべてのビジネス シナリオをデータベースとテーブルに分割する必要はなく、すべての分散作業はデータベース層によって実行されます。TiDB は MySQL プロトコルと互換性があるため、MySQL を直接置き換えることができ、基本的に箱から出してすぐに動作し、従来のデータベースとテーブルの分割方式によってもたらされる重い作業負荷や複雑なメンテナンスコストを心配する必要はありません。ユーザーインターフェイスにより、一般の技術者が効率的に保守管理を行うことができます。また、TiDBはNoSQLと同等の容量を有しており、データ量やアクセストラフィックが増加し続ける場合でも水平拡張によりシステムの業務支援能力を向上させることができ、応答遅延も安定しています。
データベース
写真
TiDB 自体は分散システムであり、3 番目の使用シナリオは TiDB をデータ ウェアハウスとして使用することです。TPC-H は、データ分析分野のテスト セットです。OLAP シナリオでの TiDB 2.0 のパフォーマンスが大幅に向上しました。データ ウェアハウスでのみ実行できる一部の複雑なクエリは、TiDB 2.0 で実行できます。基本的には10秒以内に制御されます。もちろん、OLAP の範囲は非常に広いため、TiDB の SQL も不確実です。このため、PingCAP は TiSpark をオープンソース化しました。TiSpark は Spark プラグインです。ユーザーは Spark SQL を直接使用して、TiKV でビッグ データ分析を行うことができます。リアルタイム。
他のシステムのモジュールとして
写真
TiDB はストレージとコンピューティングを分離する従来のプロジェクトであり、その基礎となる Key-Value レイヤーは HBase の代替として単独で使用でき、クロス行トランザクションをサポートします。TiDB は 2 つの API インターフェイスを外部に提供しており、1 つは行間トランザクションをサポートするために使用される ACID トランザクション API、もう 1 つは全体的なパフォーマンスの向上と引き換えに単一行トランザクションを実行できる Raw API ですが、クロス行トランザクション用の ACID は提供しません。 -行トランザクションのサポート。ユーザーは、自分のニーズに応じて 2 つの API から選択できます。たとえば、一部のユーザーは TiKV 上に Redis プロトコルを直接実装し、TiKV を大容量と低遅延の要件を持つ一部の Redis シナリオに置き換えています。
アプリケーション
写真
TiDB と MySQL の互換性の比較
-
TiDB は、MySQL トランスポート プロトコルとその構文のほとんどをサポートしています。これは、既存の MySQL コネクタとクライアントが引き続き動作することを意味します。ほとんどの場合、既存のアプリケーションはコードを変更せずに TiDB に移行できます。
-
TiDB サーバーの現在正式にサポートされているバージョンはMySQL 5.7です 。ほとんどの MySQL 操作およびメンテナンス ツール (PHPMyAdmin、Navicat、MySQL Workbench など)、およびバックアップおよびリカバリ ツール (mysqldump、Mydumper/myloader など) を直接使用できます。
-
ただし、一部の機能は分散環境ではうまく実装できないため、当面サポートされなかったり、MySQL とパフォーマンスが異なったりします。
-
一部の MySQL 構文は解析して TiDB に渡すことができますが、その後の処理は行われません 。たとえば、Create Table ステートメントの Engine は解析されて無視されます。
TiDB でサポートされていない MySql 機能
-
ストアド プロシージャと関数
-
引き金
-
イベント
-
カスタム関数
-
外部キー制約
-
一時テーブル
-
フルテキスト/空間関数とインデックス
-
非
ascii-latin1//// 文字セットbinary_utf8_utf8mb4 -
SYSスキーマ
-
MySQL トレース オプティマイザー
-
XML関数
-
Xプロトコル
-
セーブポイント
-
列レベルの権限
-
XA構文 (TiDB は内部的に 2 フェーズ コミットを使用しますが、SQL インターフェイスを通じて公開されません) -
CREATE TABLE tblName AS SELECT stmt文法 -
CHECK TABLE文法 -
CHECKSUM TABLE文法 -
GET_LOCKとRELEASE_LOCK機能
自動インクリメントID
TiDB の自動インクリメント列は、一意であることのみが保証されており、単一の TiDB サーバーで自動インクリメントされることも保証されますが、複数の TiDB サーバーで自動インクリメントされることは保証されません。自動的に割り当てられる値は保証されません。デフォルト値とカスタム値を組み合わせないことをお勧めします。値が混在しており、混在すると Duplicated Error エラー メッセージが。
TiDB は、システム変数を通じて tidb_allow_remove_auto_inc 列の削除を許可する属性を有効または無効に できますAUTO_INCREMENT 。列属性を削除するための構文は次のとおりです:alter table modify または alter table change。
AUTO_INCREMENT TiDB は列を追加する属性をサポートしていないため 、この属性を削除した後に復元することはできません。
SELECT の制限
-
SELECT ... INTO @变量構文はサポートされていません 。 -
SELECT ... GROUP BY ... WITH ROLLUP構文はサポートされていません 。 -
TiDB で
SELECT .. GROUP BY expr返される結果は、 MySQL 5.7 と一致しません。MySQL 5.7 の結果は と同等ですGROUP BY expr ORDER BY expr。ただし、TiDB のこの構文によって返される結果には順序が約束されておらず、これは MySQL 8.0 の動作と一致しています。
意見
TiDB は現在、 ビューに対する UPDATE、INSERT、DELETE などの書き込み操作をサポートしていません 。
デフォルト設定の違い
キャラクターセット
-
TiDB のデフォルト:
utf8mb4。 -
MySQL 5.7 のデフォルト:
latin1。 -
MySQL 8.0 のデフォルト:
utf8mb4。
照合
-
TiDB の
utf8mb4デフォルトの文字セット:utf8mb4_bin。 -
MySQL 5.7 の
utf8mb4デフォルトの文字セット:utf8mb4_general_ci。 -
MySQL 8.0 の
utf8mb4デフォルトの文字セット:utf8mb4_0900_ai_ci。
大文字と小文字を区別
lower_case_table_names構成について
-
TiDB のデフォルト: で
2あり、この値の設定のみをサポートします2。 -
MySQL のデフォルトは次のようになります。
-
-
Linux システムでは、値は次のとおりです。
0
-
-
Windows システムでは、この値は次のようになります。
1 -
macOS システムでは、値は次のとおりです。
2
パラメータの説明
-
lower_case_table_names=0 テーブル名は指定されたサイズで保存され、比較では大文字と小文字が区別されます。
-
lower_case_table_names = 1 テーブル名はディスク上に小文字で保存されますが、比較する際には大文字と小文字は区別されません。
-
lower_case_table_names=2 テーブル名は指定された大文字と小文字で保存されますが、小文字で比較されます。
タイムスタンプタイプフィールドの更新
デフォルトでは、タイムスタンプ タイプ フィールドが配置されているデータ行が更新されると、フィールドは現在時刻に自動的に更新され、パラメータ明示的デフォルト_for_timestamp がこの動作を制御します。
-
TiDB のデフォルト: で
ONあり、この値の設定のみをサポートしますON。 -
MySQL 5.7 のデフォルト:
OFF。 -
MySQL 8.0 のデフォルト:
ON。
パラメータの説明
-
Explicit_defaults_for_timestamp=off、データ行が更新されると、タイムスタンプ タイプ フィールドが現在時刻に更新されます。
-
Explicit_defaults_for_timestamp=on に設定すると、データ行が更新されるときに、タイムスタンプ タイプ フィールドは現在時刻に更新されません。
外部キーのサポート
-
TiDB のデフォルト: で
OFFあり、この値の設定のみをサポートしますOFF。 -
MySQL 5.7 のデフォルト:
ON。