5.3. Debezium MySQL コネクターによるデータ型のマッピング方法

PDF

Debezium MySQL コネクターは、行が存在するテーブルのように構造化されたイベントで行への変更を表します。イベントには、各列の値のフィールドが含まれます。その列の MySQL データ型は、イベントの値を表す方法を指定します。

文字列を格納する列は、文字セットと照合順序を使用して MySQL に定義されます。MySQL コネクターは、binlog イベントの列値のバイナリー表現を読み取るときに、列の文字セットを使用します。

コネクターは MySQL データ型を リテラル 型および セマンティック 型の両方にマップできます。

リテラル型: Kafka Connect スキーマタイプを使用して値がどのように表されるか。
セマンティック型: Kafka Connect スキーマがどのようにフィールド (スキーマ名) の意味をキャプチャーするか。

デフォルトのデータ型変換がニーズを満たさない場合、コネクター用のカスタムコンバータを作成することができます。

詳細は以下を参照してください。

基本型

以下の表は、コネクターによる基本的な MySQL データ型のマッピング方法を示しています。

表5.11 基本型のマッピングの説明
MySQL 型	リテラル型	セマンティック型
`BOOLEAN, BOOL`	`BOOLEAN`	該当なし
`BIT(1)`	`BOOLEAN`	該当なし
`BIT(>1)`	`BYTES`	`io.debezium.data.Bits` `length` パラメーターには、ビット数を表す整数が含まれます。`byte[]` にはビットがリトルエンディアン形式で含まれ、指定数のビットが含まれるようにサイズが指定されます。たとえば、`n` はビットです。 `numBytes = n/8 + (n%8== 0 ?0 : 1)`
`TINYINT`	`INT16`	該当なし
`SMALLINT[(M)]`	`INT16`	該当なし
`MEDIUMINT[(M)]`	`INT32`	該当なし
`INT, INTEGER[(M)]`	`INT32`	該当なし
`BIGINT[(M)]`	`INT64`	該当なし
`REAL[(M,D)]`	`FLOAT32`	該当なし
`FLOAT[(M,D)]`	`FLOAT64`	該当なし
`DOUBLE[(M,D)]`	`FLOAT64`	該当なし
`CHAR(M)]`	`STRING`	該当なし
`VARCHAR(M)]`	`STRING`	該当なし
`BINARY(M)]`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。
`VARBINARY(M)]`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。
`TINYBLOB`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。
`TINYTEXT`	`STRING`	該当なし
`BLOB`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。サイズが最大 2GB の値のみがサポートされます。Claim Check パターンを使用して、大きな列の値を外部化することが推奨されます。
`TEXT`	`STRING`	n/a 2GB までのサイズの値のみがサポートされています。Claim Check パターンを使用して、大きな列の値を外部化することが推奨されます。
`MEDIUMBLOB`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。
`MEDIUMTEXT`	`STRING`	該当なし
`LONGBLOB`	`BYTES` または `STRING`	該当なし `binary.handling.mode` コネクター設定を基にし、raw バイト (デフォルト)、base64 でエンコードされた文字列、または 16 進数でエンコードされた文字列のいずれか。サイズが最大 2GB の値のみがサポートされます。Claim Check パターンを使用して、大きな列の値を外部化することが推奨されます。
`LONGTEXT`	`STRING`	n/a 2GB までのサイズの値のみがサポートされています。Claim Check パターンを使用して、大きな列の値を外部化することが推奨されます。
`JSON`	`STRING`	`io.debezium.data.Json` `JSON` ドキュメント、配列、またはスケーラーの文字列表現が含まれます。
`ENUM`	`STRING`	`io.debezium.data.Enum` `allowed` スキーマパラメーターには、許可される値のコンマ区切りリストが含まれます。
`SET`	`STRING`	`io.debezium.data.EnumSet` `allowed` スキーマパラメーターには、許可される値のコンマ区切りリストが含まれます。
`YEAR[(2\|4)]`	`INT32`	`io.debezium.time.Year`
`TIMESTAMP[(M)]`	`STRING`	`io.debezium.time.ZonedTimestamp` マイクロ秒の精度を持つ ISO 8601 形式。MySQL では、`M` を `0-6` の範囲にすることができます。

時間型

