2026阿里云国际版Lindorm多模数据库实战教程：宽表/时序/搜索五引擎选型、lindorm-cli连接与计费成本测算

Meta Description: 阿里云国际版 Lindorm 多模数据库实战教程：一个实例同时运行宽表、时序、搜索、计算、流五类引擎的定位与边界、与 RDS/PolarDB/Hologres 的分工对照表、五种存储类型的延迟与计费口径对比、节点规格与数量计算法、控制台开通与白名单配置七步、lindorm-cli 安装与 MySQL/HBase/Avatica 三种协议连接命令、官方参考月价与扩容费公式、八条省钱动作与十问 FAQ。

> 关键词：阿里云国际版Lindorm、Lindorm教程、多模数据库、宽表引擎、LindormTSDB、LindormSearch、lindorm-cli、HBase兼容、Lindorm价格、NoSQL数据库

一、先给结论：Lindorm 是什么，以及本文不重复哪些内容

一句话答案：Lindorm 是阿里云的云原生多模数据库——同一个实例里可以同时启用五类引擎（宽表、时序、搜索、计算、流），底层共用一套 LindormDFS 存储，用统一的 SQL 就能跨模型查询、检索与分析。它要解决的是「一份业务数据散落在 HBase + InfluxDB + Elasticsearch + Kafka 好几套系统里，各自运维、各自扩容、还要维护好几套 SDK」这个经典困境。

它值得在 2026 年单独写一篇的理由有三个：第一，它是国际站少数几个「一个实例顶多套系统」的产品——宽表引擎兼容 HBase、Cassandra 与 SQL，时序引擎兼容 OpenTSDB，搜索引擎兼容 Apache Solr 与 Elasticsearch 的 API，迁移成本远比想象中低；第二，存储与计算解耦，存储按类型单独买、单独扩，容量层可以做到比标准存储便宜一个数量级，冷热分层是它最省钱的一张牌；第三，它的计费口径与国内站、与同门的 Hologres 都不一样——固定费用 + 存储费 + 节点规格费 + 节点内存费 + 增值服务费五项分开算，而且本地盘按物理容量（含副本）计费，这一条最容易让预算翻倍。

在开写之前，先把本文与站内既有数据库文章的分工说清楚，避免你把五篇文章读成一篇：

| 既有主题 | 它解决的问题 | 与本文的关系 | |--------|--------|--------| | RDS 数据库选购+实战 | MySQL/PostgreSQL 等事务型关系库 | 本文讲 NoSQL 多模，事务型选型不重复 | | PolarDB 云原生数据库 | 计算存储分离的云原生关系库 | 同族架构参照，只做对比不展开 | | Hologres 实时数仓 | 分析型 HSAP 数仓、CU 计费 | 本文讲在线宽表/时序/搜索，与它互补 | | 日志服务 SLS | 日志采集、查询与投递 | Lindorm 承接线上明细数据，SLS 管日志，分工不同 | | 对象存储 OSS 实战 | 冷数据、静态对象的低成本存放 | Lindorm 的容量存储层与 OSS 各有适用面，文末对比 |

本文只讲一件事：Lindorm 这一个产品怎么选引擎、怎么选存储、怎么开通连接、怎么算钱。 其它产品的细节一律只引用不展开。

二、五个引擎怎么选：一张表看完

Lindorm 的「多模」不是营销词，它是真的把五种负载放进了同一个实例、同一套存储里。每类引擎可以独立扩缩容，你可以只为一个工作负载配资源，不必为凑一整台机器而过度采购。

