2026阿里云国际版表格存储Tablestore实战教程：宽表/时序模型选型、CU吞吐计费与成本测算

Meta Description: 面向出海团队的阿里云国际版表格存储 Tablestore 实战教程：讲清 serverless NoSQL 多模数据库的定位、四种数据模型（宽表/时序/消息/AI记忆）如何选型、高性能型与容量型实例的边界、30 个地域的可用性、存储与读写 CU 吞吐的真实单价表、预留吞吐与按量吞吐的差异、搜索索引与公网流量的计费陷阱，附三个成本测算场景、控制台开通建表读写全流程与十个高频 FAQ。价格可能变动，请以官方为准。

关键词：阿里云国际版、Tablestore教程、表格存储、serverless数据库、NoSQL、宽表模型、时序模型、CU吞吐、预留读写、搜索索引计费、成本测算、出海架构

一句话答案：阿里云国际版的表格存储 Tablestore 是一个「全托管、Serverless、按量计费」的 NoSQL 数据库——单张表可以装下 PB 级数据、扛住每秒千万级查询，而你不需要选机器、不需要分库分表、不需要运维任何集群；一个产品里内置了宽表（类 HBase/Bigtable）、时序、消息（Timeline）、AI 记忆四套数据模型，外带搜索索引、向量检索与 SQL 查询，是出海团队做元数据存储、IoT 设备数据、IM/Feed 流以及 AI 记忆层最省事的入口。 但它有两条必须先记住的硬限制：实例类型（高性能型 vs 容量型）创建后不可变更，且容量型实例不支持预留读写吞吐、只能走按量——选错只能把实例删了重建。

对做海外业务的团队来说，「选一个数据库」这件事从来不只是技术题。用传统关系型数据库存海量元数据，会遇到单表容量、分库分表、扩容停机的三连击；用对象存储 OSS 存，又拿不到低延迟的单行读写和二级索引；自己拿 HBase / Cassandra 搭一套，运维成本立刻把两个人头吃进去。表格存储 Tablestore 瞄准的，正是「海量、半结构化、要低延迟随机读写、又不想运维」这一片夹缝——它把分布式 KV 的弹性、搜索引擎的检索能力和 Serverless 的零运维揉进了同一个产品。

本文基于阿里云国际版（alibabacloud.com）官方定价页与帮助文档的实测数据写成，面向已经或准备用国际版部署业务的中文开发者与架构师。文中所有单价均来自官方页面，价格可能变动，请以官方为准。注册与购买前，请确认当地法规合规性。

一、先搞清边界：Tablestore 在数据库版图里补的是哪块拼图

阿里云国际版的数据库家族已经很拥挤：关系型的 RDS、云原生关系型的 PolarDB、多模的 Lindorm、实时数仓 Hologres、分析型数仓 AnalyticDB、离线大数据 MaxCompute、缓存 Tair/Redis……唯独「纯 Serverless 的 NoSQL 宽表/元数据库」这一格一直空着，Tablestore 就是补这一格的产品。它和站内其它几款数据库的定位并不重叠：

一句话选型口诀：要「事务和 SQL 关系模型」选 RDS/PolarDB；要「多引擎一站式」选 Lindorm；要「分析报表」选 Hologres/AnalyticDB；要「离线算」选 MaxCompute；要「存文件」选 OSS；而当你面对的是「海量半结构化数据 + 低延迟随机读写 + 不想运维」时，才是 Tablestore 的主场。

📝 小提示：Tablestore 是「表格存储」的中文名，英文站产品 slug 是 table-store（注意是带连字符的 table-store，不是 tablestore），控制台入口是 ots.console.alibabacloud.com，文档前缀是 /help/en/tablestore/。搜索或访问时认准这几个，别被相似的路径带偏。

二、四种数据模型怎么选：宽表、时序、消息、AI 记忆

Tablestore 最容易被误会的地方，是很多人以为它「就是一个 KV 表」。实际上一个实例里可以承载四类数据模型，官方文档把它归纳为 Wide Column（宽表）、TimeSeries（时序）、Timeline（消息/IM）、AI（Agent Memory，AI 记忆）。选错模型不影响能不能用，但会直接影响你要不要自己造轮子。

