元ドキュメント: よくある質問
よくある質問
TDSQL Boundless はどのデータベースプロトコルと互換性がありますか？
TDSQL Boundless は MySQL 8.0 プロトコルと互換性があり、MySQL 8.0 インスタンスとして使用できます。ただし、一部制限されている操作があります。詳細はMySQL 互換性をご参照ください。
TDSQL Boundless にシャーディングキー（ShardKey）は必要ですか？
TDSQL Boundless ではシャーディングキーの定義は不要です。テーブル作成構文は MySQL ネイティブと同一です。TDSQL Boundless のシャーディングメカニズムは MySQL ネイティブのパーティションテーブルに基づいており、ほとんどの場合、1レベルの HASH パーティションテーブルで十分に対応できます。HASH パーティションはすべてのデータノードに均等に分散され、書き込み負荷をバランスします。
TDSQL Boundless エンジンと MySQL ネイティブの読み書きパフォーマンスの違いは？
TDSQL Boundless はネイティブ分散データベースです。Raft プロトコルによりデータユニットのレプリカ間の整合性を維持し、デフォルトで各データユニットに3つのレプリカを持ち、すべてのデータノードに均等に分散します。この戦略により、大量の書き込み操作の処理効率が大幅に向上し、特に書き込みが多く読み取りが少ない業務シナリオで優れたパフォーマンスを発揮します。
MySQL の InnoDB ストレージエンジンと比較して、TDSQL Boundless は 3〜9倍 のデータ圧縮率を実現でき、ストレージ容量の削減だけでなく、書き込み I/O パフォーマンスの向上も期待できます。そのため、書き込みパフォーマンスへの要求が高いシナリオに特に適しています。
TDSQL Boundless はリードライト分離に対応していますか？
リードライト分離は、通常以下の2つの課題を解決するために使用されます。
- 従来のマスター/スレーブアーキテクチャにおいて、スレーブのリソースを有効活用する
- AP（分析処理）と TP（トランザクション処理）の業務が混在する環境で、両者の相互干渉を回避する
ただし、TDSQL Boundless のアーキテクチャは従来のマスター/スレーブアーキテクチャ（InnoDB 等）とは異なります。TDSQL Boundless ではデータがすべてのノードに均等に分散されているため、各ノードの CPU や I/O 等のリソースを十分に活用でき、スレーブリソースの活用を目的としたリードライト分離は不要です。
AP の読み取り SQL と TP シナリオを分離する必要がある場合については、今後のバージョンで対応を予定しています。
TDSQL Boundless は読み取り専用アカウントや読み取り専用ノードに対応していますか？
現時点では、読み取り専用アカウントおよび読み取り専用ノードには対応していません。TDSQL Boundless の対等ノードアーキテクチャでは、読み書きリクエストが各ノードに分散されるため、すべてのノードのリソースを十分に活用できます。TDSQL Boundless のアーキテクチャについては製品概要をご参照ください。
今後のバージョンで読み取り専用ノードのサポートを追加する予定です。
TDSQL Boundless はどのようなテーブルタイプに対応していますか？シングルテーブル、ブロードキャストテーブル、パーティションテーブルはありますか？
TDSQL Boundless では、現在主に通常テーブル（パーティションあり/なしの2種類）をサポートしています。
- パーティションテーブル：異なるパーティションのデータを異なるノードに分散できます
- 非パーティションテーブル：データ量が大きい場合、Replication Group（RG）が自動的に分割され、各ノードに均等に分散されます
- ブロードキャストテーブル（同期テーブル）：テーブル作成時に、すべてのノードにデータを複製するよう定義できます
TDSQL Boundless でパーティションテーブルを使用する必要はありますか？
スタンドアロン環境では、パーティションテーブルは主にパーティションプルーニングによる SQL パフォーマンスの向上や、DROP PARTITION による定期的なデータクリーンアップに使用されます。TDSQL Boundless の分散環境では、これに加えて複数ノードの書き込み能力を活用できるため、大量データの処理に特に有効です。
大規模なデータ移行を行う場合は、事前に大きなテーブルを Hash ベースのパーティションテーブルに変換しておくことを推奨します。これにより、TDSQL Boundless の複数ノードの処理能力を活かしてデータインポートを高速化できます。
パーティショニングを行わずにシングルテーブルを作成した場合、データインポートの初期段階ですべての書き込みが1つのデータノードに集中し、I/O ボトルネックが発生する可能性があります。TDSQL Boundless には自動分割とデータマイグレーション機能がありますが、最初にパーティションが設定されていない場合、このプロセスは遅くなる可能性があります。
パーティションテーブルの作成は、コストが非常に低い変更です。テーブル作成文の変更のみで済み、アプリケーションコードの修正は不要です。例えば、30ノードのインスタンスであれば、30パーティションの1レベル Hash パーティションテーブルを作成することで、各ノードに1つのプライマリレプリカが配置され、データが均等に分散されます。
読み取りシナリオでパフォーマンスの問題はありますか？データシャードの所在をどのように特定しますか？
TDSQL Boundless の分散環境では、読み取りパフォーマンスはデータシャーディングとクエリ方式の影響を受ける場合があります。
- パーティションキーを含むクエリ：パーティションキーが指定されている場合、TDSQL Boundless はクエリを該当するデータシャードに直接ルーティングします。不要なデータ走査を回避し、非常に効率的です。
- パーティションキーを含まないクエリ：パーティションキーが指定されていない場合、セカンダリインデックスによるデータ位置の特定が行われます。該当テーブルのデータを持つノード上で走査クエリが実行されるため、若干のパフォーマンス低下が生じる可能性があります。
TDSQL Boundless の最大対応容量はどの程度ですか？
TDSQL Boundless の最大容量は理論上無制限です。業務の成長に応じてノードを追加することでデータベースの容量を拡張できます。現在、パブリッククラウドでは数十ノード規模のインスタンスのデプロイに対応しています。
TDSQL Boundless はコンソールから水平スケールアウト/スケールインを容易に実行できるビジュアルインターフェースを提供しています。また、自動マイグレーションと容量均衡機能を内蔵しており、ノード間のデータ分布を自動的に調整し、手動介入なしでパフォーマンスとストレージ効率を最適な状態に維持します。
LSM-Tree ベースの TDSQL Boundless のクエリパフォーマンスは MySQL ネイティブより低いですか？
MySQL の B+Tree インデックスと比較して、LSM-Tree は書き込みパフォーマンスに優れる一方、読み取りパフォーマンスにはトレードオフがあります。
ただし、TDSQL Boundless は分散データベースとして、クエリパフォーマンスを向上させる複数のメカニズムを提供しています。
- 垂直/水平スケーリング：ノードの追加によりデータベースの処理能力を拡張し、QPS を向上できます。これはシングルノードの MySQL では実現できません。
- 最適化戦略：シングルノード上でも、以下の最適化が施されています。
- Leveling Compaction：L1〜L6 の各レイヤーでキーの一意性が保証されており、各レイヤーで検索する SST ファイルは1つだけで済みます
- Bloom Filter：ブルームフィルターにより、対象キーを含まない SST ファイルを高速に除外し、不要なディスクアクセスを回避します
- Block Cache：ホットデータをブロックキャッシュに保持し、ディスク I/O を削減してさらに読み取りパフォーマンスを向上させます
以上により、LSM-Tree ベースの TDSQL Boundless は最適化された MySQL インスタンスに比べて読み取り性能で若干劣る場合がありますが、分散アーキテクチャと各種最適化を通じて、特に大規模データ処理や高同時実行アクセスのシナリオにおいて効率的な読み書きパフォーマンスを提供します。
InnoDB と TDSQL Boundless では、大規模トランザクションのプライマリ/スタンバイ遅延に違いはありますか？
InnoDB と TDSQL Boundless は、大規模トランザクションにおけるプライマリ/スタンバイ遅延の扱いが異なります。
- InnoDB：バイナリログ（binlog）によるデータ同期を使用します。高同時実行・大量データの環境では、大規模トランザクションが binlog の複製・再生に時間がかかり、遅延が生じる場合があります。
- TDSQL Boundless：Raft プロトコルに基づく分散データベースで、Raft ログによりノード間のデータをリアルタイムに同期します。Leader ノードはクライアントリクエストを受信後、ログエントリをローカルログに追加してから Follower ノードに複製します。過半数のノードに複製されてから初めてクライアントに応答するため、大規模トランザクションによる遅延を効果的に抑制できます。
TDSQL Boundless では、プライマリ/スタンバイ間の apply 操作の遅延はほとんど発生しません。唯一の潜在的な遅延は、Follower が Leader から次のログエントリ（またはハートビート）を受信してコミットインデックスを取得するまでの間隔ですが、通常無視できるレベルです。
また、TDSQL Boundless ではトランザクションサイズに制限があり、特に削除操作については大規模トランザクションを複数の小さなトランザクションに分割して実行することを推奨します。
トランザクションが最終的に Rollback された場合、既に Follower に複製されたログはどうなりますか？
Raft プロトコルでは、トランザクションがロールバックされた場合、既に Follower ノードに複製されたログエントリはステートマシンに適用されません。つまり、基盤のデータストレージには影響しません。これらのログエントリは「未コミット」として扱われます。
Raft プロトコルは以下のメカニズムにより、「未コミット」のログエントリが誤って適用されないことを保証します。
- commitIndex の管理：コミット済みログエントリの最大インデックスを追跡する
commitIndex変数を使用します。トランザクションがロールバックされた場合、commitIndexは変更されないため、「未コミット」のエントリが適用されることを防ぎます。 - ログの切り詰め：フェイルオーバーなどの状況では、新しく選出された Leader がログを切り詰めてクラスター全体の整合性を確保する場合があります。「未コミット」のエントリはクラスター全体から除去されます。
TDSQL Boundless の Compaction はパフォーマンスにどのような影響がありますか？
TDSQL Boundless の Compaction プロセスは、上位レイヤーのファイルを読み込み、ソートマージを行い、下位レイヤーのファイルに書き込むという2つのアクションで構成されます。この処理は主に CPU と I/O リソースを消費します。そのため、システムに十分なリソースがあれば、Compaction 自体が業務パフォーマンスに目立った影響を与えることは通常ありません。
さらに、TDSQL Boundless は分散アーキテクチャを採用しているため、すべてのノードのリソースを Compaction に活用できます。これは従来のマスター/スレーブアーキテクチャとは異なり、Compaction のために追加リソースを確保する必要性を効果的に軽減します。
Compaction のパフォーマンスへの影響に対する懸念は、初期の RocksDB 実装における比較的単純な Compaction 戦略に起因するところが大きいですが、バージョンの更新に伴い最適化が重ねられ、影響はより制御可能になっています。
TDSQL Boundless の現在のディザスタリカバリ（DR）対応状況は？
TDSQL Boundless は多様な高可用性技術を備えており、インスタンス内のマルチレプリカ DR とインスタンス間の物理スタンバイ DR に対応しています。
インスタンス内のマルチレプリカ DR
- 同一データセンター 3レプリカ：同一データセンター内の3レプリカで1つのインスタンスを構成。少数派ノードの障害に対応できますが、データセンター全体の障害には対応できません。
- 同一都市 3データセンター 3レプリカ：同一都市内の3つのデータセンター（各データセンターが1つのアベイラビリティゾーン）で構成。データセンター間のネットワーク遅延は通常 0.5〜2ms。少数派ノード障害および単一データセンター障害に対応できますが、都市全体の障害には対応できません。
インスタンス間の物理スタンバイ DR
同一都市内 DR および都市間 DR に対応しています。完全に独立した2つのインスタンス間でデータ同期とプライマリ/スタンバイ切り替え機能を提供します。
注意：
- ミッションクリティカルなアプリケーションでは、データベースと同等の DR レベルをアプリケーション側にも確保してください。
- インスタンス間 DR ではデータ同期は準リアルタイムです。Switchover（計画内切り替え）はデータロスなしで実行可能ですが、Failover（障害時切り替え）ではスタンバイの同期遅延に応じて数秒程度のデータロスが発生する可能性があります。
TDSQL Boundless は JSON に対応していますか？
はい。JSON データ型をサポートしており、JSON_ARRAYAGG および JSON_OBJECTAGG の2つの集約関数にも対応しています（MySQL と同等の動作です）。
TDSQL Boundless は外部キーやグローバルインデックスに対応していますか？
TDStore は外部キーおよびグローバルインデックスに対応していません。移行対象のインスタンスがこれらの機能を使用しているかどうかを確認する必要がある場合は、テクニカルサポートに連絡してスキャンツールを入手してください。
TDSQL Boundless はパブリックネットワーク（外部ネットワーク）からのアクセスに対応していますか？
セキュリティとパフォーマンスの観点から、TDSQL Boundless インスタンスは現在、プライベートネットワーク（VPC）内からのアクセスのみに対応しています。
TDSQL Boundless の AUTO_INCREMENT フィールドで値が飛ぶのはなぜですか？
TDSQL Boundless では、AUTO_INCREMENT フィールドはグローバルに一意であることのみを保証しており、グローバルに連番であることは保証していません。
割り当て効率を向上させるため、TDSQL Boundless はシャードキャッシュメカニズムを採用しています。例えば、3つのコンピュートノードがある場合、それぞれが以下のように連続した AUTO_INCREMENT 値の範囲をキャッシュします。
- ノード A：1〜100
- ノード B：101〜200
- ノード C：201〜300
ノード A のキャッシュ値を使い切ると、次に利用可能な範囲（例：301〜400）を取得します。このメカニズムにより、分散環境でも値の割り当てを高速に行えますが、ノード間のキャッシュ値が不連続であるため、値に飛びが生じることがあります。
Lighthouse（軽量アプリケーションサーバー）から TDSQL Boundless に接続するには？
Lighthouse は Tencent Cloud が自動的に割り当てるプライベートネットワーク VPC を使用しており、デフォルトではクラウドデータベース等の他の VPC リソースとは内部ネットワークで接続されていません。接続するには Cloud Connect Network（CCN）との関連付けが必要です。詳細は Lighthouse 内部ネットワーク接続に関する説明をご参照ください。
システムから「インスタンスバージョン検証エラー。カーネルを最新版にアップグレードしてから再試行してください」と表示された場合は？
TDSQL Boundless のカーネルは継続的にアップデートされています。このシステムメッセージが表示された場合は、チケットを送信して Tencent Cloud エンジニアにカーネルのアップグレードを依頼してください。