
InfluxDB 1.1: 60% performance increase and new query functionality - otoolep
https://www.influxdata.com/influxdb-1-1-released-with-up-to-60-performance-increase-and-new-query-functionality/
======
aorth
I wanted to try it, but the downloads page presents a popup asking for your
name and email address, and you cannot dismiss it.

[https://www.influxdata.com/downloads/](https://www.influxdata.com/downloads/)

~~~
reacharavindh
And what is wrong with it? Honestly curious.

~~~
aorth
I understand the tradeoff between them giving me free software and me giving
them my contact information—the way they've done it is just so up front and in
your face!

I'm pretty sure there is a web dev or user experience best practice about not
spamming your users with "subscribe to us" and "like us on Facebook" dialogs
immediately when they land on your page. And this one can't even be dismissed
unless you subscribe!

~~~
daenney
This is what I usually use sites like
[http://10minutemail.com](http://10minutemail.com) for.

~~~
skeptic2718
Or in this specific case, just enter garbage in the form.

------
ckdarby
Currently using internally for production level work. They need to spend
serious time making it easier to diagnose issues when they happen.

The log is simply not verbose enough and when I hit issues with telegram,
kapacitor and influxdb I have to open up a github issue having no idea what is
causing the issue.

Still highly recommended they just need to spend time making it easier to
identify common problems. It'll help reduce the number of github issues they
have opened too.

------
hbs
Performance usually varies greatly with your set up. I have not tried the 1.1
release but earlier relases suffered very badly when authentication was turned
on and when data came out of order. Nobody cares about the ideal case, it's
never encountered.

------
c2h5oh
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..

~~~
scrollaway
Sounds like you were using the wrong tool for the job. Influx is not for high
cardinality data.

~~~
hbs
The problem is the definition of high cardinality, the Gorilla paper talks
about 2B metrics at FB but the hardware sizing page for influx shows a scary
graph which basically kills any series cardinality above a million

[https://docs.influxdata.com/influxdb/v1.1/guides/hardware_si...](https://docs.influxdata.com/influxdb/v1.1/guides/hardware_sizing/)

quite a difference!

~~~
user5994461
InfluxData is a single server app with zero failover and zero sharding.

There is no "billion" metrics going in there. The architecture (or lack
thereof) is not intended for that.

You can try vertical scaling (if you're not in the cloud), you'll squeeze more
metrics until you overflow your network cards or your hard drives or your CPU.

------
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.

------
chrissnell
I'm looking forward to trying it out. I used it at home to build a live
weather site for my backyard weather station:
[https://mhkweather.com](https://mhkweather.com)

The performance went way down when I moved my DB from a ext4 SSD volume to a
four-disk ZFS magnetic volume. I expected some slowdown but not as much as I
saw. Looking forward to trying 1.1 to see if it improves things.

------
daenney
Can anyone verify the claims on their production setup? I'm always a bit weary
of these announcements. It's easier to get big numbers like that on benchmarks
than in real usage scenarios, has usually been my experience.

------
regecks
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 deprecated and disabled in this
> release

Ahh. I must be the only one using it, it gave kind of a good overview of all
your collections. A bit of a pain to do from Grafana but oh well.

~~~
pauldix
Before we actually remove the admin interface, we'll have a modern version of
it in the now OSS Chronograf. Basically moving that functionality to there so
we can iterate on the UI separately from the DB.

~~~
regecks
Cool. However, we're pretty settled on Grafana+InfluxDB and I'm not sure I
have any real reason to deploy Chronograf. We'll see though.

------
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.

~~~
daenney
> 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.

~~~
daenney
Oh, and about Go's (1.8) garbage collector:
[https://twitter.com/brianhatfield/status/804355831080751104](https://twitter.com/brianhatfield/status/804355831080751104).
I think it'll be alright.

------
betimd
Very good to hear that. Started to try influxdb as my tsdb for iot and looks
very promising.

------
otoolep
Nice work by the InfluxDB team.