| 引擎 | 兼容的 API | 最适合的场景 | 关键能力 | |--------|--------|--------|--------| | 宽表引擎（LindormTable） | SQL、HBase API、Cassandra Query Language（CQL）、S3 API | 大规模半结构化/结构化数据：元数据、订单、账单、用户画像、社交流、Feed、日志、轨迹 | 千万级并发、单实例可存至百 PB；官方口径对比开源 HBase：读写吞吐 3–7 倍、P99 延迟约 1/10、压缩比 2 倍、存储成本低约 50%；支持全局二级索引、多维查询、动态列、TTL、冷热分离；内置 GanosBase 做时空/轨迹查询 | | 时序引擎（LindormTSDB） | HTTP API、OpenTSDB API | 设备遥测、IoT 传感器数据、运维指标等按时间顺序到达的数据 | 时序专用压缩（压缩比更高）、SQL 查询、多维度时间线查询、聚合、降采样、弹性扩缩 | | 搜索引擎（LindormSearch） | SQL、Apache Solr API、Elasticsearch API | 日志、文本、文档、账单、用户画像上的全文检索与复杂多维查询 | 存储计算解耦；自动索引宽表与时序引擎里的数据；支持全文检索、聚合、复杂多维查询、横向扩容、一写多读、跨可用区容灾、TTL | | 计算引擎（LDPS） | Apache Spark API | 大批量数据生产、交互式分析、图计算 | 云原生分布式计算，兼容 Spark 社区模型与 API；与存储引擎深度集成，直接利用底层数据特征与索引跑分布式作业 | | 流引擎 | SQL、Apache Kafka API | IoT 数据处理、应用日志处理、物流时效分析、实时轨迹处理 | 对流入数据边存边算；配合宽表引擎的 GanosBase 可做电子围栏、区域统计等实时轨迹分析 |

选型口诀很简单：要「在线点查 + 海量写入」选宽表；要「设备指标 + 降采样」选时序；要「全文检索 + 多维筛选」选搜索；要「批处理 + 图计算」选计算；要「边到边算 + 实时轨迹」选流。 复杂业务往往是宽表 + 搜索的组合（一份数据，宽表存明细、搜索做检索），而搜索引擎能自动索引宽表数据这一点，正是它比「自己拼 HBase + ES」省事的地方。

> 📝 小提示：如果你已经有一套 HBase 或 Cassandra 应用，别急着重写代码——宽表引擎兼容这两种 API，迁移通常只改连接串和少量配置，这也是 Lindorm 相比纯自研多模方案最现实的落地路径。

三、存储类型怎么选：五种存储、两种计费口径

Lindorm 底层是自研的 LindormDFS，存储资源与计算资源彻底解耦，存储单独计费、可以在不中断业务的情况下扩容，而且整个实例内所有引擎共享同一份存储容量——不会出现「宽表买的盘搜不到」的情况。这句话听着平淡，但它直接决定了成本结构：你只为一份数据付一次存储钱。

官方把存储分成五类，选择的关键有两条：延迟需求和计费口径。

| 存储类型 | 存储层延迟 | 典型场景 | 支持它的引擎 | |--------|--------|--------|--------| | 标准存储 | 3–5 ms | 流数据、聊天、实时报表、在线计算等需要实时访问的数据 | 宽表、时序、搜索、LindormDFS、流引擎 | | 性能存储 | 0.2–0.5 ms | 对延迟敏感：广告竞价、用户画像、人群圈选、实时搜索、风控 | 宽表、时序、搜索、LindormDFS、流引擎 | | 容量存储 | 15 ms–3 s | 不常访问的数据：监控日志、历史订单、音视频归档、数据湖存储、离线计算 | 宽表、LindormDFS、流引擎 | | 本地 SSD | 0.1–0.3 ms | IO 密集型在线业务：在线游戏、电商、直播、媒体，要求极低延迟与高吞吐 | 宽表、时序、搜索、文件引擎 | | 本地 HDD | 10–300 ms | 海量数据存储、离线计算、互联网与金融的大数据分析 | 宽表、时序、LindormFile |

第一条关键差异：逻辑容量 vs 物理容量。 标准存储、性能存储、容量存储按逻辑容量计费——你看到一个 100 GiB 的库文件，就只计 100 GiB，冗余由 LindormDFS 自己处理，不用乘副本数。而本地 SSD、本地 HDD 以及挂载的云盘按物理容量计费——本地盘数据默认 3 副本、云盘默认 2 副本，一个 100 GiB 的逻辑数据库在三副本下要占 300 GiB 的计费容量。这就是前文说的「最容易被忽略、却能让预算翻倍」的一条。