选择逻辑其实很朴素：结构化的「实体 + 属性」选宽表；带时间戳的「指标 + 标签」选时序；「谁在什么时候发了什么」的消息流选 Timeline；给大模型做「外挂记忆」选 AI 模型。 需要强调的是，官方文档同时把 TimeSeries 归入 IoTstore 物联网方案，把 AI 模型归入 MCP 智能 Agent 架构——也就是说，Tablestore 不只是"能存"，而是围绕这两条链路给了现成的上层方案。

宽表模型的能力清单值得单独看一眼，因为它决定了你「要不要自己再搭一套搜索/计数/事务」：它支持 auto-increment 自增主键列、条件更新（Conditional Update）、本地事务（Local Transaction）、原子计数器（Atomic Counter）、数据多版本与 TTL 生命周期。这意味着像「点赞数 +1」「库存扣减」「幂等写入」这类在纯 KV 上通常要借助外部组件或 Lua 脚本的活，在 Tablestore 里可以直接用原生能力解决。

📝 小提示：四种模型并非"混在一张表里"——宽表用「数据表」、时序用「时序表」、消息用 Timeline、AI 用 Agent Memory，实例创建时就决定了它承载哪类模型（时序模型要选「Create Instance for TimeSeries Model」）。选型前先想清楚主数据形态，能省掉后期迁移。

三、实例类型与地域：高性能型 vs 容量型，30 个地域怎么落子

3.1 两种实例类型：这是一次性选择，选错只能重建

Tablestore 只有两种实例类型，官方明确「实例类型创建后不可更改」，所以这是全文最需要先想清楚的一个决策点：

一句话结论：容量型在存储和读写吞吐上的单价都明显更低（存储约为高性能型的 40%、按量读写约为 1/5），代价是读性能和并发较低、且不支持预留吞吐。 所以判定标准很简单——只要业务对「读延迟」敏感（在线接口、用户直接等待的查询），就必须选高性能型；只有日终批处理、报表预处理、冷数据归档这类"慢一点无所谓"的负载，才适合容量型。

补充一句官方给出的一个反直觉细节：无论你是哪种实例类型，只要用了「搜索索引」，其存储都会按高性能型单价计费；同样，时序模型里的「时序元数据」也按高性能型存储单价计费，而「时序数据」才按容量型单价计费。也就是说，实例类型并不是"一刀切"的计费开关，用到了特定能力就会被拉高到高性能单价（详见第五节）。

3.2 地域：30 个地域可用，但两类实例的覆盖范围不同

Tablestore 官方列出的可用地域相当广（含中国内地、亚太、欧美、中东共 30 个地域）。就近部署能显著降低延迟，跨地域建实例则可用于容灾。需要注意的是，高性能型和容量型支持的地域并不完全一致：

对出海团队最常用的新加坡（ap-southeast-1）来说，两类实例都可用，是部署东南亚业务的首选落点。如果你的业务同时要覆盖东南亚和欧美，就近选新加坡 + 弗吉尼亚两地建实例做跨地域容灾是常见做法。 网络接入支持四种 Endpoint：Public（公网）、Public (Dual-stack)（公网双栈）、VPC（专有网络）、Classic Network（经典网络）——其中只有公网下行会产生流量费，走 VPC 内网访问是免费的，这一点在成本优化里非常关键。

资源配额方面，官方明码标价：每个阿里云账号最多创建 10 个实例，每个实例最多包含 64 张表（含数据表、二级索引表、时序表）；单张表可设置的预留读吞吐与预留写吞吐各自上限为 100,000 CU。需要更高配额或更大预留，需提交工单或联系技术支持。

📝 小提示：实例类型和地域都是"落子无悔"的决策，建议先用功能验证 + 小规格实例跑通读写与 SDK 接入，确认延迟和吞吐满足预期后再正式迁移数据，避免选错后重建导数据的返工成本。

四、计费拆解①：CU 到底怎么算，单价表一次看全

Tablestore 的账单由四个维度构成：数据存储费、数据传输出网流量费、按量（溢出）读写吞吐费、预留读写吞吐费。其中最容易糊的，是「CU」这个单位。

4.1 CU 的定义与取整规则

读写吞吐以「容量单位（Capacity Unit，CU）」计量，CU 是数据读写操作的最小计费单位。 官方规则很明确：

