{"action":"created","issue":{"url":"https://api.github.com/repos/influxdb/influxdb/issues/3445","labels_url":"https://api.github.com/repos/influxdb/influxdb/issues/3445/labels{/name}","comments_url":"https://api.github.com/repos/influxdb/influxdb/issues/3445/comments","events_url":"https://api.github.com/repos/influxdb/influxdb/issues/3445/events","html_url":"https://github.com/influxdb/influxdb/issues/3445","id":96820048,"number":3445,"title":"[Feature Request] Metadata of Tags","user":{"login":"KrishnaPG","id":4610831,"avatar_url":"https://avatars.githubusercontent.com/u/4610831?v=3","gravatar_id":"","url":"https://api.github.com/users/KrishnaPG","html_url":"https://github.com/KrishnaPG","followers_url":"https://api.github.com/users/KrishnaPG/followers","following_url":"https://api.github.com/users/KrishnaPG/following{/other_user}","gists_url":"https://api.github.com/users/KrishnaPG/gists{/gist_id}","starred_url":"https://api.github.com/users/KrishnaPG/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/KrishnaPG/subscriptions","organizations_url":"https://api.github.com/users/KrishnaPG/orgs","repos_url":"https://api.github.com/users/KrishnaPG/repos","events_url":"https://api.github.com/users/KrishnaPG/events{/privacy}","received_events_url":"https://api.github.com/users/KrishnaPG/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-07-23T13:51:31Z","updated_at":"2015-07-24T16:46:55Z","closed_at":"2015-07-23T18:34:01Z","body":"The features of tags looks promising. However as others indicated in this issue (https://github.com/influxdb/influxdb/issues/373) there are few questions / concerns - and appreciate it if someone could address these below:\r\n\r\nThe requirement is: consider the `cpu series` where each `host` has additional info (apart from its traditional name) as below:\r\n*    ipv4 address\r\n*    ipv6 addresses\r\n*   the data center address (city / county / country so on..) etc.\r\n\r\nNow, it is not clear how to specify this additional info for the host tag.\r\n*   Obviously this info need to be set just once and we cannot and (will not perhaps) send it with every measurement\r\n\r\nUsing all these dependent info as separate tags will not be the right way. Since it is pure metadata about the tags.\r\n\r\nWe usually send only the hostname with every measurement (as show in the example [here](https://influxdb.com/blog/2015/02/24/influxdb-v0_9_0-rc4_released_now_with_tags_and_more_unicorns.html)), but need to retain the meta info about that hostname tag somewhere in the db so that it can be accessed (e.g. present in the ui) when needed.\r\n\r\nRight now, it looks like I have to use some other db (such as mysql) to store this meta info about the tags, which is not really good idea.\r\n\r\nIf some solutions already exists for this with in Influxdb itself, please share it. Else, it would be great if this situation is addressed.\r\n"},"comment":{"url":"https://api.github.com/repos/influxdb/influxdb/issues/comments/124576657","html_url":"https://github.com/influxdb/influxdb/issues/3445#issuecomment-124576657","issue_url":"https://api.github.com/repos/influxdb/influxdb/issues/3445","id":124576657,"user":{"login":"beckettsean","id":6537329,"avatar_url":"https://avatars.githubusercontent.com/u/6537329?v=3","gravatar_id":"","url":"https://api.github.com/users/beckettsean","html_url":"https://github.com/beckettsean","followers_url":"https://api.github.com/users/beckettsean/followers","following_url":"https://api.github.com/users/beckettsean/following{/other_user}","gists_url":"https://api.github.com/users/beckettsean/gists{/gist_id}","starred_url":"https://api.github.com/users/beckettsean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/beckettsean/subscriptions","organizations_url":"https://api.github.com/users/beckettsean/orgs","repos_url":"https://api.github.com/users/beckettsean/repos","events_url":"https://api.github.com/users/beckettsean/events{/privacy}","received_events_url":"https://api.github.com/users/beckettsean/received_events","type":"User","site_admin":false},"created_at":"2015-07-24T16:46:55Z","updated_at":"2015-07-24T16:46:55Z","body":"@KrishnaPG I can understand why you would want InfluxDB to manage all the metadata about all your samples, but the performance gains depend on not replicating every feature of a traditional RDBMS. Metadata about the metadata adds a whole new tabular structure and index to the database, as well as adding complexity and correctness checking during the write path. While those features might eventually make it into InfluxDB it won't be for a long time.\r\n\r\nMeanwhile, using a traditional RDBMS is the better way to solve this issue. The data from the two can be joined client-side to represent the full picture.\r\n\r\n> I am not sure how telegraf does this (is it transparently supplying all the parameters always? and does it support changing the tags metainfo?). \r\n\r\nTelegraf sends all metadata with every point. The tags sent can be changed by altering the telegraf config file, but there is no historical modification of data. Telegraf is a wrapper for efficiently injecting points into InfluxDB. It does nothing but smooth the write path.\r\n\r\n> And I do not think presently InfluxDB allows changing old tags either (which, BTW is right approach).\r\n\r\nCorrect. Old data can be overwritten, but this is assumed not to happen very often.\r\n\r\n> Given that the primary interface of Influxdb is REST/HTTP api, I do not think supplying all the tag's meta-info always is really a wise idea. \r\n\r\nIt's not RESTful, but it is HTTP. A binary protocol will come with the 1.x family to add performance but not 0.9. I'm not sure that adding another 30-50 bytes to each HTTP call will lead to significant issues. There's no change in the on-disk representation, it's just a bit more HTTP on the wire. The write performance of InfluxDB won't be significantly affected, and if you have sensors where sending an extra few bytes is painful, a general purpose TSDB optimized for ease of use might not be the right product. If you prefer, use UDP to eliminate the REQ and ACK traffic. It sounds like you really want a more tunable system, which InfluxDB will eventually become, but for now ease of use trumps edge case performance."}}