第二条：标准存储与性能存储都可以叠加容量存储做冷热分层。 这是 Lindorm 最省钱的用法——把热数据留在标准/性能存储上保证延迟，把冷数据放到容量存储上，不用迁移实例、不用改表结构，容量存储就是同一实例里的低成本层。

还有两个容易被误读的点：一是表中延迟只是存储层延迟，不是端到端延迟，实际响应还要叠加引擎与网络开销，别拿 0.1 ms 去承诺 SLA；二是本地盘实例至少要配 3 个节点——默认三副本下，只有 3 节点才能在单节点故障时保住三副本不降级。所以「本地 SSD 最便宜」这个直觉要打个问号，它的性价比是建立在「IO 密集 + 节点数够」的前提上的。

四、规格与节点数怎么算：官方给了两张表

Lindorm 的规格从 4 核 8 GB 到 32 核 256 GB，但注意一个前置条件：当商品类型选 Lindorm（而不是老的 Lindorm V1）时，宽表引擎与时序引擎的最低规格都是 4 核 16 GB。别照着 V1 的旧文章买 4 核 8 GB，你会发现在新版商品里根本选不出来。

官方对起步配置的建议相当明确：至少 3 个节点，每节点 8 核 32 GB 起步，16 核 64 GB 更好——因为部分性能优化需要内存大于 16 GB 的节点，部分写入优化需要至少 3 个节点。

宽表引擎按「每节点请求速率 × region 数」选规格：

| 每节点请求速率 | 每节点 region 数 | 推荐规格 | |--------|--------|--------| | < 1,000 请求/秒 | < 500 | 4 核 / 16 GB | | < 20,000 请求/秒 | < 1,000 | 8 核 / 32 GB 或更高 | | > 20,000 请求/秒 | > 1,000 | 16 核 / 64 GB 或更高 |

时序引擎按「写入吞吐（测量点/秒，以 3 节点集群为前提）」选规格：

| 写入吞吐（TPS） | 每节点推荐规格 | |--------|--------| | < 190 万点/秒 | 4 核 / 16 GB | | < 390 万点/秒 | 8 核 / 32 GB | | < 780 万点/秒 | 16 核 / 64 GB | | < 1,100 万点/秒 | 32 核 / 128 GB |

官方同时提醒：请求速率和 region 数不是唯一的选型依据，出现下面任意一种情况都要往上选一档——单行大小达到 KB 或 MB 级；SCAN 请求带复杂过滤；缓存命中率低（大部分请求走磁盘）；实例里表特别多；CPU 利用率长期在 70% 以上。在线业务优先加内存（提高缓存命中率），离线重负载（MapReduce、Spark）或极高 TPS/QPS 优先加 CPU 核数。

最后是「加节点」和「升规格」的分工，这一条官方写得很直白：加节点能解决高延迟、性能不稳定这类整体负载问题，但解决不了单节点热点——热点只能靠升配，因为规格决定了单节点的热点处理能力，规格不够时大流量下会出现负载过高甚至 OOM。所以看到「某一两个节点特别忙」时，扩节点是白花钱。

五、开通实操：控制台七步 + 白名单配置

Lindorm 的开通流程在控制台里，网址是 https://lindorm.console.alibabacloud.com/cn-hangzhou/clusterhou/cluster（登录后按右上角地域切换到你要购买的地域）。

第一步，选商品类型（Commodity Type）。 有三个选项：Lindorm（新版多模，本文推荐）、Lindorm V1（老版）、LindormTunnel channel service（通道服务）。本文的所有规格口径都基于 Lindorm。

第二步，选计费方式（Billing Method）。 Subscription（包年包月，预付费）或 Pay-as-you-go（按量付费，按小时计费）。官方对两者的定位是：包年包月时长越长折扣越大，适合稳定负载；按量适合短期使用，随时释放实例即可停止计费。两者创建后可以互转——按量转包年包月、包年包月转按量都有官方文档支持，不用担心选错就锁死。

第三步，选部署方式（Deployment Method）。 三种：

