背景
Timestream模型是针对时序场景设计的特有模型，可以让用户快速完成业务代码的开发，实现相关业务需求。但是，如果业务系统不仅想实现基础的相关业务功能，还要达到最佳的性能，并且兼顾到未来的扩展性的话，就不是一件特别容易的事情。
本文会以共享汽车管理平台为例，介绍一系列的timestream最佳设计和使用，给业务设计和使用提供一些参考。关于共享汽车管理平台的场景，细节请参考：《基于Tablestore的共享汽车管理平台》。
场景和模型简介
在共享汽车管理平台这个场景中，主要是对车辆的状态轨迹监控、车俩元数据以及订单元数据进行管理。另外，还会对相关的数据进行计算分析并存储相关结果：
- 车辆状态轨迹：记录了车辆的状态监控，比如车速、位置、续航等数据，另外还需要记录车辆行驶过程中的违章记录，比如：是否超速、是否闯红灯等等；
- 车辆元数据：记录车辆的基本属性信息，便于用户进行车辆检索，比如：车型、车牌、颜色等；
- 订单元数据：订单相关信息记录，包含行程的起止时间、车辆、用户、费用等信息
业务主要是对上面三部分数据进行查询和检索，满足业务场景的需求。其中车辆元数据以及状态轨迹数据是典型的时序序列，可以很方便的映射到Timestream模型中。
下图是数据模型的映射：
下面介绍一下模型设计的细节以及设计中需要注意的一些优化点，这些优化点对于业务功能以及性能上都有一定的提升。
业务模型设计
在Timestream模型中，主要包含了元数据和数据点两部分数据，分别使用一个元数据表以及若干个数据表进行存储。下面介绍这两类数据在存储设计的关键点。
元数据表设计
在共享汽车这个场景下，元数据表主要存储两类数据：车辆的基本信息、车辆的最近状态数据（位置、续航、状态、违章统计等），业务会根据各类信息进行多条件的组合查询符合条件的车辆。
如上图所示，Timestream的元数据表会通过多元索引来提供丰富的数据检索能力。在Timestream模型的元数据中，包含了name、tags、attributes三类数据，其中name、tags默认会提供数据检索能力，attributes则需要在创建Meta表的时候指定需要索引的attributes字段以及相关信息，默认attributes并不支持检索。
需要注意的是，目前并不支持动态修改Meta表的索引字段，所以最好能在设计之初能够考虑到当前以及未来的功能需求，下面介绍一下相关信息是如何映射到模型以及相关的设计。
name设计
name字段的选取是很关键的，是数据检索性能的一个重要影响因素，不同的name字段设计可能会导致查询延时相差一个数量级。name字段的选取建议满足以下条件：
- 绝大多数查询场景都会对该字段进行精确查询
- 该字段单个取值下的最大记录数不宜过多，比如说不超过一千万条记录
在共享汽车管理平台这个场景下，管理的是各个平台的车辆，而在车辆检索的时候，一定会指定的条件是平台的名字，并且某个平台的车辆其实也不会太多，一般也就百万量级，所以这里可以将平台作为name。
tags设计
在Timestream模型中，Name和Tags可以唯一确定某个元数据，在这个场景中，唯一确定某辆车的信息是：平台、车辆ID，其中平台是name，所以，tags中只需要存储ID即可。
tags设计需要注意：
attributes设计
attributes是主体的可变属性，也可以用来存储主体的非唯一属性。在这个场景中，车辆的基本信息以及当前状态都是用attributes来进行存储。attributes设计关键点：
- 创建meta表的时候需要指定有检索需求的attributes以及相关属性，默认attributes是不支持索引的
- 数值型数据尽可能使用int来存储，attribute支持多类型的数据，但在数据检索过程中，int类型的数据检索效率比string类型高的多，建议使用int，索引类型为LONG
- 考虑未来系统的扩展性，可以预留一列作为扩展字段，索引类型为KEYWORD，并且是Array
索引创建示例代码：
public void createMetaTable() {
db.createMetaTable(Arrays.asList(
new AttributeIndexSchema("地区", AttributeIndexSchema.Type.KEYWORD),
...
// 数值类型索引
new AttributeIndexSchema("座位", AttributeIndexSchema.Type.LONG),
...
// 扩展字段，数组类型索引
new AttributeIndexSchema("配置1", AttributeIndexSchema.Type.KEYWORD).isArray()
));数据表设计
Timestream可以支持多个数据表的存储，来满足不同的业务场景需求。另外，为了能够利用底层引擎所做的性能优化，我们推荐append的写入方式，即不会对已有数据进行修改，所以在以下场景中，我们建议业务将数据分到不同数据表中进行存储：
- 数据精度不同，特别是在监控场景下，这个需求更加突出。按数据精度分表便于后续数据的查询，如果查询长周期的数据可以去查询低精度的表，减少查询的数据量，提高查询效率
- 需要对数据进行加工处理，也就是会对数据进行更新，建议将处理之后的数据写到另外一张表中
在共享汽车这个场景中，需要对车辆的状态轨迹数据进行流式处理，比如检测是否超速等违章、车辆状态轨迹是否异常等，然后将处理之后的数据写到另外一张表中，提供给业务进行查询。
sdk使用
前面介绍了业务模型设计需要注意的地方，对业务功能拓展能力以及性能都有一定的提升。下面介绍一下timestream sdk使用的一些性能优化点。
数据写入
元数据
元数据写入支持两种方式：put和update。其中put会删除老的记录，并且插入一个全新行；update则是对原有记录的部分attributes进行更新。建议尽量使用Put的方式进行写入。
示例代码：
public void writeMeta() {
TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("*滴")
.addTag("ID", carNo)
.build();
TimestreamMeta meta = new TimestreamMeta(identifier)
.addAttribute("地区", "杭州")
.addAttribute("座位", 4)
...
.addAttribute("状态", "闲置");
// 插入车辆信息
metaWriter.put(meta);
}数据点
数据点写入也提供了两种方式：同步和异步。其中异步接口底层是通过TableStoreWriter进行异步写入，其写入吞吐能力更高，对写入延时不是特别敏感的业务建议使用异步方式。
示例代码：
public void writeData() {
TimestreamIdentifier identifier = new TimestreamIdentifier.Builder("*滴")
.addTag("ID", carNo)
.build();
Point point = new Point.Builder(1546272000, TimeUnit.SECONDS)
.addField("位置", "30.1457580736,120.0563192368")
.addField("车速", 30)
.addField("续航", 100)
.build();
// 异步写入
dataWriter.asyncWrite(identifier, point);
}数据查询
元数据查询
元数据查询的时候，建议指定需要返回的列名。如果没有显示指定列名的话，会去读主表以获取完整的信息，这样每一行元数据都会反查一次主表，查询性能会更差一些。
示例代码：
Filter filter = Name.equal("*滴");
// 用selectAttributes指定需要返回的attributes
Iterator<TimestreamMeta> iter = metaTable.filter(filter)
.selectAttributes("座位", "状态")
.fetchAll();总结
本文介绍了Tablestore Timestream在模型设计以及sdk使用中的一些优化点，对于业务现有功能实现、未来拓展以及性能提升都有很好的作用，更加细节的timestream使用请参考《Timestream模型》。如有更多疑问，欢迎加入【表格存储公开交流群】，群号：11789671。
