📣新登場！TiDB Cloud BYOC、TiDB Cloud Filesystem、PostgreSQL-compatible TiDB Cloud Starter がパブリックプレビュー中。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者
ベストプラクティス
API

TiDB Cloud Lake PoC ガイド

このガイドでは、TiDB Cloud Premium インスタンスから TiDB Cloud Lake へのデータレプリケーションを主な例として、TiDB Cloud Lake の再現可能な概念実証（PoC）について説明します。代表的なワークロードに最も大きな影響を与える判断事項、すなわちオブジェクトストレージと PrivateLink 接続、スキーマ互換性、データレイアウト、オーバーラップのメンテナンス、ブロックサイズ、事前集計に焦点を当てています。

PoC は、代表的なデータサンプルと本番で使用されるクエリパターンで実行してください。クエリレイテンシー、QPS、Warehouse サイズ、ストレージサイズを記録し、各最適化を同じベースラインで比較できるようにします。

ステップ 1. S3 接続を設定する

ソースパイプラインがすでに Parquet、CSV、または JSON オブジェクトをオブジェクトストレージに書き込んでいる場合は、S3 バケットを使用します。Home > Connect で TiDB Cloud Lake デプロイメント用の IAM role ARN を取得し、AWS IAM Role による認証 に従って S3 接続、stage、およびデータロードを設定します。

トラフィックをプライベートネットワーク経路内に留める必要がある場合は、PrivateLink を使用します。Home > Connect で PrivateLink サービスを取得し、AWS PrivateLink で接続する に従って接続を設定します。ロードを開始する前に、クライアントまたはソースクラスターから、エンドポイント、セキュリティグループルール、DNS の動作、およびルートを確認してください。

ステップ 3. Data Pipeline を使用して TiDB Cloud Premium インスタンスから TiDB Cloud Lake にデータをレプリケートする

TiDB Cloud Data Pipeline を使用すると、サードパーティの ETL ツールを導入せずに、TiDB Cloud Premium インスタンスから TiDB Cloud Lake にデータをレプリケートできます。Data Pipeline はまず選択したソースデータの完全なスナップショットをエクスポートし、その後、行レベルの変更を継続的にレプリケートすることで、TiDB Cloud Lake 内のデータを最新の状態に保ちます。

Data Pipeline は増分レプリケーションに TiCDC を使用し、TiDB Cloud と TiDB Cloud Lake 間でデータを転送するために外部 stage を使用します。PoC を開始する前に、必要な機能が使用中の TiDB Cloud プランで利用可能であること、および外部 stage とアクセスポリシーが設定されていることを確認してください。現在の提供状況と設定要件については、Data Pipeline to TiDB Cloud Lake を参照してください。

PoC では、代表的なテーブルを選択し、それらのスキーマ、想定行数、および鮮度目標を記録します。初期スナップショットの完了後、行数、null 数、サンプル集計、最小値と最大値をソースと比較してください。次に、ソースで代表的な insert、update、delete を生成し、TiDB Cloud Lake に期待されるレプリケーションレイテンシー内で反映されることを確認します。レプリケートされたテーブルをクエリ性能テストに使用する前に、スナップショット所要時間、レプリケーション遅延、拒否されたレコード、スキーママッピングエラーを記録してください。

ソーススキーマをマッピングして検証する

ファイルをロードしたりレプリケーションを開始したりする前に、各ソースカラムと対応する Lake カラム、データ型、null 許容性、デフォルト値、および必要な変換を記録してください。decimal の精度とスケール、signed および unsigned 整数の範囲、タイムスタンプの精度とタイムゾーン、文字列エンコーディングを確認します。ターゲット型の選択には Lake データ型リファレンス を使用してください。型名が一致していても意味論が同一であるとは限りません。

null と境界値を含む小さなサンプルをロードします。同じスナップショットまたはレプリケーションチェックポイント時点で、行数、null 数、最小値と最大値、および集計結果をソースと比較してください。変換によって精度とタイムスタンプの意味が保持されていることを確認し、完全ロードを開始する前に、拒否または切り捨てられた値を調査してください。