• 1 个读 CU = 从数据表读取一行不超过 4 KB 的数据。
• 1 个写 CU = 向数据表写入一行不超过 4 KB 的数据。
• 不足 4 KB 或非 4 KB 整数倍的数据，向上取整到最近的 4 KB。

官方给了两个取整的例子：写入 7.6 KB 数据消耗 2 个写 CU（7.6 KB 向上取整到 8 KB = 2 × 4 KB）；读取 0.1 KB 数据消耗 1 个读 CU（不足 4 KB 按 1 个算）。这意味着"行不大"不等于"不烧 CU"——哪怕读一行只有几十字节，也是 1 个读 CU。所以设计表结构时，把大字段拆表、控制单行体积，直接决定吞吐账单。

还有一个必须知道的保护机制：单个分区键每秒消耗超过 10,000 CU 时，Tablestore 会返回 OTSCapacityUnitExhausted 错误，此时应按指数退避（exponential backoff）降低请求速率。这也是分区键设计要避免"热点集中"的原因——把高并发的写入分散到多个分区键上。

4.2 存储与吞吐单价表（官方参考价，USD）

以下单价来自阿里云国际版 Tablestore 定价页，按地域分列。为方便阅读，先给出最常用的几个地域：

数据存储（USD/GB/小时）

换算成月（按 730 小时）：新加坡容量型约 $0.0876/GB/月（≈ ¥0.63），高性能型约 $0.219/GB/月（≈ ¥1.58）。也就是说，1 TB 数据放在容量型实例里，存储费约 $89.8/月；放高性能型则约 $219/月。

按量（溢出）读写吞吐（USD/10k CU）

预留读写吞吐（USD/10k CU/小时，仅高性能型支持）

数据传输出网流量（USD/GB）：新加坡 $0.081/GB、中国内地 $0.123/GB，其余地域差异较大（从约 $0.07 到 $0.45 不等），务必以定价页为准。注意官方定义：只有「公网下行流量」收费，内网下行、公网上行都不收费；但跨地域访问也计为公网访问。还有一个隐蔽点——即使操作失败，Tablestore 返回的失败信息仍会产生下行流量，照样计费。

⚠️ 计费口径提示：官方文档在不同页面使用「CU」时口径并不完全一致——按量读写吞吐按「每 10k CU」计价，而搜索索引的帮助文档在预留读示例中按「每 CU 每小时」计价。本文表格一律采用定价页标注的口径（每 10k CU），实际结算请以控制台账单为准。

五、计费拆解②：预留 vs 按量、搜索索引陷阱与省钱动作

5.1 预留吞吐比按量便宜，但"设了就一直扣"

官方的计费逻辑是：预留读写吞吐是数据表的一个属性，你可以为表设置一个预留值；每秒访问量不超过预留值的部分按「预留价」计费，超出部分按「按量（溢出）价」计费。 预留价明显低于按量价（以新加坡高性能型为例：预留读 $0.0002 vs 按量读 $0.0030，相差 15 倍；预留写 $0.0003 vs 按量写 $0.0060，相差 20 倍）。

听起来很美，但有三个坑必须记住：

1. 预留吞吐 > 0 时，即使没有任何读写请求也照常计费。 官方原文：若预留读/写吞吐大于 0，Tablestore 会为数据表分配并保留相应资源，闲置期间仍然收费。
2. 只有高性能型实例支持预留吞吐，容量型实例的数据表不支持预留，只能按量。
3. 调整预留值 1 分钟内生效；把预留读和预留写同时设为 0 即可停止预留费用，且不会释放实例或数据表。

由此得到第一条实操省钱动作：大促、批量导入、数据迁移这类"流量脉冲"场景，临时拉高预留写吞吐以压低写入成本；脉冲结束立刻把预留降回 0，避免闲置空扣。

5.2 搜索索引：无论实例类型，存储都按高性能单价计费

这是 Tablestore 最容易被低估的一项成本。官方明确：搜索索引的数据独立存储，且存放在高性能存储介质上——即使你的实例是容量型，搜索索引的存储依然按高性能型存储单价计费。 更关键的是，使用搜索索引还会产生「预留读吞吐」费用（覆盖索引构建时读源表、建索引与分词消耗、以及为查询性能常驻内存的部分），这个预留读吞吐由系统根据索引大小与行数自动设置、不可手动调整。

