pauldix

75 ms·

331.
by pauldix 11y ago
InfluxDB CEO here. Happy to answer any questions!
332.
InfluxDB v0.9.0 released with developer and production support available(influxdb.com)
16 points by pauldix 11y ago|6 comments
333.
by pauldix 11y ago
That should be doable if you're batching data together. The next build will actually do this automatically for you if you're writing into the Graphite, CollectD, or UDP inputs. It buffers some updates in memory to batch them in a
334.
by pauldix 11y ago
The Go client has already been updated. We'll be updating the Ruby and front end JS client. Hopefully the community will jump on updating the other clients once we release 0.9.0. It's a super simple protocol so I don't imagin
335.
by pauldix 11y ago
hasn't been measured yet. That'll come in mid-to-late summer after we've released 0.9.1 or 0.9.2. Also, on the 0.9.2 or 0.9.3 release cycle we're going to start work on a new storage engine that is custom built for this
336.
by pauldix 11y ago
Can it be called a pure AP system if a long running network partition can cause it to become unavailable? In our case, shard groups are part of the data that is in the CP system. We create these ahead of time, but those are what we use to d
337.
by pauldix 11y ago
We don't have those recommendations at the moment. We'll be putting that out over the next few months after we release 0.9.0 and some point releases after that. Out of curiosity, how many metrics are you tracking in Graphite? What
338.
by pauldix 11y ago
In your example I'd probably have the direction in the measurement name. e.g. { "name": "network_bytesin", "tags": {"host" "example.com"}, "fields": {"value":
339.
by pauldix 11y ago
Analytics are usually based on aggregating discreet events. It's based on irregular time series. Metrics and sensor data are usually regular time series. That is, series where you have samples taken at regular intervals of time, like o
340.
by pauldix 11y ago
That's fine too. However, queries by default set an end time of "now" on the server. So depending on how far in the future the point is, it may not show up in a query that doesn't have the end time explicitly specified t
341.
by pauldix 11y ago
The new model combines tags, which are indexed, with fields, which are not indexed. A measurement can have up to 255 different fields, all of which can be written for a single data point. As we push things forward we'll be adding more
342.
by pauldix 11y ago
That's why later on we'll be adding per query request consistency levels. For now, we're focused on the AP use case where you don't need an absolute guarantee.
343.
by pauldix 11y ago
This is the third Raft implementation for us. The original was goraft, then we attempted to make our own streaming raft implementation for high throughput. This time around we realized we should only put very low write throughput stuff thro
344.
by pauldix 11y ago
Timestamps should mostly be supplied by the client. They can be present or in the past, it doesn't matter. If a write succeeds only partially, it will most likely be replicated up to the other servers (and thus be consistent) by the hi
345.
by pauldix 11y ago
They could have an out of date view of the cluster. Like which databases exist, or which servers exist. However, those cases are fine. If a database was created and a server doesn't have a copy of it. When a write comes in it'll b
346.
by pauldix 11y ago
Each of those continuous query data points would be an insert. I guess if you're recalculating it frequently, those new points would be updates, however, under non-failure conditions that won't be a problem. If failure conditions
347.
by pauldix 11y ago
This is purpose built for this use case. The MapReduce system you talk about is part of what's built in. Each aggregate function in the query language is represented as a MapReduce job that gets run on the fly. The other part of it is
348.
by pauldix 11y ago
InfluxDB CEO and post author here. I'd love to hear feedback and answer any questions.
349.
InfluxDB Clustering Design – Neither CP or AP(influxdb.com)
110 points by pauldix 11y ago|51 comments
350.
by pauldix 12y ago
One of the key goals of the project is to be able to aggregate and downsample from raw high precision data. That means we want a framework in which we ship the code to where the data lives, not the other way around. The abstractions I'
351.
by pauldix 12y ago
Cool, I'll have to take a look at that talk. We've had people ask about backfilling large amounts of data so it's something we'll have to figure out.
352.
by pauldix 12y ago
thanks Mike!
353.
by pauldix 12y ago
Thanks, we're working hard on getting the clustering features complete so we have a real answer for HA, failover, and scalability (up to a point based on current design). For logfile rotation our recommended solution is to use logrotat
354.
by pauldix 12y ago
Hi Grisha, I saw that post, thanks for writing it! The coming features you're talking about are the work we're focused on for finishing this release. The three you mention should drop in an RC within two weeks. The distributed que
355.
by pauldix 12y ago
We have, but sadly not in Denver... yet ;)
356.
by pauldix 12y ago
We haven't built the migration tool yet, but mostly likely it will involve running a new version in parallel with the old version while the upgrade runs. For a guide on how to design your schema for a clean migration see here: http:&#
357.
by pauldix 12y ago
Hi Shane, thanks for the encouragement and sorry you're having a few problems with the current 0.8.8 release. We're heads down working on 0.9.0 and won't be doing any more releases in the 0.8.x line (except to create a migrat
358.
by pauldix 12y ago
We're busy at work on the production ready version. We're targeting March, but we won't release until it's ready (even if that means slipping our target). Remember, in software development there are lies, damn lies, and
359.
by pauldix 12y ago
Thanks Eric!
360.
by pauldix 12y ago
Would love to hear feedback from everyone on the new API. Let us know!

More ›