Timestream开发最佳实践

背景

Timestream模型是针对时序场景设计的特有模型，可让用户快速完成业务代码的开发，实现相关业务需求。可是，若是业务系统不只想实现基础的相关业务功能，还要达到最佳的性能，而且兼顾到将来的扩展性的话，就不是一件特别容易的事情。

本文会以共享汽车管理平台为例，介绍一系列的timestream最佳设计和使用，给业务设计和使用提供一些参考。

场景和模型简介

在共享汽车管理平台这个场景中，主要是对车辆的状态轨迹监控、车俩元数据以及订单元数据进行管理。另外，还会对相关的数据进行计算分析并存储相关结果：

• 车辆状态轨迹：记录了车辆的状态监控，好比车速、位置、续航等数据，另外还须要记录车辆行驶过程当中的违章记录，好比：是否超速、是否闯红灯等等；
• 车辆元数据：记录车辆的基本属性信息，便于用户进行车辆检索，好比：车型、车牌、颜色等；
• 订单元数据：订单相关信息记录，包含行程的起止时间、车辆、用户、费用等信息

业务主要是对上面三部分数据进行查询和检索，知足业务场景的需求。其中车辆元数据以及状态轨迹数据是典型的时序序列，能够很方便的映射到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设计须要注意：

• tags的总长度尽量的短，只把惟一肯定主体的信息放到tag中，其他信息均放到attributes中
• tag只支持string类型的数据，若是业务字段是数值类型，须要将其转成string进行存储

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使用中的一些优化点，对于业务现有功能实现、将来拓展以及性能提高都有很好的做用

原文连接 本文为云栖社区原创内容，未经容许不得转载。