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/

Not only that, they ask for your work email address. I'm only using InfluxDB for my home dashboard (raspi, some sensors, etc.) so I just went with "[email protected]" instead.

It's OK; their email validation is borked (just put in anything matching `\w@\w`, no domain necessary) and give something random for the name. Modals like that are pretty standard practice for enterprise mumbo jumbo; they only need to catch someone foolish enough to put in real data once to be worthwhile.

Arguably, that's as correct a way as any for validation for email.

http://www.regular-expressions.info/email.html

> Don't go overboard in trying to eliminate invalid email addresses with your regular expression. The reason is that you don't really know whether an address is valid until you try to send an email to it. And even that might not be enough.

I find it even more sad when in the meantime, the button named "Learn more" on the same page doesn't link to a valid page (as https://www.influxdata.com/pricing leads to a 404).

To improve the "conversion", it would be a way better way to fix that link instead of forcing me to use the Web Inspector to remove a rude modal dialog…

That should be getting changed to have a dismiss x on the upper right. TBH I thought it had been done already. Overly aggressive marketing department...

Are you blaming your own marketing team? Take responsibility.

Granted, they don't have a link to the GitHub page on the blog post itself, but it's open source software.

https://github.com/influxdata/influxdb/releases

Yes, it's annoying.

But honestly, if a person won't share contact information in exchange for the fruits of thousands of hours of someone's labor then they don't have much of a need for it and the creators probably aren't missing them.

And what is wrong with it? Honestly curious.

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!

This is what I usually use sites like http://10minutemail.com for.

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

As far as I'm concerned I shouldn't have to give up my contact details in order to download FOSS software.

Thankfully in this case I can just go build the thing myself but these kind of sign up walls without a way to opt out of them do annoy me.

Yes, you could build the thing yourself.

I'm all for protecting privacy, but, Don't you think it is reasonable for a FOSS project/company to collect basic stats on their audience? They aren't even forcing you to give up your identity. Just an email address, which could be something that don't particularly identify you, while they get unique user stats. You could obviously mark them as Spam, if they do end up spamming you..

Whenever I see 'valid work email address' on a form I assume I'm going to get harassed by sales people.

Definitely what influx does. I feel like I get an email from them at least every week.

I have no issue with them collecting basic stats. I'm contributing to the statistics Homebrew collects and when Django gets their statistics I will keep them enabled or opt-in.

However, I should be allowed to opt out. I also don't consider my (work) email address to be meaningful data they can use to improve the quality of their software or gain an understanding of how it's being used. At best I can see them deduping download counts through it which can be done in other ways.

"Don't you think it is reasonable for a FOSS project/company to collect basic stats on their audience?"

No. That is not free, that is paying for it with your privacy.

Wow. What a deal breaker. I'm not giving you my information just to try something I don't even know if I like. This is software. It's not like test driving a car where it could cost you money if I stole it.

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.

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.

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

In the same boat. I tried Druid as well which was almost a better solution but lacked the flexibility and maturity.

We are using Postgres + citus + some HLL. Our success is probably because we just have a lot more experience with Postgres.

I still haven't tried HBase though.

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

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

quite a difference!

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

The admin UI functionality is getting moved over to Chronograf, which is now open source. We do have commercial stuff, but trying to make money off our UI was never a strategy.

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.

They do deserve to be paid for their product, yes. And it's worth paying for.

They ill will was also deserved though, because when they changed business plans to exclude more features from the community version, they surprised and angered many users. Bait and switch is what got communicated, and trust violated, forcing projects to seek alternatives or modify their budgets.

This can be avoided by clearly communicating the roadmap of community vs enterprise features and sticking to it. But don't keep danging new features in free and then remove them unexpectedly.

I'm using it too! I find it really useful for experimenting with queries before I set them up in grafana.

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.

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

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.

If you are careful and measure you can get consistent performance. We do lots of measurement of GC pauses for etcd and have it in a really tight band by ensuring we don't needlessly generate garbage in the hot path.

Here is our measurement dashboard for a functional test cluster: http://dash.etcd.io/dashboard/db/functional-tests?from=now-2...

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

Why do you assume it would?

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

Nice work by the InfluxDB team.