- 单可用区部署：主备节点在同一可用区，支持单可用区容灾； - 多可用区部署（HA）：主备在不同可用区，跨可用区容灾，但只支持宽表引擎； - 多可用区部署（基础版）：主备在不同可用区，支持所有引擎。

如果你的实例要用时序或搜索引擎，又想要可用区级容灾，必须选基础版——这是选「HA」很容易踩的一脚。

第四步，选地域与可用区。 这里有一个硬约束：地域创建后不可更改，务必想清楚再选。判断标准很简单——如果你的应用跑在 ECS 上，Lindorm 必须与 ECS 选同一地域，否则只能走公网，延迟和流量成本都会变差；能用同可用区更好，延迟最低。

第五步，配网络。 网络类型固定为 VPC（多可用区部署下不需要单独选），需要选择各可用区对应的 vSwitch。把 Lindorm 和 ECS 放在同一个 VPC，是内网访问的前提。

第六步，填集群名称、选存储类型、节点规格与数量、存储容量。 这里就是第三、四节的选型结论落地的地方，按你的延迟需求选存储类型（标准/性能/容量/本地 SSD/本地 HDD），按请求速率或写入吞吐定规格，按「至少 3 节点」定数量。

第七步，确认购买。 建议在结算页核对最终金额后再下单。

开通之后不要急着连接——Lindorm 默认拒绝所有外部访问，必须先配白名单：

1. 进入 Instances 页面，点实例 ID 或操作列的 View Instance Details； 2. 左侧导航点 Access Control，再点 Create Whitelist； 3. 填写 Whitelist Name（只支持英文字母、数字、下划线）与 Whitelist（IP 或 CIDR 段，多个用英文逗号分隔，前缀长度范围 1–32，例如 192.0.xx.xx/24）； 4. 点 OK 保存。

获取客户端 IP 的方法：如果客户端是 ECS 且与 Lindorm 在同一个 VPC，直接查 ECS 内网 IP；如果是本机通过公网连，Linux 下执行 curl ipinfo.io | grep ip 拿公网 IP，Windows 下可以 curl ifconfig.me。

> ⚠️ 安全警告：白名单里绝对不要填 0.0.0.0/0——那等于允许全世界访问你的实例，官方明确提示此时实例面临很高的安全风险。另外有个反直觉的设定：把 IP 填成 127.0.0.1 表示禁止所有 IP 访问，不是只允许本机。

> 📝 小提示：白名单建议定期复核。测试期临时加上的办公网 IP、客户公网 IP，上线后往往忘了删，这是最容易留下的隐患。

六、连接实操：lindorm-cli 安装与三种协议

宽表引擎（LindormTable）最常用的连接工具是官方的 lindorm-cli，它支持通过 MySQL 协议、HBase 协议和 Avatica 协议连接。

第一步，下载并解压。 官方提供多平台安装包，注意选对架构——服务器是 ARM（比如部分 ARM 实例）就要用 arm64 版本。Linux x86 下的命令是：

`bash // 下载最新版 lindorm-cli（文件名自带 latest，不要写死版本号） wget https://hbaseuepublic.oss-cn-beijing.aliyuncs.com/lindorm-cli-linux-latest.tar.gz

// 解压后会得到可直接执行的 lindorm-cli 文件，无需额外安装 tar zxvf lindorm-cli-linux-latest.tar.gz

// 查看版本，确认能跑起来 ./lindorm-cli -version `

官方下载页同时给出了每个安装包的 SHA256 校验值，生产环境建议先 sha256sum 核对再执行，lindorm-cli 是能直接连数据库的可执行文件，校验这一步值得做。其它平台对应 arm64 Linux、Mac（Intel / Arm）、Windows x64。

第二步，用 MySQL 协议连接（官方推荐）。 需要 lindorm-cli 2.0.0 及以上版本：

`bash // <mysql url> 填宽表引擎的 MySQL 兼容 Endpoint，默认端口 33060 ./lindorm-cli -url ld-xxxxxxxx-proxy-lindorm-vpc.lindorm.aliyuncs.com:33060 -username 你的用户名 -password 你的密码

// URL 也可以带 mysql:// 前缀，效果相同 ./lindorm-cli -url mysql://ld-xxxxxxxx-proxy-lindorm-vpc.lindorm.aliyuncs.com:33060 -username 你的用户名 -password 你的密码 `