自动设置的规则是：预留读吞吐取「每 1 GB 索引 10 CU」与「每 200 万行 10 CU」两者的较大值；当索引小于 200 MB 且行数小于 40 万时按 20 CU 计，否则最低 100 CU 起。官方给的一个示例是：8 GB、900 万行的搜索索引，存储费为 8 × $0.00030/GB/小时 = $0.0024/小时。

第二条省钱动作因此是：上搜索索引前，先估算「压缩后的索引体积」而不是「源表原始数据量」 ——官方特别提醒不同索引类型消耗资源差异很大，存储不按源表原始数据大小计费。索引越大，不仅有存储费，还垫高了不可调的预留读吞吐费。

5.3 公网流量：能走内网就走内网

第三条省钱动作最简单也最常被忽略：Tablestore 只有公网下行收费，内网完全免费。 只要你的计算资源（ECS、ACK、函数计算）与 Tablestore 实例在同一个地域、通过 VPC 内网 Endpoint 访问，下行流量费就是 0。反之，跨地域访问会被当作公网访问计费，且失败请求返回的信息也照样产生流量——这意味着一个写得不好的重试循环，会同时放大请求数和流量费。

📝 小提示：把三条动作串起来就是一句话——「在线表"设预留、用完降零"；"搜索索引前先算索引体积"；"能用 VPC 内网就别走公网"」。 大多数 Tablestore 账单超支，都是这三条里漏了某一条。

5.4 时序模型的一个计费细节

官方特别说明：使用时序模型时，「时序数据」的按量读写按容量型单价计费，「时序元数据」的按量读写按高性能型单价计费，且时序元数据的存储也按高性能型存储单价计费。 也就是说，时序场景里"元数据"这一小块是按贵的单价走的，做成本预估时别只按容量型单价一刀切。

六、成本测算：三个真实场景算给你看

下面三个场景都按新加坡地域、每月 730 小时估算，单价取自上文表格。所有数字均为官方参考价的量级估算，实际费用以控制台账单为准。

场景一：容量型，500 GB 元数据/冷数据 + 按量读写

适合"读写不频繁、可以忍受中等延迟"的场景，例如日志元数据、归档目录、低频访问的商品库。

场景二：高性能型，200 GB 在线数据 + 预留吞吐

适合"用户直接等待结果"的在线元数据、会话存储、在线商品目录。这里把预留读/写各设 100,000 CU，超出部分按量。

把两个场景放在一起看，会得到一个反直觉但有价值的结论：在这类"数据量中等、吞吐不算极端"的负载里，存储费才是账单主体（占比约 76%），吞吐费反而是小头。 这和大家对"KV 数据库按读写计费很贵"的直觉相反——Tablestore 的预留吞吐单价极低，只要预留设置合理，吞吐很难成为主要成本。真正让账单失控的，通常是"预留设了却忘记降回 0"的空扣，以及"搜索索引把存储拉到高性能单价"的放大效应，而不是正常读写本身。

场景三：加一层搜索索引，存储会被"翻倍"

假设你在场景二的 200 GB 表上，为一个只含部分字段的搜索索引建索引，压缩后索引体积 40 GB、2,400 万行：

看得出来，搜索索引只加了几十 GB 的索引存储，就直接按"高性能存储"这一较高单价计费。所以在容量型实例上叠搜索索引，会出现"实例是便宜的容量型、索引却按高性能单价收"的错配。处置建议：如果搜索查询是核心在线能力，干脆一步到位选高性能型；如果搜索只是偶发分析，评估能否用 SQL 查询 + 二级索引替代。

七、控制台实操：开通、创建实例、建表与读写数据

Tablestore 的实操路径非常短，因为它是全托管的——没有"选机器、装系统、配副本"这些步骤，核心只有三步：开通服务 → 创建实例 → 建表并读写。

7.1 开通服务与创建实例

第 1 步，开通 Tablestore 服务：登录阿里云国际版控制台，在产品列表中找到 Tablestore，进入后按提示开通服务（新账号可先走免费试用入口）。

第 2 步，创建实例：登录 Tablestore 控制台（ots.console.alibabacloud.com），在顶部导航栏选择资源组（resource group）和地域（region），在 Overview 页点击 Create Instance。在创建对话框中：

