Confluent Cloud スキーマ管理のドキュメントをお探しですか? これらのページでは、Schema Registry の全体的な概念、スキーマフォーマット、ハイブリッドのユースケース、チュートリアルといったポイントに触れていますが、最も重点的に取り上げているのは Confluent Platform です。Confluent Cloud のドキュメントについては、Confluent Cloud でのスキーマの管理」をご覧ください。

スキーマ削除のガイドライン¶

Schema Registry API により、サブジェクトの特定のスキーマバージョンまたはサブジェクトのすべてのバージョンの削除ができます。論理的な削除では、対象のバージョンのみが API により削除され、ベースとなるスキーマ ID は引き続きルックアップに利用できます。

スキーマの論理的な削除¶

# Deletes all schema versions registered under the subject "Kafka-value"
  curl -X DELETE http://localhost:8081/subjects/Kafka-value
  [1]

# Deletes version 1 of the schema registered under subject "Kafka-value"
  curl -X DELETE http://localhost:8081/subjects/Kafka-value/versions/1
  1

# Deletes the most recently registered schema under subject "Kafka-value"
  curl -X DELETE http://localhost:8081/subjects/Kafka-value/versions/latest
  1

ちなみに

Confluent Cloud のウェブ UI と CLI では、削除されたスキーマの数として報告される情報に違いが生じることがあります。「スキーマの物理的な削除」と「スキーマの削除、バージョン管理、互換性に関する内部情報」も参照してください。

スキーマの物理的な削除¶

Confluent Platform と Confluent Cloud のどちらでも、クエリ文字列 ?permanent=true を使用することで、スキーマの物理的な削除がサポートされるようになりました。物理的な削除では、スキーマ ID を含め、すべてのメタデータが削除されます。これは、レジストリでサポートされるスキーマのバージョン数に制限のある Confluent Cloud で、新しいスキーマを登録できるよう領域を解放する際に役立ちます。

物理的な削除は、サブジェクト下またはサブジェクトの特定のバージョンで登録されているすべてのスキーマバージョンで実行できます。

スキーマ（すべてのバージョンまたは特定のバージョン）の物理的な削除を実行するには、以下の 2 段階のプロセスを使用します。まずスキーマの論理的な削除を行ってから物理的な削除を実行します。

スキーマのすべてのバージョンに対して論理的な削除を実行します。

curl -X DELETE -u <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/my-existing-subject

このコマンドに ?permanent=true を追加して、スキーマのすべてのバージョンに対して物理的な削除を実行します。
```
curl -X DELETE -u <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/<my-existing-subject>?permanent=true
```

次のコマンドは、"Kafka-value" というサブジェクトで登録されているスキーマのすべてのバージョンに対して物理的な削除を実行します。

curl -X DELETE <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/Kafka-value
curl -X DELETE <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/Kafka-value?permanent=true

Kafka-value というサブジェクトで登録されているスキーマのバージョン 1 に対して物理的な削除するには、次のコマンドを実行します。

curl -X DELETE <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/Kafka-value/versions/1
curl -X DELETE <schema-registry-api-key>:<schema-registry-api-secret> <schema-registry-url>/subjects/Kafka-value/versions/1?permanent=true

ちなみに

バージョンを指定して物理的な削除を実行するためには、バージョン番号を入力する必要があります。 version:latest で実行されるのは、論理的な削除のみです。

これらの API を使用するためのガイドライン¶

上記の API は、主に開発環境での使用が意図されています。開発環境では、イテレーションを経てスキーマを仕上げるのが一般的です。本稼働環境での使用は推奨されませんが、これらの API を本稼働環境で使用できるシナリオもごくまれにあります。その場合は細心の注意を払ってください。

登録しようとしている新しいスキーマに、既存のスキーマバージョンとの互換性の問題があります。
同じサブジェクトに対して古いバージョンのスキーマを再度登録する必要があります。
対象のスキーマはリアルタイムストリーミングシステムでのみ使用され、古いバージョンが不要なことを確認できています。
トピックをリサイクルする必要があります。
Confluent Cloud に新しいスキーマを登録できるよう領域を解放する必要があります（スキーマを物理的に削除することで領域を解放します）。

また、サブジェクトに互換性設定が登録されている場合、サブジェクトの削除を実行時や、利用可能なスキーマバージョンのみを削除時にそれらの設定もすべて削除されるので注意してください。

Confluent Cloud で使用可能なスキーマの表示¶

Confluent Cloud ウェブ UI または CLI から、使用可能なスキーマと使用済みのスキーマを表示し、論理的に削除されたスキーマの数を推測することができます。

Confluent Cloud CLI では、ccloud schema-registry cluster describe を使用して、現在選択されている環境で使用可能なスキーマの数を表示できます。その例を次に示します。

$ ccloud schema-registry cluster describe
+----------------------+----------------------------------------------------+
| Name                 | account schema-registry                            |
| Cluster ID           | lsrc-g2p81                                         |
| Endpoint URL         | https://psrc-0xx5p.us-central1.gcp.confluent.cloud |
| Used Schemas         |                                                  7 |
| Available Schemas    |                                                993 |
| Global Compatibility | <Requires API Key>                                 |
| Mode                 | <Requires API Key>                                 |
| Service Provider     |                                                    |
+----------------------+----------------------------------------------------+

"Used Schemas" には、アクティブなスキーマと論理的に削除されたスキーマの合計数が報告されます。アクティブなスキーマの数がわかっていれば、論理的に削除されたスキーマの数を推測できます。スキーマが物理的に削除された場合は、それに応じて使用済みのスキーマの数が減り、使用可能なスキーマの数が増えます。

スキーマの削除、バージョン管理、互換性に関する内部情報¶

スキーマを削除した場合、実際には、スキーマのバージョン管理されたインスタンスだけが削除されます。スキーマそのもの（ハッシュ化された ID を持つスキーマ）は削除されません。スキーマの正規の MD5 ハッシュはシステムに存在し続けます。REST API で、削除済みのスキーマに対してルックアップを実行できるのはこのためです。

たとえば、サブジェクトに 3 つのバージョンがあるとします。3 番目を削除して同じスキーマをもう一度登録すると、そのスキーマはバージョン 3 として登録され、関連付けられたスキーマは以前と同じ ID を持つことになります。これは、ハッシュが既存のものと一致するためです。

Avro シリアライザーで Avro データをシリアル化するときには、サブジェクトに固有のバージョンではなく、ID が格納されます。（サブジェクト内の）バージョンが削除されても、スキーマとその ID は Schema Registry に残るため、Schema Registry を使用してデータを逆シリアル化することができます。

これはバージョン管理と互換性に影響します。たとえば、特定のサブジェクトに対して次の 2 つのスキーマがあるとします。

スキーマ ID: 23、バージョン 1、フィールド（a、b）
スキーマ ID: 45、バージョン 2、フィールド（a、b、c）

バージョン 2 を削除すると、バージョン 1 が最新バージョンになります。

互換性レベルが BACKWARD の場合、サブジェクトに登録されている次のスキーマにはバージョン 1 との後方互換性のみが求められ、バージョン 2 との互換性は求められません。