すべてのプロダクト
Search
ドキュメントセンター

Tablestore:基本概念

最終更新日:Sep 22, 2026

リージョン、インスタンス、エンドポイント、読み取り/書き込みスループットなど、Tablestore のコア コンセプトを理解します。

リージョン

Tablestore は、世界中の複数のリージョンで利用できます。レイテンシーを削減するため、ワークロードに最も近いリージョンを選択してください。クロスリージョンディザスタリカバリを行う場合は、複数のリージョンにインスタンスを作成します。SDK を設定する場合、API オペレーションを呼び出す場合、または Tablestore コンソールを使用する場合は、リージョン ID を指定する必要があります。次の表に、サポートされているすべてのリージョンとリージョン ID を示します。

パブリッククラウド

エリア

リージョン

リージョン ID

中国

中国 (杭州)

cn-hangzhou

中国 (上海)

cn-shanghai

中国 (青島)

cn-qingdao

中国 (北京)

cn-beijing

中国 (張家口)

cn-zhangjiakou

中国 (フフホト)

cn-huhehaote

中国 (ウランチャブ)

cn-wulanchabu

中国 (深圳)

cn-shenzhen

中国 (河源)

cn-heyuan

中国 (広州)

cn-guangzhou

中国 (成都)

cn-chengdu

中国 (中衛)

cn-zhongwei

中国 (香港)

cn-hongkong

アジアパシフィック

日本 (東京)

ap-northeast-1

韓国 (ソウル)

ap-northeast-2

シンガポール

ap-southeast-1

マレーシア (クアラルンプール)

ap-southeast-3

インドネシア (ジャカルタ)

ap-southeast-5

フィリピン (マニラ)

ap-southeast-6

タイ (バンコク)

ap-southeast-7

マレーシア (ジョホール)

ap-southeast-8

ヨーロッパおよびアメリカ

ドイツ (フランクフルト)

eu-central-1

イギリス (ロンドン)

eu-west-1

フランス (パリ)

eu-west-2

オランダ (アムステルダム)

eu-west-3

米国 (シリコンバレー)

us-west-1

米国 (バージニア)

us-east-1

ブラジル (サンパウロ)

sa-east-1

メキシコ

na-south-1

中東

UAE (ドバイ)

me-east-1

サウジアラビア (リヤド)

me-central-1

インスタンス

インスタンスは、Tablestore を使用および管理するための基本単位です。各インスタンスはデータベースとして機能します。Tablestore は、インスタンスレベルでアクセスコントロールとリソースメータリングを実行します。Tablestore をアクティブ化した後、Tablestore コンソールでインスタンスを作成します。その後、そのインスタンス内でテーブルを作成し、データを管理できます。

説明

各 Alibaba Cloud アカウントは最大 10 個のインスタンスを作成でき、各インスタンスには最大 64 個のテーブル (データテーブル、セカンダリインデックス テーブル、時系列テーブルを含む) を保持できます。これらのクォータを増やすには、チケットを送信するか、Tablestore テクニカルサポートグループ 36165029092 にご参加ください。

インスタンスタイプ

Tablestore は、高性能と容量の 2 つのインスタンスタイプをサポートしています。各インスタンスタイプは、テーブルあたりペタバイト規模のデータを処理できます。ユースケースと予算に最適なタイプを選択してください。詳細については、次の表をご参照ください。

重要
  • インスタンスタイプは作成後に変更できません。慎重に選択してください。

  • インスタンスタイプに関係なく、検索インデックスを使用すると、高性能ストレージ、予約済み読み取りスループット、オンデマンド読み取りスループットに対して料金が発生します。詳細については、「検索インデックスの課金」をご参照ください。

  • インスタンスタイプに関係なく、時系列モデルを使用する場合、時系列データのオンデマンド読み取り/書き込みスループットは容量レートで課金され、時系列メタデータのオンデマンド読み取り/書き込みスループットは高性能レートで課金され、時系列メタデータストレージは高性能ストレージレートで課金されます。詳細については、「TimeSeries モデルの課金項目」をご参照ください。

インスタンスタイプ

高性能

容量

ユースケース

高い同時実行性と超低読み取り/書き込みレイテンシーを必要とするオンラインワークロード。

