概要

ドキュメント はJSONオブジェクトです。 また、文書はデータを入れるための器であり、IBM® Cloudant® for IBM Cloud® データベースの基礎となるものです。

IBM Cloudant 上の IBM Cloud® サービスを使用する場合、文書の最大サイズは 1 MB に制限されます。 この制限を超えると、 413 というエラー が発生します。

IBM Cloudant では、データに結果整合性モデルを使用しています。 結果整合性モデルを使用する場合は、一部の状況で古い文書の内容を取得することが起こり得ます。 例えば、アプリケーションで文書の書き込み/更新を行った直後に、その同じ文書が読み取られた場合などに、古い内容が取得されます。

言い換えると、既に実行された書き込み/更新より前の状態の文書の内容がアプリケーションに見えることがあります。 このモデルについて詳しくは、 整合性のトピックを参照してください。

文書フィールド

すべての文書には、次の 2 つのフィールドが必要です。

  • 固有の _id フィールド。 _id フィールドについては、次のセクションで詳しく説明します。
  • _rev フィールド。 _rev フィールドはリビジョンの識別子です。これは、IBM Cloudant複製プロトコルに不可欠です。

この 2 つの必須フィールドに加えて、通常、文書には JSON を使用して記述できる他の内容を含めることができますが、 以下の各セクションで詳しく説明する注意事項に従う必要があります。

文書 ID

文書 ID の形式は、データベースがパーティション化されているかどうかによって異なります。 データベースがパーティション化されている場合は、文書 ID の一部として各文書にパーティション・キーが定義されます。 これについては、次のセクションで詳しく説明します。

パーティション・データベースの場合の ID

パーティション・データベースを使用する場合、文書 ID は、パーティション・キーと文書キーの両方を指すものになります。 以下に示すように、文書 ID をコロンで 2 つの部分に区切って、 これらのキーを指定します。

$PARTITION_KEY:$DOCUMENT_KEY

$PARTITION_KEY 部分は、複数の文書間で同じ場合があります。 この $DOCUMENT_KEY は、各パーティション内で固有でなければなりません。 つまり、1 つのデータベース内では文書 ID 全体が固有である必要があります。 文書キーにはコロン文字を追加で含めることができます。

非パーティション・データベースの場合の ID

パーティション化されていないデータベースの場合、_id フィールドは、ユーザーが作成するか、IBM Cloudant によって UUIDとして 自動的に生成されます。

文書の _id フィールドをユーザーが指定する場合は、7168 文字 (7k) 以下に制限する必要があります。

パーティション・データベースの場合と同様に、文書 ID はデータベース内で固有でなければなりません。

フィールド名の制限

下線文字 (_) で始まるフィールド名は、IBM Cloudant で予約されています。 この規則は、通常、ユーザー作成のフィールド名を下線で始めることはできないことを意味しています。 例えば、 example フィールドは受け入れられますが、_example フィールドは doc_validation というエラー・メッセージが返されます。

下線の接頭部を付けてフィールドを作成しようとする JSON 文書の例を以下に示します。

{
	"_top_level_field_name": "some data"
}

下線の接頭部を付けてフィールドを作成しようとすると返されるエラー・メッセージを以下に示します。

{
	"error": "doc_validation",
	"reason": "Bad special document member: _top_level_field_name"
}

ただし、文書内でネストされたオブジェクトのフィールド名には、 下線の接頭部を使用できます。

下線の接頭部を付けて、オブジェクト内でネストされたフィールドを作成しようとする JSON 文書の例を以下に示します。

{
	"another_top_level_field_name": "some data",
	"another_field": {
		"_lower_level_field_name": "some more data"
	}
}

下線の接頭部を付けて、ネストされたフィールドを作成した場合に返される正常終了メッセージの例 (一部省略しています) を以下に示します。

{
	"ok": true,
	"id": "2",
	"rev": "1-9ce...8d4"
}

クォーラム - データの書き込みおよび読み取り

分散システムでは、要求の実行に時間がかかることがあります。 「クォーラム」メカニズムは、書き込みや読み取りなどの要求がいつ正常に完了するかを 判断するために役立ちます。

クォーラムの設定と、専用の IBM Cloudant システムに対するその設定の影響について詳しくは、 IBM Cloudant サポートにお問い合わせください。

存続時間

有効期間 (TTL)」とは、データの特性の一つであり、 相対的な時間が経過した後、 あるいは特定の絶対時刻に達した時点で、 そのデータは期限切れとみなされるものです。 データ自体は削除されるか、別の (アーカイブ) ロケーションに移動されます。

IBM Cloudant データベース内の Time to Live 機能をサポートしていません。 顧客はこの機能を実装できます。 [View] sを使用してドキュメントを有効期限タイムスタンプでインデックス化し、 定期的にビューをクエリして削除が必要なドキュメントを検索します。