TIMESTAMP データ型を除き、MySQL の時間型は time.precision.mode コネクター設定プロパティーの値によって異なります。デフォルト値が CURRENT_TIMESTAMP または NOW として指定される TIMESTAMP 列では、Kafka Connect スキーマのデフォルト値として値 1970-01-01 00:00:00 が使用されます。

MySQL では、ゼロの値は null よりも優先されることがあるため、DATE、DATETIME、および TIMESTAMP 列にゼロの値を使用できます。MySQL コネクターは、列定義で null 値が許可される場合はゼロの値を null 値として表し、列で null 値が許可されない場合はエポック日として表します。

タイムゾーンのない時間型

DATETIME 型は、2018-01-13 09:48:27 のようにローカルの日時を表します。タイムゾーンの情報は含まれません。このような列は、UTC を使用して列の精度に基づいてエポックミリ秒またはマイクロ秒に変換されます。TIMESTAMP 型は、タイムゾーン情報のないタイムスタンプを表します。これは、書き込み時に MySQL によってサーバー (またはセッション) の現在のタイムゾーンから UTC に変換され、値を読み戻すときに UTC からサーバー (またはセッション) の現在のタイムゾーンに変換されます。以下に例を示します。

値が 2018-06-20 06:37:03 の DATETIME は、1529476623000 になります。
値が 2018-06-20 06:37:03 の TIMESTAMP は 2018-06-20T13:37:03Z になります。

このような列は、サーバー (またはセッション) の現在のタイムゾーンに基づいて、UTC の同等の io.debezium.time.ZonedTimestamp に変換されます。タイムゾーンは、デフォルトでサーバーからクエリーされます。これに失敗した場合は、データベース connectionTimeZone MySQL 設定オプションで明示的に指定される必要があります。たとえば、データベースのタイムゾーン (グローバルなタイムゾーンまたは connectionTimeZone オプションを使用してコネクターのために設定) が America/Los_Angeles である場合、値 2018-06-20T13:37:03Z を持つ ZonedTimestamp によって TIMESTAMP 値の 2018-06-20 06:37:03 が表されます。

Kafka Connect および Debezium を実行している JVM のタイムゾーンは、これらの変換には影響しません。

時間値に関連するプロパティーの詳細は、MySQL コネクター設定プロパティーのドキュメントを参照してください。

time.precision.mode=adaptive_time_microseconds(default)

MySQL コネクターは、イベントがデータベースの値を正確に表すようにするため、列のデータ型定義に基づいてリテラル型とセマンテック型を判断します。すべての時間フィールドはマイクロ秒単位です。正しくキャプチャーされる TIME フィールドの値は、範囲が 00:00:00.000000 から 23:59:59.999999 までの正の値です。

表5.12 time.precision.mode=adaptive_time_microseconds の場合のマッピング
MySQL 型	リテラル型	セマンティック型
`DATE`	`INT32`	`io.debezium.time.Date` エポックからの日数を表します。
`TIME[(M)]`	`INT64`	`io.debezium.time.MicroTime` 時間の値をマイクロ秒単位で表し、タイムゾーン情報は含まれません。MySQL では、`M` を `0-6` の範囲にすることができます。
`DATETIME, DATETIME(0), DATETIME(1), DATETIME(2), DATETIME(3)`	`INT64`	`io.debezium.time.Timestamp` エポックからの経過時間をミリ秒で表し、タイムゾーン情報は含まれません。
`DATETIME(4), DATETIME(5), DATETIME(6)`	`INT64`	`io.debezium.time.MicroTimestamp` エポックからの経過時間をマイクロ秒で表し、タイムゾーン情報は含まれません。

time.precision.mode=connect

MySQL コネクターは定義された Kafka Connect の論理型を使用します。この方法はデフォルトの方法よりも精度が低く、データベース列に 3 を超える 少数秒の精度値がある場合は、イベントの精度が低くなる可能性があります。00:00:00.000 から 23:59:59.999 までの値のみを処理できます。テーブルの time.precision.mode=connect の値が、必ずサポートされる範囲内になるようにすることができる場合のみ、TIME を設定します。connect 設定は、今後の Debezium バージョンで削除される予定です。