低コストのストレージを必要とするオフラインワークロード。レイテンシーに敏感なオンラインワークロードには適していません。

課金コンポーネント

  • 予約済みおよびオンデマンド書き込みスループット

  • 予約済みおよびオンデマンド読み取りスループット

  • 高性能ストレージ

  • アウトバウンドインターネットトラフィック

  • オンデマンド書き込みスループット

  • オンデマンド読み取りスループット

  • 容量ストレージ

  • アウトバウンドインターネットトラフィック

パフォーマンス

読み取り

高

中

書き込み

高

高

同時実行性

高

中

利用可能なリージョン

次の表に、各インスタンスタイプとストレージタイプをサポートするリージョンを示します。

インスタンスタイプ

エリア

対応リージョン

高性能

中国

中国 (杭州)、中国 (上海)、中国 (北京)、中国 (張家口)、中国 (ウランチャブ)、中国 (深圳)、中国 (河源)、中国 (広州)、中国 (成都)、中国 (中衛)、中国 (香港)

アジアパシフィック

韓国 (ソウル)、シンガポール、マレーシア (クアラルンプール)、インドネシア (ジャカルタ)、フィリピン (マニラ)、タイ (バンコク)、マレーシア (ジョホール)

ヨーロッパおよびアメリカ

ドイツ (フランクフルト)、イギリス (ロンドン)、フランス (パリ)、オランダ (アムステルダム)、米国 (シリコンバレー)、米国 (バージニア)、ブラジル (サンパウロ)、メキシコ

中東

サウジアラビア (リヤド)

容量

中国

中国 (杭州)、中国 (上海)、中国 (青島)、中国 (北京)、中国 (張家口)、中国 (フフホト)、中国 (深圳)、中国 (成都)、中国 (香港)

アジアパシフィック

日本 (東京)、マレーシア (クアラルンプール)、インドネシア (ジャカルタ)

ヨーロッパおよびアメリカ

ドイツ (フランクフルト)、イギリス (ロンドン)、米国 (バージニア)

中東

UAE (ドバイ)

Endpoints

Endpoint types

Each Tablestore instance has a unique endpoint. Four endpoint types are available: [Public], [Public (Dual-stack)], [VPC], and [クラシックネットワーク]. Select the endpoint type based on your network environment.

説明

Accessing Tablestore over the Internet incurs outbound traffic charges. For more information, see Billing overview.

Public

Use the [Public] endpoint to access Tablestore over the Internet. Endpoint format:

https://instanceName.RegionID.ots.aliyuncs.com

VPC

Use the [VPC] endpoint to access Tablestore from a virtual private cloud. Endpoint format:

https://instanceName.RegionID.vpc.tablestore.aliyuncs.com

Classic Network

Use the [クラシックネットワーク] endpoint to access Tablestore from an ECS instance in the same region over the classic network. This reduces latency and avoids Internet traffic charges. Endpoint format:

https://instanceName.RegionID.ots-internal.aliyuncs.com

Public (Dual-stack)

Use the [Public (Dual-stack)] endpoint to access Tablestore over the Internet with IPv4 and IPv6 support. Endpoint format:

https://instanceName.RegionID.tablestore.aliyuncs.com
説明

[Public (Dual-stack)] endpoints are available only in the following regions: China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), and China (Hong Kong).

Get an endpoint

  1. Log on to Tablestore コンソール. You can switch the region and resource group at the top of the page.

  2. On the [概要], click the instance name or [インスタンスの管理]. Select the appropriate [インスタンスアクセス URL].

    Access scenario

    Endpoint to use

    Over the Internet

    Use the [Public], or the [Public (Dual-stack)] endpoint, depending on the IP protocol that your client supports.

    Internet access has higher latency. Use [VPC] network when possible.

    重要
    • If your client uses only IPv6, use the [Public (Dual-stack)] endpoint.

    • If your client does not support IPv6, use either the [Public] or the [Public (Dual-stack)] endpoint.

    From a VPC

    Use the [VPC] endpoint.

    From the classic network

    Use the [クラシックネットワーク] endpoint.

    説明

    For more information about VPCs and the classic network, see Network types.

Read/write throughput

Read and write throughput is measured in capacity units (CUs). A CU is the minimum billing unit for data read and write operations. Each API read or write operation on a data table consumes the corresponding read or write CUs.

