一、ARS的工作原理 #

简单来说，ARS是Azure Cosmos DB底层的「通用数据骨架」，它把所有类型的数据都拆解成三个基础单元来存储和管理：

• Atom：这是最小的不可分割数据单元，就像积木里的最小颗粒——一个字符串、数字、布尔值，甚至是一个空值，都属于Atom的范畴。不管你存的是JSON文档、表格行还是图形节点，最终都会被拆成这些最基础的「数据颗粒」。
• Record：把相关的Atom组合在一起，形成一个有逻辑意义的「数据块」。比如JSON里的一个对象、表格里的一行数据、图形里的一个节点，都是一个Record——相当于把零散的积木颗粒拼成一个小部件。
• Sequence：将多个Record按特定顺序组织起来，形成更大的数据集。比如一个JSON数组、表格里的多行数据、图形里的一组节点和边，就是一个Sequence——就像把多个小积木部件拼成一个完整的模型。

在存储层面，ARS采用**日志结构合并树（LSM Tree）**来处理读写操作：写操作会先快速写入内存中的缓存，之后再批量异步刷写到磁盘；读操作则会自动合并内存缓存和磁盘中的数据，确保你拿到的是最新结果。这种设计让ARS在高并发场景下依然能保持出色的读写性能。

二、ARS如何支撑多模型架构并避免性能损耗 #

Azure Cosmos DB之所以能支持文档、键值、图形、表格、列族这五大数据模型，核心就是ARS的「通用适配性」，而且完全不会有跨模型的性能损耗，原因如下：

1. 统一底层存储，无需模型转换
   不管你用哪个API（SQL、MongoDB、Gremlin、Table等）写入数据，底层都会直接映射成ARS的Atom/Record/Sequence，不需要额外的格式转换。比如你用MongoDB API存一个BSON文档，底层就是ARS的Record；之后用SQL API查询时，直接读取ARS的存储单元即可，不用把BSON转成JSON再处理——中间没有任何「翻译」成本，性能自然不会打折扣。

2. 按需映射模型，保留原生体验
   ARS不会强制上层模型改变形态，而是根据不同模型的特性，把ARS的基础单元「组装」成对应模型的样子。比如：

   • 键值模型：把键作为一个Atom，值作为一个Record，多个键值对组成Sequence，完美适配键值存储的快速读写需求。
   • 图形模型：把节点和边分别作为Record（包含属性Atom），用Sequence来管理节点和边的关联关系，让Gremlin查询可以直接遍历底层的Sequence，保证图形遍历的高效性。

3. 共享性能优化，所有模型受益
   ARS底层的LSM Tree、分区策略、索引优化等性能特性，是所有上层模型共用的。比如自动索引功能，ARS会为所有Atom建立索引，不管你用哪个模型查询，都能快速定位到目标数据——不会因为模型不同而单独做索引，既节省了资源，又保证了跨模型的一致性能。

简单总结：ARS就像是Azure Cosmos DB的「万能工具箱」，不管你要搭建哪种数据模型的应用，它都能提供合适的基础部件，而且全程不需要额外的转换步骤，自然就能避免性能损耗，同时让多模型架构成为可能。

内容的提问来源于stack exchange，提问作者user8971331