• 选择实例类型：High-performance（在线低延迟）或 Capacity（离线低成本）——记住，此处一旦选定不可更改；
• 输入实例名称与实例描述；
• （如需）开启 ZRS 同城冗余以获得机房级容灾能力；
• 点击 OK 完成创建。

第 3 步，确认配额：每个账号最多 10 个实例、每实例最多 64 张表；单表预留读/写吞吐各上限 100,000 CU，超出需提工单。

7.2 宽表模型：建表并读写一行数据

第 1 步，创建数据表：进入 Instance Details 标签页，点击 Create Table。在 Create Table 对话框中：

• Table Name 设为 order；
• 主键列名设为 order_id，类型选 String，并勾选为 Partition Key（分区键）；
• 其余保持默认，点击 Create。

创建成功后，数据表会出现在 Tables 区域（若未刷新，点刷新图标即可）。

第 2 步，写入一行数据：在 Tables 区域找到该表，点击 Actions 列的 Query，进入 Query Data 页，点击 Insert。填入主键值与属性列，例如：

// 主键
order_id : 3a0ab074-ea98-11ef-821b-00163e184c56   (String)
// 属性列
user_id      : 1000000096      (String)
sku_id       : 9000000002      (String)
price        : 400.00          (Double)
num          : 43              (Integer)
total_price  : 17200.00        (Double)
order_status : closed          (String)
create_time  : 2025-01-09 13:40 (String)

第 3 步，更新一行数据：在 Query Data 页选中目标行，点击 Update。在对话框中既可以新增属性列（例如加入 comments，类型 String），也可以更新已有列（例如把 order_status 从 closed 改为 refunded），然后点击 OK。

第 4 步，读取数据：点击 Search，在 Mode 中选择 Range Search（主键范围读）或单行读取。控制台右上角还可直接执行 SQL 语句查询分析（见第八节）。

📝 小提示：控制台建表时把 order_id 设为 Partition Key，是为了让数据按该列散列到不同分区；生产环境一定要选高基数、写入分散的列做分区键，否则单分区超 10,000 CU/s 会触发 OTSCapacityUnitExhausted。

7.3 时序模型：建表、写入并查询时序数据

时序模型需要单独创建时序实例：在 Overview 页点击 Create Instance for TimeSeries Model，选择实例规格、填写名称与描述后点击 OK。

第 1 步，创建时序表：进入 Instance Details → Time Series Tables 标签页 → Create Time Series Table（也可点 Generate Demo with One Click 一键生成带样例数据的示例表）。时序表名设为 car_example，其余保持默认，点击 Create。

第 2 步，写入时序数据：时序数据 = 元数据 + 数据点，不预先创建元数据时，系统会自动从写入的数据里提取。点击时序表名进入 Query Data 页：

• （可选）点击 Add Time Series 添加元数据，例如 Metric Name 设为 car_tsdata，在 Tag 中加一条 car_model = model_A；
• 点击 Insert Data，系统会自动带出所选时序的元数据；填入时间与属性列，例如 时间 February 5, 2025, 00:00:00，属性列 vin_id(string)、model(string, model_A)、speed(double, 75.90)、gps(string, 30.23,52.78)、current_mileage(double, 10)、remaining_oil(double, 20)、available_mileage(double, 198)、tire_pressure(double, 2.4)，点击 OK。

第 3 步，查询时序数据：在 Query Data 页找到目标时序，点击 Query Data，设置时间范围与条件即可查询；也可用 SQL 查询时序数据（见下节）。

八、SQL 查询、搜索索引与生态集成

8.1 SQL 查询：用熟悉的 SQL 分析宽表/时序数据

Tablestore 提供了统一的 SQL 查询能力，让你不必写 SDK 就能对宽表模型和时序模型的数据做复杂查询与分析。官方把 SQL 能力拆成四块：

• Data mapping（数据类型映射）：使用 SQL 前必须确认字段在 SQL 中的类型与数据表一致；
• DDL：为表建映射表、为搜索索引建映射表、更新属性列、删除映射表、查询表信息；
• DQL：数据查询、聚合、全文检索、搜索索引的 ARRAY 字段、嵌套查询、虚拟列、Join 操作；
• Database Administration：查询表的索引信息、列出表名等。

