之前大数据验证的TDengine，现在已经切换到MatrixDB，还在验证阶段
关于MatrixDB
官方文档
What_is_YMatrix.jpg
时序特性： 支持时序数据的流式快速插入、高压缩比存储和高效查询，支持 first、last、time_bucket 等常用时序函数
目前分布式的时序数据库都不是开源的
如果先解决当前的数据问题，有以下满足时序功能的数据库
influxdb
写性能
写性能.png
磁盘压缩性能
查询性能
查询性能.png
缺点
1、集群版已经闭源商业化，开源版仅支持单机模式
2、单机版性能逊于集群版， 同时没有集群的冗余，当服务器不可用时，写入和查询会立即失败
3、必须是SSD磁盘
matrixDb
MatrixDB是关系型数据库，需要使用关系模型建立数据模型，并且建议使用宽表
设备信息要额外建立一张设备表来存储，并通过ID与指标表关联以减少冗余
mxkv类型解决了关系表模式固定、列数限制与NULL的问题，但暂时不利于压缩存储
GTI以后有没有不固定KV 集合存储的需求？
| influxDB | MatrixDB | openTSDB | |
|---|---|---|---|
| 模型类型 | 非关系型模型（支持行协议即可） | 关系模型（需要提前定义模型结构） | 非关系型模型（支持行协议即可） |
| 拓展性 | 行协议支持属性任意拓展 | 企业版本的 mxkv 高性能 KV 数据类型支持属性拓展，单机版不支持，需要变更表结构 | 支持属性任意拓展 |
| kafka接入 | 支持，需要集成telegraf | 软件本身可以直接消费kafka数据入库，操作比较简单 | 支持，需要集成telegraf |
| 查询语法 | 有独立的语法结构（2.0版本开始使用FLUX函数式数据脚本语言--更新太快），支持跨表数据聚合，需要专门去学习 | YMatrix 基于 PostgreSQL 开发，所以支持 PostgreSQL 提供的标准 SELECT 语句做查询，包括 WHERE,GROUP BY,ORDER BY,JOIN 等复杂语句 （企业版才能支持联邦查询） | 有独立的语法结构，支持简单的查询 |
| 查询监控 | 支持 | 支持 | |
| 对接 Prometheus 监控生态 | 支持 | 支持 | 支持 |
| 存储引擎 | TSM | 基于 PostgreSQL 的 HEAP，YMatrix 自研发的 MARS2 | LSM （基于HBase） |
| 连续查询 | 支持 | 支持（滑动窗口） | 否 |
| 权限要求 | 无特殊权限需求 | 需要创建用户，设置密码（堡垒机禁止使用） | |
| 集群拓展 | 没有开源 | 没有开源 | 支持 |
考虑到以后数据分析场景，指标范围有变化的可能，influxDB的行协议支持属性指标的拓展，而matrixDB需要更改数据模型的结构，在后续的指标范围变更中会增加表结构运维的工作
使用influxdb情况下，以后每个基地只需要建立一个bucket，无需其他的运维工作，如果切换到matrixDB，针对不同的模型需要建立不同的数据模型结构，如果需求变更涉及到模型结构的变动，还得变更对应的数据模型结构
influxDB 窄表
matrixDB 推荐宽表模式
按照目前设备属性值历史记录的使用场景，使用窄表更合适
measurementName,tagKey=tagValue fieldKey="fieldValue" 1465839830100400200
--------------- --------------- --------------------- -------------------
| | | |
Measurement Tag set Field set Timestamp
matrixDb 写入性能 验证是 通过 kafka -> matrixGate 数据流的方式写入的吗？
针对 高性能kv 的查询性能有没有验证
不要使用取值范围很广的数据作为tag,例如uuid,hash等等
如果实在有这方面的需求，考虑一下几点建议
切成多个shard,并分到多个实例上
使用tag 前缀进行区分
使用field
使用集群
Tag Key不要与Field的名称相同
Tags的数量不要太少
database的数量不要太多
当database的数量达到千万级别时，会出现打开文件过多，占用内存过多等问题。
优化
常见的优化方式如下
控制series的数量
Series会被索引且存在内存中，如果量太大会对资源造成过多损耗，且查询效率也得不到保障。
可以通过以下方式查询series的数量：
influx -database 'cloudportal' -execute 'show series' -format 'csv'|wc -l
1
通过以下方式查询tag values的数量：
influx -database 'cloudportal' -execute 'SHOW TAG VALUES FROM six_months.collapsar_flow WITH KEY = dip' -format 'csv'|wc -l
1
数量是否合适可以参考以下标准：
机器配置
| 类型 | CPU | RAM | OPS |
|---|---|---|---|
| Low | 2-4 cores | 2-4G | 500 |
| Moderate | 4-6 cores | 8-32G | 500-1000 |
| High | 8+ cores | 32+G | 1000+ |
配置对应的Series数量
| 机器配置 | 每秒写Field | 每秒查询数量 | Series数量 |
|---|---|---|---|
| Low | <5 K | <5 | <100k |
| Moderate | < 250 K | <25 | <1million |
| High | >250 K | >25 | >1million |
链接：//www.greatytc.com/p/133c56dd804f
来源：简书
每个模型一张表 ，40个基地，假设一个工厂600台设备，每个模型属性30个，序列基数40 * 600 * 30 = 720000
STD_AVI,siteCode=5103,devId=112,prop=VIN propValue=LECA3123908AD012 1465839830100400200