第三步，用 Avatica 协议连接。 URL 形态不同，走的是 HTTP 通道、端口 30060：

`bash ./lindorm-cli -url "jdbc:lindorm:table:url=http://ld-xxxxxxxx-proxy-lindorm-pub.lindorm.rds.aliyuncs.com:30060" -username 你的用户名 -password 你的密码 `

关于 Endpoint 里的两个关键词，这是最容易连不上的地方： URL 中带 -vpc 的是内网地址，只能从同一个 VPC 内的 ECS 访问；带 -pub 的是公网地址，从本机或办公网访问要用它，并且要在白名单里加上你的公网 IP。用内网地址从公网连、或用公网地址却没配白名单，都是「连接超时」的常见原因。

其它引擎的连接方式各不相同： 时序引擎推荐用 JDBC 驱动连接，也可以用 lindorm-cli；搜索引擎可以用 Solr Shell 或 SQL 连接（因为它兼容 Solr/Elasticsearch API）；计算引擎通过 JDBC 连接跑 Spark SQL；LindormDFS 则直接用开源的 HDFS Shell 连接。也就是说，你原来用 Solr 客户端、HDFS 客户端、Spark 客户端的代码，多数不用改。

> 🔐 安全提醒：-password 明文写在命令行里会进入 shell history，也可能出现在其他用户的 ps 输出中。生产环境建议改用环境变量传参，或把连接封装成脚本后收紧文件权限。

> 📝 小提示：lindorm-cli 属于「客户端环境」的一部分，放在 ECS 上跑（走 VPC 内网）比放在本地机器上跑（走公网）更安全也更快，测试阶段可以先用本地公网连，正式上手就迁到 ECS 上。

七、计费与成本测算：五项费用拆开看

Lindorm 的总费用由五项构成，官方文档写得很清楚：

| 计费项 | 说明 | |--------|--------| | 固定费用 | 覆盖管理实例的主节点（master node）的运行成本 | | 存储费 | 按你在所选地域选定的存储类型与容量计费 | | 节点规格费 | 按你在该地域选定的节点类型与节点数量计费 | | 节点内存费 | 按你在该地域选定的节点内存计费 | | 增值服务费 | 弹性计算资源（启用计算引擎后按实际用量按小时计费）、本地盘实例挂载的云盘、LTS 备份存储、LTS 数据同步规格等 |

这里有两个必须记住的细节。第一，多引擎不是叠加购买：官方明确写了，如果你启用了多种引擎，同类型节点的 CPU 核数会合并计费、内存（GB）也会合并计费——所以「宽表 + 搜索」共用一个实例，比各买一套要省。第二，弹性计算资源有上限设置：官方提示这是付费功能，要设置一个合理上限以避免流量高峰期的意外费用，而且上限限制的是计算引擎可用的最大资源量，不是实际用量——也就是「封顶」封的是天花板，不是账单预估。

关于单价，需要说清楚一件事：阿里云国际版对 Lindorm 没有在公开文档里逐档刊列单价，价格随地域、存储类型、节点规格、计费方式变化，官方口径是到购买页与结算页查询。所以本文不虚构一张「精确到分」的价目表，而是给出官方文档中真实出现的参考月价——它们来自官方的「配置变更计费」算例：

| 配置（宽表引擎节点） | 节点数 | 官方文档给出的参考月价 | |--------|--------|--------| | 4 核 / 16 GB（含 480 GB 存储） | 2 个 | USD 185.76 / 月 | | 8 核 / 16 GB | 2 个 | USD 312.63 / 月 |

这两个数字是官方算例里明写的包年包月月价，可以直接作为「规格翻倍、价格大约翻不到一倍」的量级参照。注意它不含地域差异与增值服务费，请以控制台结算页为准。

扩容费公式也值得单独记一下，因为它是「先买小再升级」策略的计算基础。升级时按剩余时长补差价：