SQL 性能的关键在查询优化：Tablestore 支持索引选择策略与计算下推（computing pushdown）——建立搜索索引后，系统会尽量把 SQL 计算任务下推到搜索索引，避免全表扫描。也就是说，SQL 查询要快，前提是先把搜索索引建对。

8.2 搜索索引：非主键列查询、聚合与全文检索

搜索索引基于倒排索引 + 列存，用于大数据场景下的多维查询与统计分析。它解决的是宽表模型的一个天然短板——宽表只能按主键高效查询，按非主键列过滤就得扫全表。建了搜索索引后，你可以：

• 按非主键列查询、多列组合查询、布尔查询、模糊查询（Fuzzy Query）；
• 做全文检索（对文本列分词）；
• 做聚合分析（最大值/最小值、行数统计、分组）；
• 做地理距离查询（Geo-distance Query）。

⚠️ 再次提醒：搜索索引的存储按高性能型单价计费（即使实例是容量型），且会自动产生不可手动调整的预留读吞吐费。上线前务必通过控制台的 Monitoring and alerts 查看索引的存储大小与行数，估算成本。

8.3 生态集成：计算引擎与数据流转

Tablestore 与阿里云大数据生态的打通相当完整，官方列出了明确的对接路线：

数据流转方面，既有入向：用 Tablestore Sink Connector 把 Kafka 数据批量导入数据表或时序表；也有出向：通过 DataWorks 把全量/增量数据同步到 MaxCompute 或 OSS，或用 Tunnel Service 消费全量与增量数据，还能用 CLI / DataX 直接下载到本地文件。此外，数据投递（Data Delivery） 能把全量或增量数据实时投递到 OSS，适合构建数据湖——让 Tablestore 存热数据、OSS 存历史冷数据，兼顾低延迟与低成本。

数据可视化则可对接 DataV（宽表/二级索引）与 Grafana（数据表/时序表）。

九、安全、备份与容灾

Tablestore 的安全能力分两层。访问控制层：推荐用 RAM 用户或 RAM 角色而非主账号访问；用 STS 临时凭证做有时限的授权（凭证泄露影响可控）；用 RAM Policy 精细授权；用资源目录的 Control Policy 做权限边界；再加 Network ACL（网络 ACL） 与 Instance Policy（实例策略） 限制访问来源。

数据安全层：服务端加密（建表时可开启表加密，落盘加密）；传输加密（支持 TLS，官方建议 TLS 1.2 及以上）。合规方面，Tablestore 集成日志服务 SLS 提供审计日志，可记录建表、建时序表、建索引等实例变更操作，满足安全审计、合规审计与故障排查场景。

备份与容灾三件套：备份（Backup and Restoration） 防误删与恶意篡改；ZRS（同城冗余存储） 在机房级故障（网络中断、断电、灾难事件）下仍保证强一致与高可用；跨地域建实例 用于跨地域容灾。这三者是不同层级的保护——备份防"手滑"，ZRS 防"机房挂"，跨地域防"整个地域挂"，按业务容灾等级（RTO/RPO）选配。

十、常见问题 FAQ

• Q：Tablestore 和 Lindorm、RDS 到底怎么选？

A：看数据形态与负载。要事务和关系模型选 RDS/PolarDB；要多引擎一体化（宽表+时序+搜索+文件）选 Lindorm；而"海量半结构化 + 低延迟随机读写 + 完全不想运维"这三点同时成立时，选 Tablestore。

• Q：实例类型选错了能改吗？

A：不能。 官方明确实例类型创建后不可更改。选错的唯一出路是新建实例再把数据迁过去，所以务必先想清楚负载是"在线低延迟"（高性能型）还是"离线低成本"（容量型）。

• Q：容量型实例能设置预留读写吞吐省钱吗？

A：不能。 容量型实例的数据表不支持预留读写吞吐，只能按量计费。但容量型的按量单价本身更低（读约为高性能型的 1/5、写约为 1/5）。

• Q：预留吞吐设了之后，没有访问也会扣费吗？

A：会。 预留读/写吞吐大于 0 时，Tablestore 会持续保留资源并计费，即使闲置无请求。做完批量导入或大促后，记得把预留读、预留写同时设为 0 来停止该项费用（不会释放实例和数据表）。

