时序数据库

之前已经介绍过,ES 默认存储数据时,是有索引数据、_all 全文索引数据、_source JSON 字符串三份的。其中,索引数据由于倒排索引的结构,压缩比非常高。因此,在某些特定环境和需求下,可以只保留索引数据,以极小的容量代价,换取 ES 灵活的数据结构和聚合统计功能。

在监控系统中,对监控项和监控数据的设计一般是这样:

metric_path value timestamp (Graphite 设计) { "host": "Host name 1", "key": "item_key", "value": "33", "clock": 1381482894 } (Zabbix 设计)

这些设计有个共同点,数据是二维平面的。以最简单的访问请求状态监控为例,一次请求,可能转换出来的 metric_path 或者说 key 就有:{city,isp,host,upstream}.{urlpath...}.{status,rt,ut,size,speed} 这么多种。假设 urlpath 有 1000 个,就是 20000 个组合。意味着需要发送 20000 条数据,做 20000 次存储。

而在 ES 里,这就是实实在在 1000 条日志。而且在多条日志的时候,因为词元的相对固定,压缩比还会更高。所以,使用 ES 来做时序监控数据的存储和查询,是完全可行的办法。

对时序数据,关键就是定义缩减数据重复。template 示例如下:

{
  "order" : 2,
  "template" : "logstash-monit-*",
  "settings" : {
  },
  "mappings" : {
    "_default_" : {
      "_source" : {
        "enabled" : false
      },
      "_all" : {
        "enabled" : false
      }
    }
  },
  "aliases" : { }
}

如果有些字段,是完全不用 Query ,只参加 Aggregation 的,还可以设置:

      "properties" : {
        "sid" : {
          "index" : "no",
          "type" : "keyword"
        }
      },

关于 Elasticsearch 用作 rrd 用途,与 MongoDB 等其他工具的性能测试与对比,可以阅读腾讯工程师写的系列文章:http://segmentfault.com/a/1190000002690600

Last updated