什么是时序数据？
物联网诞生于1999年，在其理念和技术的不断革新下，无处不在的设备和设施正在被越来越多的通过网络连接起来，并不断向云端发送实况数据。
以国家级气象观测站为例，全国有近6万个气象观测站，每个气象观测站有70种气象物理量需要采集。某市地铁每列列车拥有3200个指标需要测量，全市列车数达300列。服务器运维监控中，一台服务器需要同时监测IOPS、CPU、网络等十余项指标。这些例子中展现出两个概念：设备与度量指标。所谓度量指标（又被称为工况、测点）是指用户关心的能反映目标的某种状况的数据项，例如CPU利用率、温度、湿度等等。设备是指一个拥有一系列度量指标的实体，例如一台服务器、一个进程、一列车、一个气象观测站等等。一个设备的一个度量指标形成了一条时序数据的唯一标识。
随着时间推移，这条时序数据会产生一系列（时间戳，值）的二元组数据点，构成了时间序列数据集。因此，我们定义一条时间序列是由一个时间序列标识（设备和度量指标），一系列时间戳和数据值对组成的无限集。一个时间序列数据库将管理百万甚至千万条这样的时间序列。
IoTDB 数据模型及手动创建方式
IoTDB 的元数据管理采用目录树的结构，不同层级之间用 . 分割。根节点默认为 root ，除此之外主要有三个概念。存储组、设备、测点。
手动创建存储组：
set storage group to root.FU01
手动创建时间序列：
create timeseries root.FU01.deviceType1.AZQ01.Temperature with datatype=FLOAT, encoding=GORILLA, compression=SNAPPY
设备不需要创建，当创建时间序列时会默认将倒数第二层当做设备。以上述时间序列为例，设备 ID 会被设置为root.FU01.deviceType1.AZQ01 。一个设备一个时间戳的多个测点值，最好一次同时写入，尽量避免乱序数据产生。
当创建足够多的时间序列后，元数据看起来就是下面这样一颗树了：
数据类型目前支持 6 种
BOOLEAN、INT32、INT64、FLOAT、DOUBLE、TEXT
编码方式主要有 4 种
TS_2DIFF （时间列的默认编码方式）：适用 INT32、INT64 RLE：适用 INT32、INT64、FLOAT、DOUBLE（对于 FLOAT 和 DOUBLE 是有损压缩，默认保留2位小数，可在配置文件中修改 float_precision） GORILLA：适用 FLOAT、DOUBLE PLAIN：全搭
压缩方式：
UNCOMPRESSED、SNAPPY（默认）
推荐建模方式
存储组：推荐10-50个左右，每个存储组是一个独立的存储引擎，增加存储组可增加写入并行度。
设备：推荐10万以下
总时间序列数（测点数）：推荐1000万以下
每条序列的数据条数没有限制。
正常负载下此建模方式没问题，如果系统提示系统负载过高，可将 enable_parameter_adapter 设置为 false，需要手动配置参数，防止爆内存，简单的规则为：
memtable_size_threshold=tsfile_size_threshold
= IoTDB分配内存/2/存储组个数/4 (有乱序数据)
= IoTDB分配内存/2/存储组个数/2 (无乱序数据)
IoTDB 分配内存在 conf/iotdb-env.sh 中设置 MAX_HEAP_SIZE。 配置文件在 conf/iotdb-engine.properties。
推荐负载按这个调大多没问题，负载再高可以联系我们，这个手动调整参数在 0.11 版本就会去掉，解放生产力！
一个方法判断有无乱序：只要每个设备写入时间戳都是递增的，就没乱序数据，否则都可能产生乱序数据。
举个例子：设备 root.turbine.d1 有三个测点 s1, s2, s3
# 无乱序数据 insert into root.turbine.d1(timestamp,s1,s2,s3) values(1,1,2,3); insert into root.turbine.d1(timestamp,s1,s2,s3) values(2,1,2,3); # 时间戳先写 2，再写 1，可能有乱序数据 insert into root.turbine.d1(timestamp,s1,s2,s3) values(2,1,2,3); insert into root.turbine.d1(timestamp,s1,s2,s3) values(1,1,2,3); # 时间戳先写 1，再写 1，虽然是不同测点，但还属于一个设备，可能有乱序数据 insert into root.turbine.d1(timestamp,s1,s2) values(1,1,2); insert into root.turbine.d1(timestamp,s3) values(1,3);
自动创建元数据模式
除了手动创建元数据的方式，还支持自动创建元数据，自动创建元数据是在数据写入的过程进行的。主要针对提前不知道序列总数，实时消费消息队列进行写入的场景，代码中就不需要每条数据都创建序列了。
当我们对一条时间序列写入数据时，会首先检查其存储组是否存在，如果不存在会自动创建。我们把 root 定义为第 0 层，存储组默认是第一层，也就是 root 下的一层，可在配置文件中修改默认创建的层级 default_storage_group_level。
自动创建的数据类型是根据写入值的类型自动推断出来的。假如传入的是字符串格式的数据，即用 JDBC 的 insert 语句写入，或者 Session 中值类型为 String 的 insertRecord(s) 接口写入，会根据值的格式来判断，主要有四种格式的字符串，以及默认类型：
不带 . 的整数：如 123 => FLOAT 带 . 的浮点数：如 12.34 => FLOAT 布尔型：true，false => BOOLEAN 其他类型：abc，124sa => TEXT
对于前 3 种格式的字符串的默认类型，都可以在配置文件中配置，（0.10.0 版本，目前的 master 分支， boolean_string_infer_type 参数附近）
简单试用
脚本默认前台，需要手动后台启动，
nohup ./sbin/start-server.sh >/dev/null 2>&1 &
接下来可以启动 Cli 命令行:
./sbin/start-client.sh -h 127.0.0.1 -p 6667 -u root -pw root or ./sbin/start-client.sh （默认用root连接本机）
在 0.10.0 版本中，即将改名为 start-cli.sh
总结
今天主要介绍 IoTDB 的数据模型，快速启动，推荐建模方式，手动调参小技巧，以及动态创建元数据相关的知识。下一节会介绍 IoTDB 的基本 SQL 查询功能。
