【译】openTSDB详解之Metadata
本文译自：http://opentsdb.net/docs/build/html/user_guide/metadata.html
Metadata
opentsdb的主要目的是存储时间序列数据，并且允许有对数据的不同操作。然而，它（元数据）可以帮助我们知道TSDs中存储了什么类型的数据，并且提供了当与这些信息交互时所产生的一些上下文信息。openTSDB的metadata是关于data points的信息。其中大部分是用户可以配置的，从而与外部工具衔接的信息，这些工具包括：搜索引擎，问题追踪系统。这一章节将会描述一些可用的但不同的元数据，并且介绍它们可以被用来干什么。
译者注：【下面的这些：UIDMeta，TSMeta，Enabling MetaData，Annotation其实都是元数据】
UIDMeta
存储在openTSDB中的每个数据点至少有三个UIDs。一个是metric，并且至少有一个由tagk和tagv组成的tag对。当UIDs之中的的一个新名字进入系统，一个UniqueID将会被分配，正是如此，总是会有一个UID名和一个数字标志符对。
TSMeta
openTSDB中的每个时间序列由其metric UID和tag name/value UIDs【其实这里的metri UID 和 tag name/vale就是UIDs】所唯一确定，由每个UIDs和TSUIDs创建一个TSUID【原文Each timeseries in OpenTSDB is uniquely identified by the combination of it's metric UID and tag name/value UIDs,creating a TSUID as per UIDs and TSUIDs.】。当接收到一个新的时间序列时，一个TSMeta对象便被记录在tsdb-uid表的一行中，该行由TSUID唯一确定。meta对象包含一些不可变的字段，诸如：tsuid,metric,tags,lastReceived和创建的时间戳（反应了TSMeta第一次被接收时的时间）。另外，一些字段可以编辑，诸如：描述信息，注释等。详见链接：http://opentsdb.net/docs/build/html/api_http/uid/tsmeta.html
Enabling MetaData
如果你想在你的openTSDB启动时使用metadata，你必须显式的开启实时metadata跟踪或者使用CLI工具。根据对性能的影响不同，metadata有多种生成方式，所以你在生产中开启这些功能之前，请测试TSDs的影响。
以下两个是可用的，按照影响从小到大的顺序排序：
tsd.core.meta.enable_realtime_uid:当这个属性开启时，任何时候，一个新的metric，tag name或是tag value将会被分配一个UID。会产生一个UIDMeta对象，并且可将其发送给已配置的搜索插件。因为UIDs不经常被分配，这个设置对性能不会产生太大的影响。tsd.core.meta.enable_realtime_ts:当和tsd.core.meta.enable_tsuid_incrementing或者tsd.core.meta.enable_tsuid_tracking一起开启的时候，一个新的时间序列到达的时候，一个计数器或是标识将会被标记在meta表中。注释：确认开启以下设置之一，否则metadata不会被实时跟踪。
tsd.core.meta.enable_tsuid_tracking:当其开启，每次一个时间点会被记录下来，1以及时间序列的时间戳将会被写进tsdb-meta表中。开启这个设置将会产生两倍的puts数量【一个是1，一个是时间戳】到内存中，或许要求更多的堆内存。例如：一个单TSD服务器可承受每秒6000个数据点，大约2GB的堆内存。tsd.core.meta.enable_tsuid_incrementing：当这个设置开启时，写入的每个数据点都将在tsdb-meta表中增加对应于数据点所属的时间序列的计数器。因为每个数据点发出一个增加请求，这将在TSD中产生一个巨大的负载并且很快的压缩堆空间，所以仅当你能够在大型TSDs中实现负载均衡，或者是你的写入数据量非常小时才可以开启此设置。开启incrementing(指的是：tsd.core.meta.enable_tsuid_incrementing)选项将会覆写tsd.core.meta.enable_tsuid_tracking设置。例如：在单个TSD节点（必须）有能力接收每秒3000个数据点，大约6GB堆内存。
Warning
当你开启任何实时元数据设置时，当心你的JVM堆使用。同时你也需要当心存储服务器，因为写流量可能会增加为2-3倍。
假设在metadata之前被写入到硬盘时，一个TSD崩溃了；或者你不想开启实时跟踪功能，你可以周期性地使用uid CLI工具并且用metasync子命令去产生丢失的UIDMeta和TSMeta对象。详见：http://opentsdb.net/docs/build/html/user_guide/cli/uid.html
Annotations
**metadata的另一种形式就是annotation。**annotation是简单的对象，这个对象与时间戳相对应。Annotations可以看做是一个非常基础的记录事件的方法。但是它们（指annotation）并非意想成为一个时间管理或问题追踪系统。相反，它们被使用在连接时间序列和外部系统中。
Every annotation is associated with a start timestamp. This determines where the note is stored in the backend and may be the start of an event with a beginning and end, or just used to record a note at a specific point in time. Optionally an end timestamp can be set if the note represents a time span, such as an issue that was resolved some time after the start.
每个annotation与一个开始时间戳相关。这决定了note将会存储在后端中的哪里【and may be the start of an event with a beginning and end】,或者仅仅用于记录一个note在一个特殊的时间点里。可选的是，一个结束的时间戳能够设置；如果note代表一个时间跨度，诸如：一个问题在开始之后得到了解决。
另外，一个annotation由一个TSUID定义。如果TSUID域被设置为一个有效的TSUID，annotation将会被存储，与ID定义的时间戳相关联。这意味着：当创建一个查询时，任何和请求时间戳一起存储的annotation将会被检索，并且，有选择的返回给用户。这些annotations被认为是local。(These annotations are considered "local".)
如果TSUID为空，annotation将会被认为是一个global注释；（这个global annotation）可能与系统中所有时间序列相关联。当查询时，用户可以指定全局的annotation去和查询中的时间域匹配。这些注释将会同本地annotation返回。 (These notes will then be returned along with "local" annotations.)
annotation应该有一个简单的描述，限制在25个字符之内，因为注释可能出现在图形中。如果请求的时间间隔有许多annotation，那么图形将会变得被注释填满。用户接口能让用户选择一个annotation去检索更加细致的数据。这些细节可能包含冗长的notes以及一个经典的key/value对。
用户可以通过Http API添加，编辑以及删除annotations。详见../api_http/annotation。
如下是一个带有annotation 标记的Gnuplot图形例子。注意在图形中显示的是一个蓝色的线代表的是唯一的描述信息：start_time。只有start_time出现在图形中。