• Q：读一行很小的数据，是不是只算很小的 CU？

A：不是。1 个读 CU = 读一行不超过 4 KB，不足 4 KB 也按 1 个读 CU 算（读 0.1 KB 消耗 1 CU）；写入则向上取整到 4 KB（写 7.6 KB 消耗 2 个写 CU）。所以"小行"不等于"小 CU"。

• Q：为什么用了搜索索引，存储费按高通（高性能型）单价算？

A：官方规定搜索索引的数据独立存储、且位于高性能存储介质上，因此无论实例是容量型还是高性能型，搜索索引存储都按高性能型单价计费，并额外产生不可手动调整的预留读吞吐费。

• Q：访问 Tablestore 走公网要收费，怎么省这笔钱？

A：只有公网下行收费，内网免费。 让计算资源（ECS/ACK/FC）与 Tablestore 实例在同地域、通过 VPC 内网 Endpoint 访问即可免费；同时注意跨地域访问会被当作公网访问、失败请求返回的信息也会产生流量。

• Q：一个账号能建多少实例和表？

A：官方配额为每账号最多 10 个实例、每实例最多 64 张表（含数据表、二级索引表、时序表）；单表预留读/写吞吐各上限 100,000 CU。需要更高配额请提交工单。

• Q：单分区键写入太快报 OTSCapacityUnitExhausted 怎么办？

A：这是单分区键每秒超过 10,000 CU 触发的保护性报错。解法一是按指数退避降低请求速率，解法二是从根上优化分区键设计，把高并发写入分散到多个高基数分区键上，避免热点。

• Q：时序模型的计费有什么特别之处？

A：时序数据的按量读写按容量型单价计费，但时序元数据的按量读写按高性能型单价计费，且时序元数据存储也按高性能型存储单价计费。做成本预估时别把整块都按容量型单价算。

十一、总结

把全文收成一张决策卡：

1. 定位：Tablestore 是阿里云国际版的 Serverless NoSQL 多模数据库，补的是"海量半结构化数据 + 低延迟随机读写 + 零运维"这一格；与 RDS/PolarDB（关系型）、Lindorm（多引擎）、Hologres/AnalyticDB（分析型）、MaxCompute（离线）、OSS（文件）互不重叠。
2. 模型选型：实体属性用宽表、指标标签用时序、消息流用 Timeline、大模型记忆用 AI 模型。
3. 实例选型：在线低延迟选高性能型、离线低成本选容量型——类型创建后不可变更，是全文最不可逆的一个决策；容量型不支持预留吞吐。
4. 计费三支柱：存储（新加坡容量型 ≈$0.0876/GB/月、高性能型 ≈$0.219/GB/月）、读写 CU 吞吐（预留价远低于按量价）、公网下行流量（内网免费）。
5. 三条省钱动作：预留吞吐"用时调高、用完降零"；上搜索索引前先算索引体积（它按高性能单价计费）；能走 VPC 内网就别走公网。
6. 三个最易踩的坑：预留吞吐闲置照扣；搜索索引把容量型实例的存储拉高到高性能单价；公网访问（含失败请求）产生流量费。

最后强调两个"落子无悔"：实例类型和地域都是创建后不可逆的选择，建议先用小规格实例跑通延迟与吞吐再正式迁移。本文全部单价为官方参考价，价格可能变动，请以官方为准；注册与部署前，请确认当地法规合规性。

延伸阅读（本站相关文章）：

• 阿里云国际版数据库 RDS 选购 + 实战教程
• 阿里云国际版 Lindorm 多模数据库实战教程
• 阿里云国际版 Hologres 实时数仓实战教程
• 阿里云国际版大数据计算服务 MaxCompute 实战教程
• 阿里云国际版向量检索服务 DashVector 实战教程
• 阿里云国际版对象存储 OSS 实战教程
• 阿里云国际版注册教程：免实名、支付宝与国内信用卡支付

⚠️ 免责声明：本文中提到的配置、价格和优惠信息可能随时间变化，请以阿里云国际版官网（alibabacloud.com）的实时信息为准。本文不构成任何投资或购买建议。注册前请确认当地法规合规性。

本文由 2.chengzicloud.cloud 提供，点击访问首页了解更多