` 升级费 = (新配置月价 / 30 × 剩余天数) − (原配置月价 / 30 × 剩余天数) `

官方的算例是：把 2 个 4 核/16 GB 的宽表节点升到 8 核/16 GB，若剩余 50 天，费用约为 (312.63 / 30 × 50) − (185.76 / 30 × 50) ≈ USD 211.45。降级则按剩余时长退差价。但官方同时强调两条纪律：第一，剩余时长是按秒计算而不是按天；第二，升级页面上显示的金额才是最终金额，不要自己估算后照着付——这条官方原文写得很直接，也是最该照做的一条。

最后是到期与欠费口径，它的严格程度超出很多人预期：

| 场景 | 后果 | |--------|--------| | 包年包月实例到期 | 立即停服，状态变为 Locked | | 到期后 15 天内 | 续费即可恢复 | | 到期满 15 天 | 计算与存储资源被释放，数据永久删除且不可恢复 | | 按量实例所在账号欠费 | 该账号下所有按量实例立即停服（不是只停欠费的那个） | | 欠费 0–15 天 | 充值后所有实例立即恢复 | | 欠费满 15 天 | 资源释放，数据永久删除且不可恢复 |

「所有按量实例立即停服」这一条特别值得注意——一个测试实例忘了充钱，可能连带把生产环境的按量实例一起停掉。这不是危言耸听，是官方文档的原话。

八、八条省钱动作与避坑清单

1. 稳定负载走包年包月。 官方口径是「预付费、时长越长折扣越大」，波动性负载才用按量；两者可互相切换，先按量试跑、跑稳了再转包年是最稳的路径。 2. 冷热分层是最大的一张牌。 标准存储与性能存储都可以叠加容量存储存放冷数据，不用迁移实例、不改表结构，把不常访问的历史数据挪到容量层即可显著降本。 3. 用本地盘之前先算副本。 本地 SSD/本地 HDD 按物理容量计费，默认 3 副本——100 GiB 逻辑数据实际计 300 GiB，而且至少 3 个节点才能维持三副本。IO 密集场景它划算，冷数据场景它很贵。 4. 多引擎共用一个实例。 同类型节点的 CPU 与内存合并计费，别按引擎各买一套实例。 5. 给弹性计算资源设上限。 官方明确这是付费功能，设上限可避免流量尖峰带来的意外账单。 6. 不用就释放，别只停不删。 按量实例不退款，不再需要时释放实例才能停止计费。 7. 白名单别开 0.0.0.0/0。 省下的十分钟配置时间，可能要拿数据泄露来还。 8. 预算以结算页为准。 升级页显示的金额才是最终金额，官方原话如此；也别照搬网上旧文章里的数字做预算。

三个高频避坑点再说一遍： 地域创建后不可更改；商品类型（Lindorm / Lindorm V1 / Tunnel）之间不能互换；多可用区 HA 只支持宽表引擎。这三条都是在「第六步点购买」之前就必须想清楚的。

九、常见问题 FAQ

- Q: Lindorm 和开源的 HBase 是什么关系？ A: 宽表引擎兼容 HBase API，已有 HBase 应用改连接串和少量配置即可迁移。官方给出的对比口径是：相比开源 HBase，读写吞吐 3–7 倍、P99 延迟约 1/10、压缩比约 2 倍、存储成本低约 50%。这是官方口径，建议用自己的业务负载实测后再下结论。

- Q: 一个实例能同时启用多种引擎吗？ A: 可以，五类引擎都能在一个实例里启用，且每类引擎独立扩缩容。计费上同类型节点的 CPU 核数与内存会合并计算，不会重复收两份。

- Q: 宽表引擎的最低规格是多少？ A: 节点规格范围是 4 核 8 GB 到 32 核 256 GB，但当商品类型选 Lindorm（而非老的 Lindorm V1）时，宽表与时序引擎的最低规格为 4 核 16 GB。老文章里的 4 核 8 GB 在新商品里选不到。

