TiDB Cloud Serverless Export (ベータ版) を試す
TiDB Serverless にデータExport機能が備わったとのことで、早速試してみます。TiDB はご存じの通りMySQL互換がウリですので、mysql dumpやdumpling等のツールやSQL等でデータを抽出することが出来ます。ただしその場合メインクラスターのコンピュートリソースを消費するため商用環境からのデータエクスポートは気を付けて行う必要があります。
TiDB Cloud Serverless Export は現在ベータ版ではありますが、オンライン状態のデータベースから分離したコンピュートリソースによるデータエクスポートをPingCapが保証してくれるというメリットがあります。
データエクスポート先
データのエクスポートはローカルファイルに加えて、Amazon S3,Google Cloud Storage, Azure BLOB ストレージを直接指定することが可能です。
エクスポート形式
エクスポートされるデータは以下のいずれかの形式を選択可能です。
・SQL形式
・CSV形式
・Parquest形式（TiDB Cloud CLI による操作のみ）
また圧縮をサポートしており以下の形式から選択可能です。
・zstd
・gzip
・snappy
・非圧縮
Parquet 形式の注意点
これはTiDBに限った話ではなくParquet形式でデータを取り扱う際の注意点です。
でも触れましたがParquet形式はカラムナ型データフォーマットとして特にOLAP環境で高い処理効率を誇ります。Parquetはデータ型定義を保有しておりこれにより処理の効率化を実現させていますが、一般的には商用で用いられるデータベースエンジンより少ない方をサポートしています。このためParquet形式
でデータをエクスポートすると一部の方が変換される場合があります。データ分析に用いる場合は汎用的な方に変換することは問題ないかもしれない（データが消えない、書き換わらないかは要確認）ですが、再度DBへインポートするには不向きですので、バックアップには向かない形式と言えます。
詳しくはこちらの表を参照してください。
さっそくやってみる
では作業をしてみます。ExportはマネージメントコンソールかPostman TiDB CLIから操作できます。TiDB CLIは以下にまとめていますので併せてご参考ください。
TiDB Cloud CLI でのみできること
・ローカル環境をExport先に指定した場合のデータのダウンロード（コンソールからだとTiDB Cloud環境のスタッシング領域にのみ保存されます）
・Azure Blob Storage へのエクスポート
・Google Cloud Storage へのエクスポート
この手順ではAmazon S3を用いてコンソールからエクスポートを行います。
1. Amazon S3バケットの準備
まず全てデフォルトのままS3バケットを適当な名前で作成します。
次にフォルダを１個作成します。AppFlow同様、バケット直下はNGの様です。
2. IAMユーザーの作成
以下のポリシーをアタッチしたIAMユーザーを作成します。
より権限を絞るならstorage.objects.createを個別に指定してください。
作成のあとセキュリティ認証情報タブからアクセスキーを作成をクリックします。
発行されたアクセスキーとシークレットアクセスキーをコピーしておきます。
3.TiDB Cloud でのExport設定
Exportの設定画面は少し見つけづらいです。まずはクラスターを選択してImportをクリックします。
そうすると画面の下の方に小さい文字でLooking for data export? と表示されていますのでそこをクリックします。
Amazon S3を選択します。
Exportしたいテーブルを指定します。
フォーマットと圧縮形式を指定します。
S3バケット名とクレデンシャルをセットします。S3バケット名は必ずフォルダ名が必要です。また文字列の最後は/で終わらせてください。
タスクが実行中になるので待ちます。
完了しました！
4.確認
TiDB Clusterの方ではRequest Unitsが消費されていることがわかります。TiDB Cloud Serverless Export自体は無料ですが、ここは課金に影響を与えることに注意してください。そのいっぽうでSQLが実行されていないことがわかります。オンラインクラスターへのパフォーマンスへは影響を及ぼしていないことが判断できます。
S3には４つのオブジェクトが作成されています。
Started dump at: 2024-10-09 06:43:10
SHOW MASTER STATUS:
Log: tidb-binlog
Pos: 453104417075625984
GTID:
Finished dump at: 2024-10-09 06:43:11
これはジョブのステータスを表す情報が含まれています。
次にtest-schema-create.sqlです。
/*!40014 SET FOREIGN_KEY_CHECKS=0*/;
/*!40101 SET NAMES binary*/;
CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
これはtestというスキーマを作成するためのものです。
次にtest.appflow.schema.sqlです。
/*!40014 SET FOREIGN_KEY_CHECKS=0*/;
/*!40101 SET NAMES binary*/;
CREATE TABLE `appflow` (
`column1` varchar(255) NOT NULL,
`column2` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
これはtestスキーマの中のappflowテーブルを作成します。
最後にtest.appflow.0000000010000.sqlです。
/*!40014 SET FOREIGN_KEY_CHECKS=0*/;
/*!40101 SET NAMES binary*/;
INSERT INTO `appflow` VALUES
('value1','value2'),
('value3','value4'),
('value5','value6'),
('value7','value8'),
('value1','null'),
('value3','null'),
('value5','null'),
('value7','null'),
('value1','null'),
('value3','null'),
('value5','null'),
('value7','null'),
('value1','null'),
('value3','null'),
('value5','null'),
('value7','null');
テーブルにデータを復元するINSERTSQLが含まれています。
Discussion