mysql 轨迹数据存储

前言

现在越来越多的人都开始关心自己的运动数据，比如每日的计步、跑步里程、骑行里程等。运动APP与运动类的穿戴设备借助传感器、地图、GPS定位等技术，收集好运动数据以后，通过与互联网社交功能结合，产生了一种新的运动模式。用户不仅可以查看与分析自己的运动数据，还可以分享跑步路线、骑行路线给附近的运动好友，还可以组团跑步、推荐运动设备等，吸引了各年龄段的用户。

核心需求

现在比较流行的一些运动APP和穿戴设备都提供了较为丰富的功能，甚至可以购物和社交。但运动轨迹管理、运动数据分析、附近的跑步路线/骑行路线、附近的运动团这些始终是核心功能点。

运动轨迹数据可以是穿戴设备生成的也可以是手机APP生成的，先在APP端存储，最后由手机APP批量上传到服务端。服务端和数据库都需要支持高并发的读写、数据库要支持海量的存储。

附近的运动好友、附近的运动路线、附近的运动团数据量相对会少一些，但需要支持地理位置检索。

数据模型

如下方左边的图所示，一次跑步或者骑行就会产生一条轨迹信息。我们可以把轨迹数据分成两个部分：跑步记录和轨迹点信息。

附近的人、附近的跑步路线这类数据，我们可以把它们都看成一个点。例如：我们认为跑步路线的起始点就是它的位置，于是就有了右下方的图：中间点是我，以我为中心，去查找附近N公里范围内的数据。

技术选型

我们主要分析下MySQL与Tablestore这两种数据库在运动场景下的使用。

MySQL

运动轨迹数据不能删除，存储量会越来越大，使用MySQL首先要考虑的是它是单机型数据库，横向扩展不友好。另外轨迹数据写多读少，大部分是冷数据，用MySQL存储也不经济。当用户规模大起来以后，轨迹点上传对于数据库的读写性能也有很高的要求。总结起来有如下劣势点：

单机数据库，不好扩容，存储容量受限。

存储大量冷数据，成本高，不经济。

对于海量高并发运动轨迹数据的读写需要做很多优化。

Tablestore

Tablestore(表格存储)是阿里云自研的面向海量结构化数据存储的Serverless NoSQL多模型数据库，提供了面向轨迹类场景的Timestream模型，可提供PB级存储、千万TPS以及毫秒级延迟的服务能力。适合运动轨迹的场景 。

跑步、骑行、健走等动动轨迹数据和附近的人、附近的跑步路线，都可以直接使用Timestream模型，官方的JAVA SDK有使用示例。

基于Tablestore Timestream的功能实现

Timestream模型中，数据存储分成meta和data两张表。在我们的场景中，meta表存放两类数据：设备的元数据和轨迹位置、运动记录的订单信息，这两类数据通过Timestream Identifier中的一个tag字段进行区分。data表存放跑步/骑行的轨迹点信息。

Meta数据结构

Timestream的Identifier部分有三个字段，Name用于存放运动主体的名称，比如 xxx手机、xxx手环等，ObjectType用于区分本条记录