InfluxDB 1.1: 60% performance increase and new query functionality
influxdata.com
influxdata.com
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.
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…
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.
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!
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.
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..
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.
No. That is not free, that is paying for it with your privacy.
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.
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.
https://docs.influxdata.com/influxdb/v1.1/guides/hardware_si...
quite a difference!
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 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.
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.
> 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.
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 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.
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.
Here is our measurement dashboard for a functional test cluster: http://dash.etcd.io/dashboard/db/functional-tests?from=now-2...
Why do you assume it would?