MySQL は世界で最も人気のあるオープン ソース データベースであり、DB エンジン ランキング リストで長い間 2 位にランクされており、世界中に多くの企業ユーザーや開発者がいます。しかし、時間が経つにつれて、MySQL ユーザーは新たな課題に直面するようになります。Oracleは、MySQL 5.7バージョンの公式テクニカルサポートを2023年10月に終了すると正式に発表しました。サードパーティの統計によると、MySQL サーバーの半数以上が依然としてバージョン 5.7 を実行しています。今後数か月以内に、多数の MySQL インスタンスをバージョン 8.0 以降にアップグレードする必要があります。アップグレードしないと、Oracle が提供するテクニカル サポートや重要なパッチ更新を利用できなくなり、企業ユーザーは大きな課題に直面することになります。
新世代の分散リレーショナル データベースとして、TiDB は誕生初日から MySQL エコシステムを採用し、MySQL 5.7 および MySQL 8.0 との互換性を継続して維持し、ユーザーにスムーズな移行と使用エクスペリエンスを提供します。この記事では、MySQL 8.0 との互換性に関する TiDB 7.4 DMR の新たな進歩を紹介し、MySQL ユーザーが直面するさまざまな課題を TiDB がどのように根本的に解決できるかを探ります。
○ アップグレードは事業継続に影響します。シングル インスタンスまたは「マスター/スレーブ モード」で実行されている MySQL をアップグレードすると、データベース サービスが停止し、ビジネス運営に影響を与える可能性があります。多数の MySQL インスタンスを実行しているエンタープライズ レベルのユーザーは、アップグレードの潜在的なリスクに対処するためのテストと訓練に多大な人的資源と物的リソースを投資する必要があります。
○事業規模の拡大が難しい。ビジネス規模が拡大し、データ使用シナリオが増加するにつれて、ユーザーは通常、単一マシンの容量制限とシャード管理の複雑さの間でトレードオフを行う必要があり、データベース拡張の難しさがビジネス規模と開発速度を制限します。
○ 極めて高可用性のソリューションが不足している。コア ビジネス シナリオをサポートする MySQL データベースでは、予測できないダウンタイム イベントが発生した場合、ビジネスの回復が複雑になり、データベース管理者にとって極めて短い目標復旧時間 (RTO) を達成することが課題になります。
○ リアルタイム分析機能が不十分。大規模なデータのリアルタイム分析を処理するときの MySQL のパフォーマンスは、OLTP (オンライン トランザクション処理) シナリオほど良くありません。これは、複雑なクエリとデータ分析を必要とするビジネスにとっての課題です。
○独自の工場ホスティングサービスには限りがあります。クラウド サービス プロバイダーは MySQL ホスティング サービスを提供しますが、そのほとんどは Oracle からの公式サポートを受けていません。これは、ユーザーが製品の深い問題に対処したり、一般的な機能要件を発見したりするときに、元のデータベースの製造元から迅速なフィードバックやサポートを受けることができないことを意味します。
したがって、成熟した製品に移行して上記の問題を一気に解決するのが賢明な選択であることは間違いありません。TiDB は、MySQL の包括的なアップグレードには理想的な選択肢です。TiDB を選択すると、MySQL のアップグレードとスケーラビリティのジレンマを解消できるだけでなく、HTAP やデータベース統合などの追加の利点も享受できます。
TiDB は、PingCAP が独自に開発したエンタープライズ レベルの分散リレーショナル データベースであり、水平方向の拡張と縮小、財務レベルの高可用性、リアルタイム HTAP、クラウド ネイティブ、MySQL 5.7 プロトコルおよびエコシステムとの互換性などの重要な機能を備えています。TiDB はネイティブの分散アーキテクチャ設計を採用しており、柔軟で弾力性のあるスケーラビリティを備えており、プロセス全体がビジネスに対して透過的であり、手動による介入は必要ありません。TiDB のマルチコピー ストレージと Multi-Raft プロトコルは、データの強力な一貫性と高可用性を保証し、一部のコピーに障害が発生してもデータの可用性は影響を受けません。TiDB はローリング アップグレードを使用して、バージョン更新の影響を最小限に抑えます。さらに、一時ノードを追加して、アップグレード プロセス中の TiDB のパフォーマンスの変動と接続の中断を 5% 以内に制御することができ、アップグレードがビジネスに与える影響を大幅に軽減します。 。
また、PingCAP は、TiDB の開発者として、世界有数のクラウド サービス プロバイダーを基盤としたデータベース ホスティング サービスである TiDB Cloud を開始し、複雑な問題診断、アップグレード サポート、緊急レスキューなどのサービス サポートを提供し、独自の利点を最大限に反映しています。サービス。
プロジェクトの初期の頃から、MySQL エコシステムを採用する TiDB の製品戦略は今日まで続いています。TiDB は、MySQL のワイヤ プロトコルおよび構文コマンドと互換性があります。つまり、MySQL クライアント、MySQL ドライバー、および一部の MySQL ツールは TiDB 上で直接実行できます。MySQL 上で実行されるアプリケーションの大部分では、コードの変更はほとんど必要ありません。
MySQL 8.0 のリリースに伴い、TiDB は MySQL 5.7 との互換性をベースに、MySQL 8.0 との互換性を積極的に拡張してきました。TiDB v7.4.0 では、MySQL 8.0 の共通機能のサポートがリリースされ、MySQL 8.0 アプリケーションのスムーズな移行が容易になります。この記事では、いくつかの関数をリストします。
3.1 共通テーブル式（CTE）
MySQL 8.0 で導入された重要な機能として、TiDB はバージョン 5.1 以降、ANSI SQL 99 標準 CTE とその再帰書き込みメソッドをサポートしています。複雑なクエリを作成する場合、共通テーブル式 (CTE) を使用して一時的な中間結果セットを構築できます。この中間結果セットは SQL ステートメント内で複数回参照できるため、SQL ステートメントの作成効率、可読性、および実行効率が向上します。現在のバージョンでは、TiFlash は CTE もサポートしています。
たとえば、authors テーブルには著者情報が格納され、book_authors には著者 ID とその著者が執筆した書籍の ID との対応関係が記録されます。
mysql> desc authors;
+------------+--------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+------+---------+-------+
| id | bigint(20) | NO | PRI | NULL | |
| name | varchar(100) | NO | | NULL | |
| gender | tinyint(1) | YES | | NULL | |
| birth_year | smallint(6) | YES | | NULL | |
| death_year | smallint(6) | YES | | NULL | |
+------------+--------------+------+------+---------+-------+
mysql> desc book_authors;
+-----------+------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+------------+------+------+---------+-------+
| book_id | bigint(20) | NO | PRI | NULL | |
| author_id | bigint(20) | NO | PRI | NULL | |
+-----------+------------+------+------+---------+-------+CTE を使用すると、最も古い著者 50 人が何冊の本を書いたかをリストする SQL を簡単に作成できます。
mysql> WITH top_50_eldest_authors_cte AS (
-> SELECT a.id, a.name, (IFNULL(a.death_year, YEAR(NOW())) - a.birth_year) AS age
-> FROM authors a
-> ORDER BY age DESC
-> LIMIT 50
-> )
-> SELECT
-> ANY_VALUE(ta.id) AS author_id,
-> ANY_VALUE(ta.age) AS author_age,
-> ANY_VALUE(ta.name) AS author_name,
-> COUNT(*) AS books
-> FROM top_50_eldest_authors_cte ta
-> LEFT JOIN book_authors ba ON ta.id = ba.author_id
-> GROUP BY ta.id;
+-----------+------------+----------------------+-------+
| author_id | author_age | author_name | books |
+-----------+------------+----------------------+-------+
| 524470241 | 80 | Alexie Kirlin | 7 |
| 67511645 | 80 | Bridgette Tromp | 9 |
...
| 48355494 | 80 | Audrey Mayert | 7 |
+-----------+------------+----------------------+-------+
50 rows in set (0.23 sec)3.2 窓関数
ウィンドウ関数は分析関数とも呼ばれ、データを分析、要約、並べ替えるときに使用されます。ウィンドウ関数を SQL 形式で記述して、複雑なデータの並べ替え作業を完了し、ユーザーがデータの価値を探索できるようにすることができます。たとえば、データのグループ化と並べ替え、変化傾向の分析などです。
TiDB は現在、MySQL 8.0 が提供するウィンドウ関数を完全にサポートしており、そのほとんどは TiFlash にプッシュダウンして実行できます。
3.3 リソースの管理と制御
TiDB は、クラスター リソースの合理的な割り当て、データベースの安定性の向上、データベース使用コストの削減を目的として、バージョン 7.1 でリソースの管理と制御を導入しました。複数のアプリケーションが TiDB クラスターを共有するシナリオでは、リソースの分離により、アプリケーション負荷の変化が他のアプリケーションに及ぼす影響を効果的に軽減できます。また、リソース管理により、コア ビジネスに対するバッチ ジョブやバックグラウンド タスクの影響や、突然の SQL パフォーマンスの問題も解決できます。クラスター全体の速度を下げることは、大規模クラスターの安定性を向上させる重要な機能です。
MySQL とは実装方法に違いはありますが、TiDB は MySQL の構文やリソース グループを指定するためのヒントと互換性があり、ユーザーの学習コストや移行コストを削減します。さらに、TiDB のリソース分離により、最も重要な I/O リソースをより効果的に制御でき、MySQL と同等かそれ以上の結果を達成できます。
以下は、リソース管理を使用して、usr1 が使用するすべてのリソースを 1 秒あたり 500 RU 以内で制御する方法を示しています。
● 推定クラスタ容量
mysql> CALIBRATE RESOURCE● 1 秒あたり 500 RU の制限を持つ app1 リソース グループを作成します。
mysql> CREATE RESOURCE GROUP IF NOT EXISTS app1 RU_PER_SEC = 500;● ユーザーをリソース グループに関連付けると、usr1 のセッションがリソース グループ app1 に自動的に関連付けられます。
mysql> ALTER USER usr1 RESOURCE GROUP app1;セッションが属するリソース グループを変更することもできます。
mysql> SET RESOURCE GROUP `app1`;または、ヒント RESOURCE_GROUP() を使用して、ステートメントが属するリソース グループを指定します。
mysql> SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;3.4 ロールベースの権限管理
TiDB は、MySQL 互換のロール管理をサポートしています。ロールベースの承認により、アクセス許可の管理が簡素化され、エラーのリスクが軽減されます。権限をロールに関連付けることにより、データベースへのアクセスをより適切に制御できます。顧客は、シナリオごとに作業を分類し、対応するロールを作成し、権限のあるデータベースユーザーにロールを付与することができ、実際の運用時には、データベースユーザーがシナリオに応じてロールを切り替えることで、誤操作の可能性を低減できます。
ロールを使用して権限を分割する例を次に示します。アプリケーション管理者として、ユーザー dev_adm_usr はデータベース app_db 内のデータを操作する必要があります。ほとんどの場合、これは単なるクエリですが、データの修正が必要な場合には変更を加えることがあります。dev_adm_usr の誤操作を防ぐために、権限と使用ロールの 2 つの部分を分離し、必要な場合にのみ読み取りと書き込みのロールを自分自身に付与します。
● ロール app_read_role および app_write_role を作成する
mysql> CREATE ROLE 'app_read_role', 'app_write_role';● 対応する権限をロールに付与します。ここでは、2 つのロールにそれぞれ app_db に対する読み取り権限と書き込み権限が付与されます。
mysql> GRANT SELECT ON app_db.* TO 'app_read_role'@'%';
mysql> GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write_role'@'%';● 両方のロールをユーザー dev_adm_usr に付与します。
mysql> GRANT 'app_read_role','app_write_role' TO 'dev_adm_usr'@'localhost';● app_read_role を dev_adm_usr のデフォルトのロールとして設定し、ログイン時にユーザー dev_adm_usr がデフォルトで読み取り専用権限を持つようにします。
mysql> SET DEFAULT ROLE 'app_read_role' TO 'dev_adm_usr'@'localhost';● dev_adm_usr がデータを変更する必要がある場合、ロール app_write_role を有効にします。
mysql> SET ROLE app_read_role,app_write_role;または、すべての役割を有効にする
mysql> SET ROLE ALL;3.5 拡張された uft8mb4 文字セット
MySQL 8.0 での重要な変更点は、デフォルトの文字セットがより一般的な uft8mb4 に変更され、デフォルトのソート方法が utf8mb4_0900_ai_ci に変更されたことです。TiDB は、システムの移行を容易にするために、新しいバージョンに utf8mb4_0900_ai_ci ソート メソッドも追加しました。
MySQL 5.7 と MySQL 8.0 の両方と互換性を持たせるために、TiDB は MySQL 互換変数default_collation_for_utf8mb4 をサポートしています。ユーザーが utf8mb4 文字セットのデフォルトの並べ替えを調整できるようにします。このアプローチにより、TiDB は異なる MySQL バージョン間でスムーズに移行できるようになり、さまざまなアプリケーションのニーズに適応できます。
MySQL 8.0 から移行する場合は、8.0 のデフォルトのソート utf8mb4_0900_ai_ci に設定します。
set global default_collation_for_utf8mb4='utf8mb4_0900_ai_ci';MySQL 5.7 から移行する場合は、utf8mb4_general_ci を utf8mb4 のデフォルトのソートとして 5.7 に設定します。
set global default_collation_for_utf8mb4='utf8mb4_general_ci';3.6 JSON多値インデックス(多値インデックス)
TiDB は、MySQL 5.7 の完全な機能をサポートした後、MySQL 8.0 の新しくリリースされた機能のサポートを追加し続けています。最近のバージョンでは「複数値インデックス」がサポートされており、JSON 型の「配列」のインデックス作成が可能となり、JSON データの取得効率が向上しました。使用方法は MySQL とまったく同じです。つまり、移行プロセス中にデータ モデリングやアプリケーションを変更する必要はなく、ユーザーは使い慣れた方法で JSON データを操作し続けることができます。
多値インデックスは、通常のインデックス構造を拡張したものです。通常のインデックスとテーブルの 1 対 1 の対応とは異なり、多値インデックスとテーブルの対応は N 対 1 になります。MySQLと同様に、取得条件にMEMBER OF()、JSON_CONTAINS()、JSON_OVERLAPS()を使用する場合、複数値のインデックスが選択される場合があります。
たとえば、顧客情報テーブルがあり、すべての詳細情報が JSON 形式の JSON 型列にコンパイルされ、顧客が所在する都市を保存する配列構造があるとします。
北京にいる顧客を取得する必要がある場合、複数値のインデックスがない場合、このクエリはテーブル全体をスキャンする必要があります。
SELECT name FROM customer
WHERE 'beijing' MEMBER OF $.city;現時点では、city 配列の複数値インデックスを作成でき、上記のクエリはそのインデックスを使用して一致するレコードを取得できるため、クエリのパフォーマンスが大幅に向上します。
ALTER TABLE customers add index idx_city (name, (CAST(custinfo->'$.city' AS char(20) ARRAY)));通常のインデックスと同様に、オプティマイザが複数値インデックスを選択しない場合は、オプティマイザ プロンプト USE_INDEX() または USE_INDEX_MERGE() を使用して、オプティマイザに強制的に選択をさせることができます。
3.7 セッション変数のヒントを変更する(SET_VAR())
MySQL 8.0 では、特別なヒント SET_VAR() が導入されました。このヒントを使用すると、ステートメントの実行中にセッション レベルのシステム変数を変更できます。TiDB は v7.4.0 でもこのヒントをサポートしており、システム変数設定の柔軟性が向上し、SQL ステートメント用に「カスタマイズ」できます。オプティマイザーと実行時間に関連する複数の変数は、ヒントを使用して変更できます。
たとえば、大規模なテーブルの分析と処理の場合は、SQL の実行並列性を適切に高めます。
SELECT /*+ set_var(tidb_executor_concurrency=20) */
l_orderkey,
SUM(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
customer,
orders,
lineitem
WHERE
c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue DESC,
o_orderdate
limit 10;このヒントを使用して、他のクエリを変更せずに、前のクエリで TiFlash を選択するように強制することもできます。
SELECT /*+ set_var(tidb_isolation_read_engines='tidb,tiflash') */
l_orderkey,
SUM(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
customer,
orders,
lineitem
WHERE
c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue DESC,
o_orderdate
limit 10;3.8 CHECK制約
CHECK 制約は整合性制約チェックの一種で、データの精度を維持するために使用されます。CHECK 制約を使用すると、指定した条件を満たすようにテーブル内のフィールドの値を制限できます。テーブルに CHECK 制約を追加すると、TiDB はデータの挿入または更新時に制約条件が満たされているかどうかをチェックし、満たされていない場合はエラーが報告されます。
MySQL 8.0 より前は、CHECK 制約の構文をサポートするだけで、実際の動作ではチェックされませんでしたが、8.0 以降は完全にサポートされました。TiDB は、新しいバージョンでもこの機能を追加しました。この機能が原因で問題が発生する可能性がある DDL に CHECK 条件が残らないようにするために、TiDB はデフォルトでは CHECK 制約チェックを有効にしませんが、変数 tidb_enable_check_constraint これは、MySQL 5.7 と 8.0 の両方と互換性があるという TiDB の製品戦略を完全に反映しています。
mysql> set global tidb_enable_check_constraint=on;
mysql> CREATE TABLE t
-> ( a INT CHECK(a > 10) NOT ENFORCED, -- 不生效 check
-> b INT,
-> c INT,
-> CONSTRAINT c1 CHECK (b > c)
-> );
mysql> insert into t values (20,20,20);
ERROR 3819 (HY000): Check constraint 'c1' is violated.
ユーザー データ移行の複雑さを軽減するために、TiDB はツール TiDB Data Migration (DM) を開始しました。ユーザーは、MySQL プロトコル (MySQL、MariaDB、Aurora MySQL) と互換性のあるデータベースから TiDB への完全なデータ移行と増分データ同期を支援できます。DM は、DDL 同期、サブデータベースとサブテーブルのマージをサポートし、さまざまなシナリオに柔軟に適応するさまざまな組み込みフィルターを備えているため、データ移行の効率が効果的に向上します。
TiDB 7.4 は TiDB 7 シリーズの最後の DMR バージョンとなり、MySQL 8.0 向けに多くの最適化が行われています。MySQL の包括的なアップグレードとして、TiDB の技術的リーダーシップは、ユーザーが変化するビジネス データの課題に対処し、継続的なビジネスの成長と革新を達成するのに役立ちます。TiDB は MySQL 5.7 および MySQL 8.0 の機能と高い互換性を持っていますが、ユーザーがさまざまなビジネス アプリケーションをスムーズに移行できるようにするための技術サポートも提供し続け、それによって移行プロセス中の作業負荷とリスクを軽減します。