表5.13 time.precision.mode=connect の場合のマッピング
MySQL 型	リテラル型	セマンティック型
`DATE`	`INT32`	`org.apache.kafka.connect.data.Date` エポックからの日数を表します。
`TIME[(M)]`	`INT64`	`org.apache.kafka.connect.data.Time` 午前 0 時以降の時間値をマイクロ秒で表し、タイムゾーン情報は含まれません。
`DATETIME[(M)]`	`INT64`	`org.apache.kafka.connect.data.Timestamp` エポックからの経過時間をミリ秒で表し、タイムゾーン情報は含まれません。

10 進数型

Debezium コネクターは、decimal.handling.mode コネクター設定プロパティーの設定にしたがって 10 進数を処理します。

decimal.handling.mode=precise

表5.14 decimal.handling.mode=precise の場合のマッピング
MySQL 型	リテラル型	セマンティック型
`NUMERIC[(M[,D])]`	`BYTES`	`org.apache.kafka.connect.data.Decimal` `scale` スキーマパラメーターには、小数点を移動した桁数を表す整数が含まれます。
`DECIMAL[(M[,D])]`	`BYTES`	`org.apache.kafka.connect.data.Decimal` `scale` スキーマパラメーターには、小数点を移動した桁数を表す整数が含まれます。

decimal.handling.mode=double

表5.15 decimal.handling.mode=double の場合のマッピング
MySQL 型	リテラル型	セマンティック型
`NUMERIC[(M[,D])]`	`FLOAT64`	該当なし
`DECIMAL[(M[,D])]`	`FLOAT64`	該当なし

decimal.handling.mode=string

表5.16 decimal.handling.mode=string の場合のマッピング
MySQL 型	リテラル型	セマンティック型
`NUMERIC[(M[,D])]`	`STRING`	該当なし
`DECIMAL[(M[,D])]`	`STRING`	該当なし

ブール値

MySQL は、特定の方法で BOOLEAN の値を内部で処理します。BOOLEAN 列は、内部で TINYINT(1) データ型にマッピングされます。ストリーミング中にテーブルが作成されると、Debezium は元の DDL を受信するため、適切な BOOLEAN マッピングが使用されます。スナップショットの作成中、Debezium は SHOW CREATE TABLE を実行して、BOOLEAN と TINYINT(1) の両方のカラムに TINYINT(1) を返すテーブル定義を取得します。その後、Debezium は元の型のマッピングを取得する方法はないため、TINYINT(1) にマッピングします。

ソースカラムをブール型に変換できるように、Debezium は TinyIntOneToBooleanConverter カスタムコンバーターを提供しており、以下のいずれかの方法で使用することができます。

すべての TINYINT(1) または TINYINT(1) UNSIGNED 列を BOOLEAN 型にマップします。
正規表現のコンマ区切りリストを使用して、列のサブセットを列挙します。
このタイプの変換を使用するには、以下の例のように selector パラメーターを使用して converters 設定プロパティーを設定する必要があります。
```
converters=boolean
boolean.type=io.debezium.connector.mysql.converters.TinyIntOneToBooleanConverter
boolean.selector=db1.table1.*, db1.table2.column1
```
注:MySQL8 では、SHOW CREATE TABLE を実行時に tinyint unsigned 型の長さが表示されないため、このコンバータは機能しません。新しいオプション length.checker はこの問題を解決することができます。デフォルト値は true です。length.checker を無効にし、以下の例のように、タイプに基づいてすべての列を変換するのではなく、変換が必要な列を selector プロパティーに指定します。
```
converters=boolean
boolean.type=io.debezium.connector.mysql.converters.TinyIntOneToBooleanConverter
boolean.length.checker=false
boolean.selector=db1.table1.*, db1.table2.column1
```

空間型

現在、Debezium MySQL コネクターは以下の空間データ型をサポートしています。

表5.17 空間型マッピングの説明
MySQL 型	リテラル型	セマンティック型
`GEOMETRY, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, GEOMETRYCOLLECTION`	`STRUCT`	`io.debezium.data.geometry.Geometry` : フィールドが 2 つの構造が含まれます。 `srid (INT32`: 構造に保存されたジオメトリーオブジェクトの型を定義する、空間参照システム ID。 `wkb (BYTES)`: wkb (Well-Known-Binary) 形式でエンコードされたジオメトリーオブジェクトのバイナリー表現。詳細は、Open Geospatial Consortium を参照してください。

5.3. Debezium MySQL コネクターによるデータ型のマッピング方法

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links