Tablestore
定义与本文语境
Tablestore 是阿里云的表格存储产品。在本文中，它不是被当作通用数据库泛泛介绍，而是被明确作为 Agent Memory 框架的底层存储基础设施，用来同时支撑两类 AI 场景：Memory 与 Knowledge。
原文将 AI Agent 概括为：LLM（大型语言模型）+ 记忆（Memory）+ 规划技能（Planning skills）+ 工具使用（Tool use）。在这一结构里，Tablestore 主要承担“记忆”和“知识”两类数据底座角色。
AI Agent 的“感知-决策-行动”闭环需要两类核心存储能力：
- Memory：作为“回忆”，负责情景记录、情景摘要、实时数据抽取等，要求毫秒级响应、高并发、动态 Schema 扩展，典型场景包括用户与大模型的会话上下文管理、实时状态信息同步。
- Knowledge：作为“知识”，负责知识库原文、摘要等内容的存储与检索，核心是语义检索效果，同时也关注规模、性能和成本，典型场景包括 RAG 知识库与多模态搜索。
原文指出，传统数据库如 MySQL 和 PostgreSQL 虽然在许多场景表现良好，但在“大规模数据集下的低成本、稳定性能、扩展性、灵活检索能力”这些要求同时成立时，会出现一定瓶颈。因此作者基于 Tablestore 在这些方面“天然适合”的特性，总结客户经验，提出了基于 Tablestore 的轻量级 Agent Memory 框架。
在 Agent Memory 框架中的角色职责
在该框架中，Agent Memory SDK 位于上层，负责屏蔽底层实现细节；Tablestore 位于底层，负责真正承载 Memory 与 Knowledge 两类数据。其职责可以拆成两部分：
1. 作为 Memory 的存储底座
用于承载会话管理、历史消息存储等情景记忆场景。原文强调，这类场景最常见的是会话管理和历史消息存储，并以此设计了两个核心数据对象：
- Session：表示会话
- Message：表示消息
开发者通过 SDK 操作 MemoryStore，但底层实际由 Tablestore 负责数据落库、更新和查询。
2. 作为 Knowledge 的检索底座
用于承载文档、向量、全文内容与元数据过滤，并服务于 RAG、语义搜索等长期知识检索场景。开发者通过 SDK 操作 KnowledgeStore，底层则依赖 Tablestore 的全文检索、向量索引与多元索引能力完成查询。
关键能力与设计信息
Memory 场景下的适配能力
原文认为 Tablestore 天然适合 Memory 场景，主要因为这类场景对以下能力要求很高：
- 毫秒级响应
- 高并发读写
- 动态 Schema 扩展
- 大规模数据下的低成本
- 稳定性能
- 可扩展性
- 灵活检索能力
在具体产品能力上，原文多次点名其用于 Memory 的关键特性包括：
- 宽表模型
- 二级索引
- 多元索引
这些能力被用于支撑聊天记录、会话管理、日志、交互等核心数据的高效存储与管理。
Memory 的典型访问方式
原文给出了聊天场景示例：
- 先创建 Session，并记录
user_id、session_id、update_time以及模型名等元数据。 - 用户每次发言，写入一条 Message；同时更新 Session 的
update_time。 - 大模型每次回复，也写入一条新的 Message。
- 当用户继续追问如“再来一个”时，可以按条件查询最近若干条历史消息，再把这些消息传给大模型，用作上下文。
示例中明确展示了一个重要约束：记录用户消息时，需要同时更新 session 信息，文中示例仅以更新 update_time 为例。
另外，消息检索支持按元数据过滤。示例中通过 Filters.eq("message_type", "用户") 过滤，只取用户消息，再分页取最近 3 条历史消息。
Knowledge 场景下的适配能力
在 Knowledge 场景中，原文强调 Tablestore 主要依赖以下三类能力：
- 向量检索
- 全文检索
- 多租户设计
表设计与主键设计
原文给出了较明确的设计原则：
DocumentID作为表的分区键。- 这样可以把所有文档离散到各个分区。
- 因为“全文 + 向量”会导致单行较大，所以把
DocumentID放在第一个主键作为分区键，以便均衡各分区的读写压力。 DocumentID与TenantID组合起来作为唯一主键。- 如果用户不是多租户场景，
TenantID填默认值即可。
多租户路由能力
原文特别强调了多租户特性并说明了其边界：
- 当用户开启多租户特性后，会把
TenantID设置为多元索引的路由键。 - 这样同一租户的数据可以落到指定分区上。
- 查询时就不需要访问所有分区。
- 结果是降低查询消耗，并减少“毛刺”。
这说明多租户不是抽象概念，而是直接影响路由方式、查询范围与稳定性的具体实现机制。
全文与向量索引能力
原文给出的细节包括：
- 文本字段
text在多元索引中会自动创建“最大语义分词”。 - 如果需要其他分词方式，可以随时修改。
- 向量字段
embedding会自动创建向量索引。 - 内部会自动选择合适的索引结构进行索引。
- 用户无需手工调优和优化。
检索方式与过滤能力
示例代码展示了两种典型查询：
- 向量搜索：给定
query_vector，设置top_k=20，并可带tenant_id与元数据过滤条件。 - 全文搜索：给定查询词如
"abc hi"，设置limit=50，同样可带tenant_id与元数据过滤条件。
元数据过滤支持逻辑组合。示例中使用了：
Filters.eq("meta_string", "hi")Filters.gt("meta_long", 1)- 再用
Filters.logical_and([...])组合
这表明 Tablestore 在 Knowledge 场景中不只是“向量库”，而是支持全文、向量、标量过滤联合使用的数据底座。
性能、规模、成本与可用性
Memory 场景指标
原文给出的 Memory 场景数据比较具体：
- 理论上的写入和查询 QPS 很容易支持到几百万甚至千万级别。
- 受限于真实业务情况，目前 Memory 场景最大的线上真实业务查询和写入大概在“十几万 QPS”量级。
- 在单行较大的情况下，写入延时为 1~8ms。
- 查询延时为 1~4ms。
- 单个 Memory 表最大规模可到 PB 级别。
在成本与可用性方面，原文还给出两个明确表述：
- 成本按实际用量计费。
- 对于存储型业务，在指标对齐情况下，有信心做到成本最低。
- 默认提供 3AZ，即同城 3 可用区部署的容灾能力。
- 目标是把可用性做到最高。
Knowledge / RAG 场景指标
原文对向量检索场景也给出了具体边界：
- 单向量表理论最大规模可到千亿级别。
- 目前线上最大向量单表已到百亿级别。
- 查询 QPS 峰值在 2K+。
- 向量检索延时在 10ms~120ms。
- 同样按量付费。
- 同样默认提供 3AZ 容灾能力。
这些数字说明，Tablestore 在本文中被定位为同时覆盖“极高吞吐的 Memory”与“高规模向量/全文检索的 Knowledge”两种不同负载模型。