--- title: "NoSQLのコンポーネント" url: https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/components/ description: "Catalyst NoSQLは、非リレーショナル・非SQLのデータストレージ手段を提供するフルマネージドで強力なデータベースです。NoSQLテーブルでのデータの作成、管理、クエリを簡単に行い、Java、Node.js、PythonでCRUD操作を実行できます。" last_updated: 2026-02-23T12:39:41Z service: Cloud Scale type: general --- # NoSQLのコンポーネント Catalyst NoSQLデータベースのアーキテクチャを理解し、操作方法を学ぶには、まずNoSQLデータベースを構成するコンポーネントを理解する必要があります。 ### 基本コンポーネント Catalyst NoSQLに関わる基本的なコンポーネントを以下に説明します。 #### 用語
コンポーネント名 説明
**テーブル** テーブルは、NoSQLがデータを格納する基本構造です。リレーショナルデータベースと同様に、テーブルはレコードまたはアイテムで構成されます。 以下に示すサンプルテーブルTravelは、訪問可能な旅行先のデータと、各場所の主要な情報を保持しています。
**属性** 属性は、テーブル内のデータ値の特性を表します。NoSQLの属性は、リレーショナルデータベースのフィールドやカラムに相当し、各属性は特定のデータ型のデータを保持します。 以下のサンプルテーブル*Travel*には、`DestinationName`、`Distance`、`BestTimeToVist`、`Location`、`EstimatedCost`の属性が含まれています。
**アイテム** アイテムは、単一のデータポイントのデータを保持する属性のコレクションです。NoSQLのアイテムは、リレーショナルデータベースの行やレコードに相当し、異なる属性の値を含むことができます。 サンプルテーブル*Travel*では、`DestinationName`で一意に識別される各データコレクションがアイテムです。例えば、`Distance`、`BestTimeToVisit`、`EstimatedCost`の値のセットも含む「Honolulu」のレコードはアイテムです。同様に、異なる属性値を持つ「Prague」で識別されるレコードもアイテムです。 > **注意:** Catalyst NoSQLでプロビジョニングされるアイテムの最大合計サイズは**400 KB**です。
**データ** Catalyst NoSQLの用語では、テーブルのデータは、[CatalystカスタムJSON形式](https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/working-with-data/introduction/#the-catalyst-custom-json-format)で存在するすべての属性とアイテムで構成されます。 *Travel*テーブルの以下のJSONコードは、テーブルのデータを表しています。[データの操作](https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/working-with-data/introduction/)ヘルプセクションでは、カスタムJSONデータ形式とサポートされるデータ型について詳しく説明しています。
#### サンプルテーブルの表現 **テーブル名**: Travel ```json { "item": { "DestinationName": { "S": "Honolulu" }, "Distance": { "N": 4960 }, "BestTimeToVist": { "L": [ { "S": "September" }, { "S": "October" }, { "S": "November" } ] }, "EstimatedCost": { "N": 2500 } }, "item": { "DestinationName": { "S": "Prague" }, "Distance": { "N": 4081 }, "Location": { "M": { "Country": { "S": "Czech Republic" }, "Continent": { "S": "Europe" } } }, "EstimatedCost": { "N": 3000 } }, "item": { "DestinationName": { "S": "Marrakesh" }, "Distance": { "N": 3700 }, "BestTimeToVist": { "L": [ { "S": "March" }, { "S": "April" }, { "S": "September" }, { "S": "October" } ] }, "Location": { "M": { "Country": { "S": "Morocco" }, "Continent": { "S": "Africa" } } }, "EstimatedCost": { "N": 1700 } } } ``` *Travel*テーブルは、CatalystカスタムJSON形式のシンプルなNoSQLテーブルを表しています。この構造にはネストされた属性と配列が含まれています: `BestTimeToVist`はリストデータ型（"L"）の配列として存在し、`Location`属性は`Country`と`Continent`のキーを含むマップデータ型（"M"）のネストされた属性です。 > **注意:** ここに示されているテーブルは**CatalystカスタムJSON形式**の表現です。このJSON形式で各サーバーサイドSDKのデータを構築するフォーマットは異なります。このテーブルに示されているCatalystカスタムJSON形式の一般的な構文、サポートされるデータ型とその表記については、[このセクション](https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/working-with-data/introduction/#the-catalyst-custom-json-format)を参照してください。 ### テーブルキー 一般的なNoSQLアーキテクチャに従い、Catalyst NoSQLはクラスター全体のパーティション（シャードとも呼ばれる）にデータを格納します。これらのシャードは、ミラー内の多くのサーバーにレプリケーションすることもできます。複数のノードにまたがるこの分散ストレージにより、データセットが小さなチャンクに分割され、最適化が促進されます。 NoSQLテーブルでデータをクエリする際、特定のアイテムが格納されているパーティションを特定する必要があります。さらに、パーティション内をソートしてアイテムを見つけるためにも追加の作業が必要です。これらは、以下で説明するように、パーティションを識別またはソートするための固有のキーの助けを借りて実現されます。 #### 用語
コンポーネント名 説明
**パーティションキー** パーティションキーは、データアイテムが格納されている分散ストレージ内の論理パーティションを識別します。これらの論理パーティションは、ハッシュ関数を通じてバックエンドの物理ストレージノードにマッピングされます。 以下で説明するサンプルテーブル*Menu*では、属性Categoryがパーティションキーです。
**ソートキー** プライマリソートキーは、特定のパーティション内をソートしてデータアイテムを見つけ、データ内のパーティションキーに一致するアイテムが1つ以上ある場合はソート順で返します。これは、キーハッシュの範囲から識別することで行われます。Catalystでは、NoSQLテーブル作成時にオプションでソートキーを追加できます。 以下で説明するサンプルテーブル*Menu*では、属性`DishName`がソートキーとして使用されます。
**シンプルプライマリキー** Catalyst NoSQLのシンプルプライマリキーは、パーティションキーのみを示します。 NoSQLテーブルにソートキーなしでパーティションキーのみを設定する場合、パーティションキーがテーブルのプライマリキーとして機能し、アイテムを一意に識別します。これは、リレーショナルデータベースのプライマリキーの概念と同様です。 前のセクションで説明したサンプルテーブル*Travel*では、属性`DestinationName`がプライマリキーとして使用されます。この属性はすべてのアイテムに存在する必要があり、この属性に同じ値を持つ2つのアイテムは存在できません。 ただし、以下で説明するサンプルテーブル*Menu*では、パーティションキー`Category`はアイテムを一意に識別しません。同じ値を持つ複数のアイテムが存在できるためです。これは、*Menu*テーブルが複合プライマリキーを使用しているためです。
**複合プライマリキー** 複合プライマリキーは、パーティションキーとソートキーの両方を含み、アイテムを一意に識別します。つまり、両方のキーの組み合わせがプライマリキーとして機能します。複合プライマリキーを使用したテーブルのクエリは、データが複数のパーティションにまたがるため、グローバルです。 パーティションキーが一意である必要があるシンプルプライマリキーとは異なり、ソートキーも定義する限り、パーティションキーに非一意の値を格納できます。 > **注意:** テーブル内で同じパーティションキーを持つすべてのアイテムについて、ソートキーは一意である必要があります。 以下で説明するサンプルテーブル*Menu*には、パーティションキー`Category`とソートキー`DishName`が一緒にデータアイテム（料理）を一意に識別する複合プライマリキーが含まれています。
**追加ソートキー** Catalyst NoSQLでは、複合プライマリキーの一部であるメインソートキー以外に、追加のソートキーを設定できます。 追加ソートキーは、メインソートキー以外の異なるキーに基づいてソートを実行する必要がある場合や、特定のアイテムのメインソートキーが不明な場合に使用されます。この場合、パーティションキーと追加ソートキーの組み合わせが複合プライマリキーとして使用されます。 追加ソートキーを使用したテーブルのクエリは、ローカルインデックスに類似しており、すべて同じパーティションキーと共に使用され、その特定のパーティション内のみでソートされます。 > **注意:** Catalystでは、テーブルに対して**最大5つの追加ソートキー**を設定できます。 以下で説明するサンプルテーブル*Menu*では、属性`PreparationTime`と`Calories`が追加ソートキーとして設定されています。
#### サンプルテーブルの表現 **テーブル名**: Menu ```json { "item": { "Category": { "S": "Pizza" }, "DishName": { "S": "Vegan" }, "Calories": { "N": 350 }, "PreparationTime": { "N": 20 }, "Cost": { "N:" 25 }, "DiscountPercentage": { "N": 5 }, "KeyIngredients": { "L": [ { "S": "Pizza Base" }, { "S": "Pizza Sauce" }, { "S": "Olives" }, { "S": "Bell Peppers" }, { "S": "Corn" }, { "S": "Onions" } ] } }, "item": { "Category": { "S": "Pizza" }, "DishName": { "S": "Chicken Overload" }, "Calories": { "N": 450 }, "PreparationTime": { "N": 30 }, "KeyIngredients": { "L": [ { "S": "Pizza Base" }, { "S": "Pizza Sauce" }, { "S": "Fried Chicken" }, { "S": "Paprika" } ] } }, "item": { "Category": { "S": "Sandwich" }, "DishName": { "S": "Vegan" }, "Calories": { "N": 300 }, "PreparationTime": { "N": 20 }, "Cost": { "N": 25 }, "DiscountPercentage": { "N": 15 } } } ``` *Menu*テーブルにはさまざまな属性が含まれており、`Category`がパーティションキー、`DishName`がソートキー、`PreparationTime`と`Calories`が追加ソートキーです。 > **注意:** ここに示されているテーブルは**CatalystカスタムJSON形式**の表現です。このJSON形式で各サーバーサイドSDKのデータを構築するフォーマットは異なります。このテーブルに示されているCatalystカスタムJSON形式の一般的な構文、サポートされるデータ型とその表記については、[このセクション](https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/working-with-data/introduction/#the-catalyst-custom-json-format)を参照してください。 複合プライマリキーはデータクエリを強化します。このテーブルがシンプルプライマリキーのみ（つまりCategory（例:「Pizza」））で設定されている場合、クエリするとその`Category`のすべてのアイテム（メニュー内のすべての「ピザ」）が取得されます。ただし、複合プライマリキー（つまり`Category`と`DishName`）で設定されているため、両方のキーでクエリすると、それらの値の一意のアイテム（例:「Pizza」と「Vegan」）が取得されます。 同様に、追加ソートキーは同じパーティション内でテーブルをクエリする際にさらなる柔軟性を提供します。追加ソートキー`PreparationTime`をパーティションキー`Category`と組み合わせてテーブルをクエリできます（例:「Sandwich」と「20」）。 インデックスについて説明する前に、Catalyst NoSQLがすべてのテーブルに提供する特別な属性を理解しましょう。 ### Time To Live（TTL） Time To Live（TTL）は、特定の時点以降にCatalyst NoSQLテーブルのアイテムを自動的に削除する方法を提供します。テーブル作成時に、テーブル内で有効期限のタイムスタンプを保持する属性を設定できます。データ追加時に、テーブル内の各アイテムの有効期限タイムスタンプを**Unixエポック時間形式**で追加できます。Catalystは、有効期限を過ぎたテーブル内のアイテムを自動的に完全に削除し、手動更新の実行と書き込みスループットの消費を省けます。 TTL属性は、特定の時点以降に不要になるアイテムや、有効期間が短いアイテムの削除に便利です。有効期限を過ぎた後にCatalystが自動的に削除するアイテムは、テーブルおよびインデックスが作成されているすべての場所から削除されます。 Catalystは、TTL属性値が期限切れを示すアイテムを確認するために、24時間ごとに**組み込みスケジューラ**を実行します。このチェックは、すべてのプロジェクトのすべてのNoSQLテーブルで実行され、有効期限を過ぎたアイテムは完全に削除されます。 例を使ってTTLを理解しましょう。前のセクションで示した*Menu*テーブルに、TTLタイムスタンプを格納するための`Expiry`という名前の属性を作成すると仮定します。次に、テーブル内のすべてのアイテムの有効期限タイムスタンプを以下のように定義できます。 #### サンプルテーブルの表現 **テーブル名**: Menu ```json { "item": { "Category": { "S": "Pizza" }, "DishName": { "S": "Vegan" }, "Calories": { "N": 350 }, "PreparationTime": { "N": 20 }, "Cost": { "N:" 25 }, "DiscountPercentage": { "N": 5 }, "Expiry": { "N": 1715755926 } }, "item": { "Category": { "S": "Pizza" }, "DishName": { "S": "Chicken Overload" }, "Calories": { "N": 450 }, "PreparationTime": { "N": 30 }, "Expiry": { "N": 1715565610 } }, "item": { "Category": { "S": "Sandwich" }, "DishName": { "S": "Vegan" }, "Calories": { "N": 300 }, "PreparationTime": { "N": 20 }, "Cost": { "N": 25 }, "DiscountPercentage": { "N": 15 } "Expiry": { "N": 1715700869 } } } ``` > **注意:** ここに示されているテーブルは**CatalystカスタムJSON形式**の表現です。このJSON形式で各サーバーサイドSDKのデータを構築するフォーマットは異なります。このテーブルに示されているCatalystカスタムJSON形式の一般的な構文、サポートされるデータ型とその表記については、[このセクション](https://docs.catalyst.zoho.com/ja/cloud-scale/help/nosql/working-with-data/introduction/#the-catalyst-custom-json-format)を参照してください。 **注意事項:** * NoSQLテーブルのアイテムのTTL属性値は、必要に応じていつでも更新できます。Catalystの組み込みスケジューラが実行される際、最新のTTL値に基づいてアイテムを識別・処理します。 * 指定された値に基づいて、必要に応じてアイテムのTTL属性を削除することもできます。