数据不能丢

交通数据除了用来调节城市交通外，还有一个重要作用是公安用来查询嫌疑车辆的通行情况，类似于我上面“查询种类多”中列举的第一种查询需求，这种场景下，每一辆经过交通路况的车辆信息都不能丢失，否则会影响刑侦判断和进展，可能会造成比较严重的后果。所以，整个系统对数据存储的可靠性，以及传输链路的可靠性要求都极高，尽力要做到不丢数据。

针对上述的场景需求，目前业内已经有多种解决方案，我们接下来看一下：

开源解决方案

一种很容易想到的方案是使用关系型数据库，比如MySQL或PostgreSQL存储，但是这种只适合存储小数据量，如果数据量超过单机存储能力，则会不适合。就算采用了分库分表的方式，也会带来极大的运维压力和产品功能牺牲。

另外一种方案，是从数据可靠性角度考虑，使用HBase等分布式NoSQL数据库，但是这种NoSQL数据库只提供单Key和Key前缀范围查询，无法支持按照其他属性列查询，无法满足我们上面的需求，就算引入Phoenix使用了二级索引，也需要提前固定好查询，无法支持自由组合，更无法支持地理位置查询。

还有一种方案，是从查询复杂度考虑，直接使用搜索引擎Elasticsearch或Solr，但是这种虽然能满足查询需求，可惜没法满足数据不能丢的要求，存在丢失数据的风险。

至此，考虑了所有开源系统后，没有一个系统能满足用户需求，那么只能退而求其次，采用组合大法：

• 存储系统使用HBase，保证数据可靠性。
• 同步方式采用Lily Indexer。
• 查询引擎使用solr系统。

上述架构方案，看起来满足了我们上面的所有需求，虽然麻烦了点。但是只能算是基本满足，因为这套架构存在比较大的问题：

• Lily indexer基于HBase的日志顺序，依赖一个时间戳，推送服务需要根据时间戳进行重排序再写入，在很多场景下难以做到严格的保序，可能会丢数据。
• 存量数据，以及solr中索引数据损坏后需要rebuild index时，需要使用运维人员通过工具去做，增加风险的同时还要只能整个系统的运维压力。

除此之外，还需要运维HBase、Lily index、Proxy和Solr四个系统，需要配备熟悉这四个开源系统的人员，这个又是一笔额外支出。除了开源解决方案外，如今又多了一种选择，使用云解决方案。

TableStore云解决方案

在现有的各种云产品中，能满足上述交通数据存储需求的系统并不多，阿里云TableStore是一款符合要求的系统，10年前就开始自研，多年的双十一、公有云客户的锤炼沉淀，保证了系统的可靠性和稳定性。

我们先来看一下基于TableStore存储交通数据的架构方案：

示例

接下来，我们举个例子帮助读者理解。

某个城市在每一个交通路口安装了摄像头，记录通过每个路口的实时车辆信息，包括车牌、车颜色、车类型（救护车、消防车、公交车、私家轿车等）、车速、时间、路口位置、路口名称。

首先，我们设计TableStore中主表结构：

上述主表结构中，只能支持查询某个路口过去一段时间内的车辆通行列表，或者每个路口实时的车辆通行情况。

另外，这种表中，我们把路口的信息，包括路口名称、路口位置等也存在了每辆车通行信息中，这样带来的好处是查询的时候简单，只需要查询单个系统即可，但是也带来了数据冗余，有时候也会将这部分数据单独存储。

接下来，我们定义TableStore多元索引的结构：

• 时间戳、车牌、车颜色、车类型都是String，其中车牌可以支持模糊查询和前缀查询。
• 车速是浮点数。
• 路口名称采用了Text类型， 支持分词，分词使用了单字分词，这样通过查询“余杭塘河路”就能查询到“花蒋路和余杭塘路”，这里不要采用其他分词方式，因为其他分词方式总会有bad case，会导致某些查询不到。
• 路口位置采用了GeoPoint类型，这个类型支持范围查询，比如某个点附近几公里内的车辆信息，同时也支持某个多边形范围内的车辆通行信息。

基于上述的表和index，我们就能满足上述提到的所有查询需求。另外，可能还有一些统计需求，比如统计每个路口过去二十小时的通行车辆数，或者统计过去一分钟通过车辆最多的前10个路口。

总结

至此，开源解决方案和TableStore云解决方案都介绍完了，使用了TableStore云解决方案后，能带来不少的收益。

减少运维负担

系统架构更简单

减少时间成本

数据可靠性更高

最后