监控系统之数据存储
关于监控数据的存储问题，是一个典型的大数据存储的例子，
系统设计的时候的一个很重要的的工作的就是容量规划
至少有如下几点需要严谨的测算
1 整个系统需要面临的流量压力： QPS ，网络流量等
2 需要存储的数据量：每天新增的数据量，稳定的总数据量
3 最常用的查询方式
进而需要根据测算的结果决定：
1 需要的服务器数量，系统的数据流向
2 需要多少的存储空间，用什么来存储数据
3 是否需要关系型数据库
监控系统 流量估算：
--QPS （Query Per Second）
监控系统中主要的QPS压力来自部署在每个机器上的监控agent，假设为了保证监控报警的及时性。
我们每台机器5s向上游传输一次监控数据，假设公司虚拟机1000台那么产生的QPS大约是：
1000/5 = 200（QPS）
这样的压力还是可以用单台服务器承载的
--网络流量
我们假设：每个监控项占用16个Bytes，一共50个监控项，我们都存储在一行，那么网络流量大约是
16*50*200 = 16000（Bps） 约等于160（KBps） = 1.28 (Mbps)
依旧是单台服务器能够承载的
监控系统的数据量估算
每天新增的数据量：
根据上次估算，一天下产生的数据行数为：
200*（24*3600） = 17280000 约等于 1700万行
产生的数据量大约是：
16 * 50*17280000 = 13824000000 约等于 13GB
稳定的数据量
一般的情况下：我们比价关注的是7天之内的监控数据，更久远的数据为们可以另外归档到一个冷数据库，而7天的数据量为
17280000 * 7 = 120 960 000 约等于1.2亿行
数据量：
13 824000000 * 7 = 96768 000 000 约等于96.8G
最常用查询方式：
监控的数据直接没有什么直接的关联关系，查询的场景往往是限定机器，监控项，时间段
一次查询放回的数据量可能会比较大
综合上面的估算和分析，监控数据存储即可以使用传统性的关系型数据库，也可以使用key-value数据库
key-Value 数据库能做，MySQL也能做，大多数性能更好，可靠性更高。
这里我们必须要明白，MySQL的纯QPS性能不如redis不是由于MySQL的实现或者算法有问题。而是MySQL定位是数据库
redis定位是缓存，所以Mysql需要保证每条数据的更改尽可能的进行持久化，而redis没有保证这一点，持久化就意味着
数据需要落在硬盘上才能给用户返回成功。保证这一点就会造成很多损失，对于一个数据库来说，这些损失也是必要的
MySQL通过拆库，拆表是可以应对任意多的数据量的，但是有一个前提就是需要提前规划，而且很难做到客户端透明，
但是对于我们监控数据的存储，这完全是可以消化的。