- Q: 存储到底怎么计费，要不要乘副本数？ A: 分两类。标准存储、性能存储、容量存储按逻辑容量计费，不用乘副本；本地 SSD、本地 HDD 以及挂载的云盘按物理容量计费，本地盘默认 3 副本、云盘默认 2 副本，所以要乘。

- Q: 该选包年包月还是按量付费？ A: 负载稳定选包年包月（时长越长折扣越大），负载波动或短期验证选按量。两者创建后可互转，先按量试跑再转包年是常见路径。

- Q: 忘记续费/欠费会怎样？ A: 包年包月到期立即停服；按量实例则是在账号欠费时，该账号下所有按量实例一起停服。两者都有 15 天的宽限期，充钱或续费即可恢复；超过 15 天资源释放、数据永久删除且不可恢复。

- Q: 明明白名单配了还是连不上，怎么排查？ A: 按顺序查三件事——① 用的是 -vpc 内网地址还是 -pub 公网地址，内网地址只能从同一 VPC 的 ECS 访问；② 白名单里加的是不是当前客户端的源 IP；③ ECS 与 Lindorm 是否在同一地域、同一 VPC。这三条覆盖了绝大多数「连接超时」。

- Q: Lindorm 的单价在哪里查？ A: 官方公开文档未逐档刊列单价，以控制台购买页与结算页为准。本文表格中的 USD 185.76 / 312.63 是官方文档算例里出现的参考月价，仅作量级参照，不代表你的实际报价——价格可能变动，请以官方为准。

- Q: 买错了/不用了能退款吗？ A: 包年包月实例可以申请退款，退款金额按订阅详情计算；按量付费实例不退款，不再需要时释放实例即可停止计费。

- Q: 国际站和国内站的价格一样吗？ A: 不一样，同一产品不同地域的单价都不同。作为同族参照，阿里云国际版 Hologres 的国际地域单价比中国大陆主要地域高约 15%～26%（数据来自官方计费文档，采集于 2026 年 9 月）。Lindorm 同理，最终以你选定地域的控制台结算页为准。

十、总结

三句话收尾：第一，Lindorm 的价值在「收拢」——把宽表、时序、搜索、计算、流五类负载收进一个实例、一套存储，用统一 SQL 查询，省下的是几套系统的运维成本和数据搬运成本；第二，它的成本结构是「存储分层 + 规格分级」，省钱重心在两条：冷数据下沉到容量存储、负载类型选对节点规格，而不是一味压缩节点数量；第三，最常见的踩坑全是计费与配置规则——本地盘按物理容量含副本计费、多可用区 HA 只支持宽表、地域与商品类型创建后不可改、到期 15 天数据永久删除、按量欠费会连坐整个账号。

如果你准备上手，建议的落地顺序是：先用 ECS 选购教程 确定地域与规格 → 用本文开通 Lindorm、配好白名单、用 lindorm-cli 连上并跑通第一条查询 → 用 日志服务 SLS 承接旁路日志 → 用 云监控 CloudMonitor 补齐资源告警 → 最后用 省钱攻略 把承诺折扣叠加到长期稳定的实例上。

相关阅读： - 事务型数据库底座：阿里云国际版 RDS 数据库选购+实战教程 - 云原生关系库对照：阿里云国际版 PolarDB 云原生数据库实战教程 - 分析型数仓互补篇：阿里云国际版 Hologres 实时数仓实战教程 - 日志链路联动：阿里云国际版日志服务 SLS 实战教程 - 数据库灾备与调优：阿里云国际版 RDS 灾备与性能调优实战

> ⚠️ 免责声明：本文中的配置步骤、计费机制与参考价格引自阿里云国际版官方产品页与帮助文档（采集于 2026 年 9 月），价格可能变动，请以阿里云国际版官网（alibabacloud.com）实时信息为准。文中以美元标注的配置月价来自官方文档算例，仅为示意参考，不代表任何实际报价；实际费用随地域、规格、计费方式、存储类型与增值服务而变化，请以控制台结算页显示金额为准。金额单位除特别标注外均为美元（USD）。本文不构成任何投资或购买建议。注册与使用云服务前，请确认当地法规合规性。

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