# 数据库大赛

**Repository Path**: f-hk/database-competition

## Basic Information

- **Project Name**: 数据库大赛
- **Description**: 数据库大赛作品（前端）
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2020-12-18
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 数据库大赛需求文档
>主题：车辆轨迹检索系统
>成员：朱珺阳、崔文博、刘泽宇
>指导老师：李莉

`v1.0`
## 一、需求分析
1、作品简介：通过大数据技术实现的指定范围内的车辆轨迹检索系统。可以精确查询**50M**范围内的车辆并绘制轨迹。

### 2、应用场景
功能类似于‘附近的人’。可以实现查询指定地点**50米到2公里**附近某一车辆某一天的行动轨迹。疫情期间可以进行大数据车辆检索，对某一地点的车辆轨迹进行查询，同类型产品可以对比北京健康宝。也可以为警方提供车辆信息检索。
![markdown](http://zhu-junyang_admin.gitee.io/picture/2.png)

### 3、实现功能
* 指定时间段内精确查询附近50米到2公里的车辆
* 通过查询出来的车辆ID绘制轨迹
* 地点搜索

### 4、技术栈
前端：`Vue.js`+`Museui`+`高德地图API`

后端：
* 数据库：`mysql`,`hbase`,`redis`,`elasticsearch`
* 语言：`golang`,`python`
* 框架：`happybase`(python操作hbase)、`gorm` (go操作mysql)、`g-redis | g-elastic`(go操作redis、es)
* 容器：docker

算法：Geohash算法，Google S2算法（正在研究）

## 二、数据库设计
主要字段如下：
* Geohash --> **geohash字符串**
* status --> **车辆状态（载客/未载客）**
* direction --> **车辆方向**
* lng --> **经度（WGS84坐标系）**
* lat --> **纬度（WGS84坐标系）**
* speed --> **车辆速度**
* time --> **经过时间**
* carno --> **车辆唯一标示码**
![markdown](http://zhu-junyang_admin.gitee.io/picture/4.png)
>mysql=> 一个季度为一个库。根据日期分表，查询具体日期先查表。主键：Geohash+random（10）组成的字符串，经纬度为WGS84转GCJ02后的经纬度，其余与原字段保持一致。mysql并不适合大数据量的查询，只能以主键作为索引（唯一性）来保证大数据量的查询效率。

>redis=>

>hbase=>

>elasticsearch=>与mysql类似，可以进行geohash的模糊查询。暂未实际应用到项目中。

## 三、系统设计
#### 1、实现思路
```mermaid
graph TD
A[选择地点] --> B(选择时间段)
    B --> C{进行查询}
    C --> |查询到结果| D[列出所有车辆信息]
    C --> |未查询到结果| E[重新选择]
    E --> A
    D --> F(选择司机ID)
    F --> G(查询该司机一天内所有经纬度坐标)
    G --> H(绘制轨迹)
```

#### 2、技术路线

```mermaid
graph TD
A[前端获取用户选择的地点坐标以及时间段] --> B(发送到后端)
    B --> C{依据条件进行查询}
    C --> |查询到结果| D[返回数据]
    C --> |未查询到结果| E[返回错误信息并记录日志]
```

## 四、系统实施
>Geohash是一种检索时空大数据的算法，精度最高为12位。依据不同的精度区分不同范围。例如精度为8时，可以查询范围为50米的矩形或圆形。因此我们可以通过模糊查询geohash字符串的公共前缀，进行数据检索。

>高德地图是GCJ02坐标系，同时geohash的精度也并不高导致不同经纬度会有重复geohash值，因此需要对原始数据进行处理。首先转换原始坐标系为高德坐标系，其次geohash字符串需要连接random（10）字符串保证唯一性。最后将生成的csv存入数据库

>对于mysql，利用模糊查询like查找geohash公共前缀以此获取数据，对于mysql的索引来说，只有在like%查询时索引生效，正好符合需求。查询时间较快。司机id查询轨迹用了order by + where语句。

>redis

>hbase

>对于大数据量的查询需要前后端协同，主流的解决方案是分页查询。

>前端利用高德API实现地点选择、轨迹绘制等功能。通过Vue.js响应式框架快速渲染后端数据并呈现在页面上，并用Muse-ui做界面美化。
![markdown](http://zhu-junyang_admin.gitee.io/picture/1.png)

## 五、系统测试与评价
>从开发角度来说。mysql主键索引可以做大数据量的简单查询，时间在1s以内，而order by + where 语句则消耗时间过长，原因是没有走主键索引，解决方案是where自查询走索引或强制走主键索引。

>从使用体验角度来说。从地点查询到显示轨迹的时间几乎可以忽略不计。轨迹绘制精确，较为直观。

## 六、未来展望
>Google S2算法

## 七、开发过程问题
1. 学校服务器不能开放端口，不能访问外网，环境相对来说不好配置。
2. 尝试本地或公有云配置hbase环境，linux内部直接配置环境非常复杂。通过docker容器解决。
3. sql语句没有做分页限制，一次查询数据量过大导致内存溢出。
4. 通过navicat导入csv到mysql会产生较大的日志占用系统空间。
5. geohash精度较差，每一位与每一位之间相差距离较远。
6. geohash有重复值，不能直接作为主键，因此必须加上random（xx）
7. 高德坐标系与原始坐标系不同，需进行转换。
8. 高德提供的API函数均为异步函数，对于前端来说需要等待异步（async await）结果，否则无法同步获取数据，导致数据无法渲染。
9. ..........