pauldix

21 ms·

271.
by pauldix 11y ago
The current version still has the problem that if you do a massive SELECT then it will fill up memory until the process gets killed. In the future we'll give controls to limit how much memory a query can take. I think it's common
272.
by pauldix 11y ago
We don't have the TCP listener wired up yet, but it's on the roadmap. Thanks for bringing it up, I'll try to get it prioritized for sometime in the next few months.
273.
by pauldix 11y ago
If you found something else that works for you, that's great. I'm sorry that InfluxDB didn't work for you when you tried it, but we'll continue to improve and build. My feeling is that this release is a significant miles
274.
by pauldix 11y ago
I disappeared because I can't spend all evening responding to every person on the internet that may be having trouble with our software. An offer to SSH into a system that isn't running Influx and trying to troubleshoot some ambig
275.
by pauldix 11y ago
I'm not quite sure what you're doing. If you have that level of hardware I don't know why you're running out of memory. Our tests with 100B points split across 1M series ran on much more modest hardware than that and did
276.
by pauldix 11y ago
We just have to close those out. Those are all fixed in the release we have today.
277.
by pauldix 11y ago
Not sure what issues you're seeing, but we have people running this in production at significant scale. One of the issues you linked to was for 0.9.6. Others were there because they had super high tag cardinality and not enough memory
278.
by pauldix 11y ago
InfluxDB supports timestamps down to the nanosecond. We recommend that you only use the precision you need, since you'll get better compression that way.
279.
by pauldix 11y ago
Have a look at this release. The write performance is massively better than it was. We did tests writing up to 100B points against a single server. The next release will focus on improving query performance, but this one still works for man
280.
by pauldix 11y ago
Am I correct in assuming that you got to the 20MB/sec number by taking our 3 bytes per point number times the number of data points? The input is actually much higher than that. Data points over the network look like this: cpu_idle,hos
281.
by pauldix 11y ago
Thanks :). He talks about doing kill nines on the process while doing a bunch of writes, trying to corrupt the DB, and perf testing. In addition to a little bit of talk about what came before and some lessons learned.
282.
by pauldix 11y ago
fsyncs happen on every write. They're durable. This release may be 100x faster than our previous release, but it's also a competitor with other solutions. We haven't run any comparisons vs. other solutions, but we will do tha
283.
InfluxDB v0.10 GA with hundreds of thousands writes/sec, 98% better compression(influxdata.com)
152 points by pauldix 11y ago|75 comments
284.
by pauldix 11y ago
It is, written in Go.
285.
Kapacitor v0.10.0 with support for custom functions and dead man's switch(influxdata.com)
12 points by pauldix 11y ago|4 comments
286.
by pauldix 11y ago
Yeah, histograms need to be added back in. I just replied to the other poster with a bit more info too. derivative and non_negative_derivative are in the current release. Hopefully 0.10.0 will convince you to come back over :)
287.
by pauldix 11y ago
Ok thanks. Hopefully we'll be able to get to those soon. We have some significant work happening in the query engine that should make it easier to add in new functions (join included). We'll also be writing up instructions for how
288.
by pauldix 11y ago
DELTE FROM hasn't been wired up yet: https://github.com/influxdb/influxdb/issues/1647 Unfortunately, we were passing that through to the DB which was causing problems. The current release 0.9.6 will retu
289.
by pauldix 11y ago
We're actively hiring for database engineers right now. Backups are coming in the next release. Which features from 0.8 aren't there? TSM is an effort, but not never ending. We just refuse to put it out there until we've done
290.
by pauldix 11y ago
I think it's similar because you're building graphs for a dashboard. Most of those UIs I've seen end up looking very similar. Our longer term goal with Chronograf is that it'll help with doing ad-hoc data exploration and
291.
by pauldix 11y ago
InfluxDB is designed to either store data for some given period of time (a retention policy) or forever, whichever you need. The ephemeral nature of time series is more about the fact that metadata and the raw data are constantly changing.
292.
by pauldix 11y ago
thanks!
293.
by pauldix 11y ago
We didn't fork Grafana. Chronograf is a completely new product built from the ground up. They don't use the same JavaScript technologies. Chronograf uses React and Dygraphs. I believe Grafana uses Angular and Flot. We're fans
294.
by pauldix 11y ago
I did see the time series announcement from Basho and will follow it with interest :) How are they moving to be a data platform company?
295.
by pauldix 11y ago
Thanks! We'll definitely be open sourcing some things from Chronograf and it's free to use. We removed the registration part of it with the release we cut today. We're fans of Bosun and actually contributed code to the projec
296.
InfluxDB is now InfluxData, a platform for time series data(influxdata.com)
124 points by pauldix 11y ago|36 comments
297.
InfluxDB v0.9.6 is out with a big update to the TSM storage engine(influxdata.com)
12 points by pauldix 11y ago|0 comments
298.
Time Structured Merge Tree: From LSM Tree to B+Tree and Back Again(influxdb.com)
97 points by pauldix 11y ago|28 comments
299.
by pauldix 11y ago
Things are actually about to get dramatically better for InfluxDB: https://influxdb.com/blog/2015/10/07/the_new_influxdb_storag...
300.
The New InfluxDB Storage Engine: A Time Structured Merge Tree(influxdb.com)
12 points by pauldix 11y ago|4 comments

More ›