CU calculation rules

  • One read CU represents reading one row of up to 4 KB from a data table.

  • One write CU represents writing one row of up to 4 KB to a data table.

  • Data that is smaller than 4 KB or not a multiple of 4 KB is rounded up to the nearest 4 KB. For example, writing 7.6 KB of data consumes 2 write CUs, and reading 0.1 KB of data consumes 1 read CU.

On-demand read/write throughput

On-demand read/write throughput is the actual throughput consumed per second that exceeds the reserved read/write throughput. The measurement interval is one second. Within each hour, Tablestore calculates the average reserved read/write throughput and the cumulative on-demand read/write throughput as the actual throughput consumed.

On-demand throughput is priced higher than reserved throughput because Tablestore must provision sufficient capacity for unpredictable traffic peaks. To reduce costs, set appropriate reserved read/write throughput.

重要

Because Tablestore cannot accurately estimate the resources to reserve for on-demand throughput, the service may return the OTSCapacityUnitExhausted error when a single partition key consumes more than 10,000 CU per second. Use exponential backoff to reduce the request rate to the data table.

Reserved read/write throughput

Reserved read/write throughput is a property of data tables in high-performance instances . You can specify the reserved read/write throughput when you create a data table.

説明

When you use search indexes, Tablestore automatically sets a reserved read throughput based on the index data size. For more information, see Search index billing. The reserved read throughput of search indexes cannot be adjusted. To reduce this cost, optimize the index size or the number of rows.

  • If the reserved read/write throughput is greater than 0, Tablestore allocates and reserves the corresponding resources for the data table. Access that does not exceed the reserved throughput per second is billed at the reserved throughput rate.

  • If the reserved read/write throughput is set to 0, Tablestore does not allocate or reserve resources for the data table.

    説明

    A non-existent data table is treated as having 0 reserved read/write throughput. Accessing a non-existent data table consumes 1 on-demand read CU or 1 on-demand write CU depending on the operation type.

The unit price of reserved throughput is lower than that of on-demand throughput. To reduce costs, set an appropriate reserved throughput level. For example, before importing a large amount of data, set a high reserved write throughput to lower the write cost. After the import is complete, reduce the reserved throughput.

Usage limits

  • Data tables in capacity instances do not support reserved read/write throughput.

  • Reserved read/write throughput greater than 0 incurs charges even without read or write requests. Tablestore limits reserved read throughput and reserved write throughput to a maximum of 100,000 each per data table. If a data table requires reserved read/write throughput greater than 100,000, submit a ticket or join the Tablestore technical support group 36165029092 to contact technical support.

Reserved read/write throughput update rules

You can update the reserved read/write throughput of a data table by calling an operation or using the console. Setting both the reserved read throughput and the reserved write throughput to 0 removes the reserved throughput configuration. This stops reserved throughput charges and does not release the instance or the data table.

  • Within each calendar day (from UTC 00:00:00 to 00:00:00 the next day, or from 08:00 to 08:00 the next day in UTC+8), you can adjust the reserved throughput an unlimited number of times. The interval between two consecutive updates to the same data table must be greater than 1 minute. This rule applies whether you update by calling an operation or by using the console.

  • The adjusted reserved read/write throughput takes effect within 1 minute.

Update by calling an operation

Call the UpdateTable operation to modify the reserved read/write throughput of a table.

Update by using the console

  1. Log on to the Tablestore console.

  2. On the instance list page, click the name of the target instance to go to the instance details page.

  3. Click the Tables tab, and then click the name of the target data table to go to the table details page.

  4. Check the current reserved read throughput and reserved write throughput values.

  5. Click Modify Table Attributes, and then set both the reserved read throughput and the reserved write throughput to 0.

  6. Click OK. The message "The table properties are modified." appears.

Calculation example

Assume that the reserved read throughput of a data table is set to 100 CU. The following access pattern occurs over 3 consecutive seconds:

  • T0: Read operations consume 120 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 20 CU.

  • T1: Read operations consume 95 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 0 CU.

  • T2: Read operations consume 110 CU of read throughput. The reserved throughput is 100 CU, and the on-demand read throughput consumed is 10 CU.

From T0 to T2, the total read throughput consumed is 100 CU of reserved read throughput and 30 CU of on-demand read throughput.