<story><title>Thoughts on Time-series Databases</title><url>http://jmoiron.net/blog/thoughts-on-timeseries-databases/</url></story><parent_chain><item><author>tsdbase</author><text>I&amp;#x27;ve hit the same problem and I would like to move back to a SQL data store. However none of the nice dashboards &amp;#x2F; visualizations support postgres or any SQL database (for now)...&lt;p&gt;My question (to everyone): what do you use as replacement for kibana or grafana?</text></item><item><author>Everlag</author><text>I actually just migrated 20 million rows of Magic: the Gathering price data from influxDB to postgres this week. For a few days of effort, I decreased my query latency by an order of a magnitude; a full set query, roughly 270 cards, went from 30 to 3 seconds with a cold cache.&lt;p&gt;The migration was prompted by influxDB 0.8 eating 50% of the VPS&amp;#x27; cpu and 77% of the ram while idling. It had no capability to index along anything but time so every query, for my use case, required a full table scan. 0.9 was supposed to fix every issue I had with it but it was due to be &amp;#x27;production ready&amp;#x27; months ago.&lt;p&gt;Unless you&amp;#x27;re dealing with ingesting an absolutely insane amount of data indexed along time, I&amp;#x27;d have to say that postgres or comparable sql database should be more comfortable, more stable, and much more mature.&lt;p&gt;EDIT: I don&amp;#x27;t want to come off as shitting all over influxDB, to its credit it barely moved beyond idle resource usage when I was stuffing it full of data.</text></item></parent_chain><comment><author>jrv</author><text>If you don&amp;#x27;t need to keep data forever, but only several weeks or months, and you only need numeric time series data and not raw event logs, Prometheus (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;&lt;/a&gt;) is your friend. Since it&amp;#x27;s optimized towards purely numeric time series (with arbitrary labeled dimensions), it currently uses an order of magnitude less disk space than InfluxDB for this use case, and I&amp;#x27;ve also heard a few reports of people&amp;#x27;s CPU+IO usage dropping drastically when they switched from InfluxDB to Prometheus for their metrics.&lt;p&gt;As dashboards for Prometheus, you can currently use PromDash (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;promdash&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;promdash&amp;#x2F;&lt;/a&gt;), Console HTML templates (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;consoles&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;consoles&amp;#x2F;&lt;/a&gt;), or Grafana (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;grafana&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;prometheus.io&amp;#x2F;docs&amp;#x2F;visualization&amp;#x2F;grafana&amp;#x2F;&lt;/a&gt;).&lt;p&gt;Durable long-term storage is still outstanding. Although replication into OpenTSDB and InfluxDB is experimentally there.</text></comment>
<story><title>Thoughts on Time-series Databases</title><url>http://jmoiron.net/blog/thoughts-on-timeseries-databases/</url></story><parent_chain><item><author>tsdbase</author><text>I&amp;#x27;ve hit the same problem and I would like to move back to a SQL data store. However none of the nice dashboards &amp;#x2F; visualizations support postgres or any SQL database (for now)...&lt;p&gt;My question (to everyone): what do you use as replacement for kibana or grafana?</text></item><item><author>Everlag</author><text>I actually just migrated 20 million rows of Magic: the Gathering price data from influxDB to postgres this week. For a few days of effort, I decreased my query latency by an order of a magnitude; a full set query, roughly 270 cards, went from 30 to 3 seconds with a cold cache.&lt;p&gt;The migration was prompted by influxDB 0.8 eating 50% of the VPS&amp;#x27; cpu and 77% of the ram while idling. It had no capability to index along anything but time so every query, for my use case, required a full table scan. 0.9 was supposed to fix every issue I had with it but it was due to be &amp;#x27;production ready&amp;#x27; months ago.&lt;p&gt;Unless you&amp;#x27;re dealing with ingesting an absolutely insane amount of data indexed along time, I&amp;#x27;d have to say that postgres or comparable sql database should be more comfortable, more stable, and much more mature.&lt;p&gt;EDIT: I don&amp;#x27;t want to come off as shitting all over influxDB, to its credit it barely moved beyond idle resource usage when I was stuffing it full of data.</text></item></parent_chain><comment><author>robochat</author><text>I&amp;#x27;ve just implemented a custom backend for graphite-api which seems to be working ok although I don&amp;#x27;t have crazy requirements. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;brutasse&amp;#x2F;graphite-api&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;brutasse&amp;#x2F;graphite-api&lt;/a&gt; is a cleaned up fork of graphite (which is much easier to install). I&amp;#x27;m using grafana as the front-end and my data is in a postgresql database and graphite-api is linking them together.</text></comment>