ステップ 4. 性能ベースラインを確立する

Lake のクエリ性能に影響する主な要因は次のとおりです。

  1. Warehouse リソース。 CPU、メモリ、Warehouse サイズ、および同時実行制限によって、一度に実行できる作業量が決まります。
  2. データレイアウト。 クラスターキーの順序、ブロックのオーバーラップ、ブロックサイズによって、どれだけデータをプルーニングできるかが決まります。
  3. クエリパターン。 必要なカラムだけを射影し、可能であれば選択性の高い述語に先頭のクラスターキーカラムを含めてください。

各ベースラインクエリについて EXPLAIN の出力を取得してください。TableScan が支配的な場合は、同時実行数を増やす前に、クラスターキープルーニング、オーバーラップメトリクス、ブロックサイズ、キャッシュヒット率、および Warehouse キャパシティを確認します。

ステップ 5. ワークロードに効果がある場合はクラスターキーを選択する

予測可能なフィルターや範囲スキャンを伴う大きなテーブルを作成する場合は、クラスターキーを評価してください。小さなテーブル、ランダムアクセスパターン、頻繁な変更では、メンテナンスコストを正当化できるほどの効果が得られない可能性があります。フィルター、テーブル結合、または範囲スキャンで頻繁に使用されるカラムを使い、最もよくフィルターされるカラムを先頭に配置してください。キー式は簡潔に保ちます。長い文字列には、長さを制限したプレフィックス式を使用してください。

CREATE TABLE lineitem (
  l_orderkey BIGINT NOT NULL,
  l_partkey INT NOT NULL,
  l_shipdate DATE NOT NULL,
  l_quantity DECIMAL(15, 2) NOT NULL,
  l_extendedprice DECIMAL(15, 2) NOT NULL
)
ENGINE = FUSE
CLUSTER BY (DATE_TRUNC(MONTH, l_shipdate), l_orderkey)
COMPRESSION = 'zstd'
STORAGE_FORMAT = 'parquet';

クラスターキーのない大きなテーブルで、範囲述語が多数のブロックをスキャンしている場合は、クエリ性能を比較する前に、キーの追加と再クラスタリングを評価してください。

ALTER TABLE lineitem CLUSTER BY (DATE_TRUNC(MONTH, l_shipdate), l_orderkey);
ALTER TABLE lineitem RECLUSTER FINAL;

キー設計の詳細については、クラスターキーガイド を参照してください。

ステップ 6. オーバーラップを監視し、RECLUSTER FINAL を実行する

クラスターキーは、グローバルにソートされた単一ファイルを強制するものではありません。バルクロードや大規模な変更によって、多くのブロックがオーバーラップしたままになり、取り込みを高速に保ちながらもプルーニング効率を低下させることがあります。初期ロード後、および大きなデータ変更後に、オーバーラップメトリクスが必要性を示している場合は、次の操作を実行してください。操作中は、そのテーブルへのレプリケーションを含む書き込みを一時停止します。RECLUSTER の実行中は DML を実行しないでください。詳細については、RECLUSTER TABLE を参照してください。

ALTER TABLE lineitem RECLUSTER FINAL;

再クラスタリングの前後で CLUSTERING_INFORMATION を確認してください。average_overlaps、average_depth、block_depth_histogram を、スキャンされたバイト数およびクエリレイテンシーとあわせて追跡します。一般に、深さとオーバーラップが低いほど、より良いクラスタリングを示します。データ分布に対して有用なメンテナンス閾値を確立するために、再クラスタリングの前後で同じワークロードを比較してください。

CREATE TABLE mytable(a INT, b INT) CLUSTER BY (a + 1);

INSERT INTO mytable VALUES (1, 1), (3, 3);
INSERT INTO mytable VALUES (2, 2), (5, 5);
INSERT INTO mytable VALUES (4, 4);

