Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

InfluxDB 1.1: 60% performance increase and new query functionality

influxdata.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#11

Post by omn1 »

regecks wrote: post #6

Sweet. I had some 'getting oomkilled' problems with boundless queries back when I started using Influx for production early in the year, but it has been rock solid and performant since the later 0.1x releases. > Support for regular expressions on field keys in the SELECT clause. For example, SELECT /cpu_\d/ FROM cpu Woohoo! Very nice for making Grafana dashboards. > The admin UI (port 8083) is now officially deprecat…

You can use the cli client that comes with InfluxDB. It is both faster and (for me) less painless to use. The Admin Interface always felt like an afterthought to me that was not well supported.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#12

Post by omn1 »

zenlot wrote: post #9
CSDude wrote: post #7

Earlier quoted context omitted.

The admin UI was really good and they started to strip features away from it one by one and now it is disabled. It even could do simple graphs and was very useful for debugging.

That seems to be their uncommunicated plan - to attract users to open source version and then remove features to offer just with enterprise product. They have done it with clustering support where after attracting people with promises they then removed it from open source version. Grafana as a replacement? It really does different things.

That sounds a bit unfair to me. In the end it's a company and they need to earn money somehow. Clustering is a very hard problem that takes a lot of manpower to get right.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#13

Post by siscia »

I am wondering the choice of go as language to build a database.

I am a big fan of golang for some workload but the GC will kill performance in a database, wouldn't?

I am not being a brat I am seriously wondering how much GC affect the overall performance.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#14

Post by rakoo »

siscia wrote: post #13

I am wondering the choice of go as language to build a database. I am a big fan of golang for some workload but the GC will kill performance in a database, wouldn't? I am not being a brat I am seriously wondering how much GC affect the overall performance.

Then you should be happy that Go has been putting a lot of effort into making its GC as non-blocking as possible. There was an interesting blog post from Pusher yesterday (https://blog.pusher.com/golangs-real-time-gc-in-theory-and-p...) about how they had to learn how the GC works and how to make the most of it; the links give more information into golang's internal evolution.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#16

Post by maaaats »

siscia wrote: post #13

I am wondering the choice of go as language to build a database. I am a big fan of golang for some workload but the GC will kill performance in a database, wouldn't? I am not being a brat I am seriously wondering how much GC affect the overall performance.

> but the GC will kill performance in a database, wouldn't?

Why do you assume it would?

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#17

Post by daenney »

siscia wrote: post #13

I am wondering the choice of go as language to build a database. I am a big fan of golang for some workload but the GC will kill performance in a database, wouldn't? I am not being a brat I am seriously wondering how much GC affect the overall performance.

> I am a big fan of golang for some workload but the GC will kill performance in a database, wouldn't?

Cassandra and HSQLDB are written in Java for example which usually suffer from much larger GC collections/pauses (though you can read a book or two on the subject and tune it). So is Neo4j, a graph database. Or Datomic in Clojure (which runs on the JVM). Then there's Mnesia written in Erlang. A time series database, or a graph database, is quite different from a more general purpose database like Postgres/MySQL and means you need to consider different things.

GC isn't necessarily an issue for high throughput (read or write). A lot of it depends on how much pressure you're putting on the GC (this is true for any type of application). Being aware of how your chosen language's GC behaves paired with the (typical) usage/behaviour of your code is probably the more important thing to consider. Just because something is written in a language without a GC doesn't automatically make it performant either.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#18

Post by iurisilvio »

I don't have too much data (around 2 years and 500k data points.

I was about to move to another database, because a query to old data or long ranges just consumed all my machine resources for some minutes. I can't use grafana because their reads crashes the server when someone want a different query.

After the 1.1 upgrade, it is really fixed. I can query anything without worries.

Re: InfluxDB 1.1: 60% performance increase and new query functionality

#19

Post by scrollaway »

c2h5oh wrote: post #8

Tried using in production, failed really badly performance-wise (granted, it wasn't a good fit - cardinality was high). Replaced with PostgreSQL and I'm seeing 2+ orders of magnitude improvement on c4.large vs r4.8xlarge before..

Sounds like you were using the wrong tool for the job. Influx is not for high cardinality data.
Post reply on HN