SELECT * FROM CLUSTERING_INFORMATION('default', 'mytable')\G
*************************** 1. row ***************************
            cluster_key: ((a + 1))
      total_block_count: 3
   constant_block_count: 1
 unclustered_block_count: 0
       average_overlaps: 1.3333
          average_depth: 2.0
   block_depth_histogram: {"00002":3}

次のメトリクス要約は、比較的中程度のオーバーラップを示しています。これらの値は普遍的に健全な閾値でも、この関数の完全な出力でもありません。

{
  "cluster_key": "(yyyymm)",
  "info": {
    "average_depth": 40.6131,
    "average_overlaps": 40.7653,
    "total_block_count": 473
  },
  "type": "linear"
}

次のメトリクス要約は深刻なオーバーラップを示しています。average_depth が総ブロック数に近くなっています。このパターンが続く場合は、クエリスキャンとレイテンシーを見直し、再クラスタリングをスケジュールし、クラスターキー設計を再検討してください。

{
  "cluster_key": "(DATE_TRUNC(MONTH, l_shipdate), l_orderkey)",
  "info": {
    "average_depth": 10181.3357,
    "average_overlaps": 10211.5616,
    "total_block_count": 10214
  },
  "type": "linear"
}

継続的に変化するテーブルについては、DML とレプリケーション書き込みを一時停止できるメンテナンスウィンドウ中に再クラスタリングをスケジュールしてください。観測されたオーバーラップ傾向に基づいてスケジュールを決定し、その計算コストを測定します。次の 1 時間ごとのタスクは一例です。これは書き込み元を一時停止しないため、再開する前にメンテナンスウィンドウを調整してください。

CREATE OR REPLACE TASK lineitem_hourly
  WAREHOUSE = 'default'
  SCHEDULE = 60 MINUTE
  COMMENT = 'Hourly FINAL recluster for lineitem'
AS
  ALTER TABLE lineitem RECLUSTER FINAL;

ALTER TASK lineitem_hourly RESUME;

ステップ 7. 適切なブロックサイズを選択する

書き込みパターンに合ったブロックサイズから開始してください。

  • 大規模な追記と分析読み取りについては、536870912 bytes (512 MiB) の閾値を評価します。
  • 頻繁な小規模 insert、update、delete については、書き換えコストと書き込み増幅を減らすために、より小さいブロックを評価します。

PoC データをロードする前に、このオプションを適用してください。

ALTER TABLE lineitem SET OPTIONS (BLOCK_SIZE_THRESHOLD = 536870912);

これは評価の出発点であり、普遍的なデフォルトではありません。同じデータとクエリで、ロード時間、書き込みコスト、スキャンされたバイト数、およびクエリレイテンシーを比較してください。

ステップ 8. 繰り返し行う集計にはマテリアライズドビューを使用する

ワークロードが同じ粒度で 1 つのテーブルを繰り返し集計する場合は、マテリアライズドビューを使用して、頻繁にクエリされるディメンションを事前集計してください。ベーステーブルとビューのクラスターキーをダッシュボードの述語に合わせ、その後、同じ Warehouse とキャッシュ条件の下で、ビューに対するクエリをベースラインと比較する前に、ビューをリフレッシュします。作成時には定義が記録され、最初のリフレッシュで物理ストレージにデータが格納されます。

CREATE TABLE fact_table (
  tenant_id INT,
  account BIGINT,
  category_id INT,
  amount DECIMAL(19, 6)
);

-- Load representative data into fact_table before benchmarking.
CREATE MATERIALIZED VIEW mv_account_totals
  (tenant_id, account, category_id, total_amount)
CLUSTER BY (tenant_id, account)
AS
SELECT
  tenant_id,
  account,
  category_id,
  SUM(amount) AS total_amount
FROM fact_table
GROUP BY tenant_id, account, category_id;

REFRESH MATERIALIZED VIEW mv_account_totals;

マテリアライズドビューは、単一テーブルの集計に最も適しています。詳細については、TiDB Cloud Lake のマテリアライズドビューのドキュメント を参照してください。

このページは役に立ちましたか？