Re: [influxdb] Measurement Schema Design

2016-09-30 Thread Sean Beckett
On Fri, Sep 30, 2016 at 9:50 AM, Sean Fitts wrote: > Sean, hi. > > Thanks for the responses. If you have the time I have some follow-ups > below... > > On Thursday, September 29, 2016 at 8:25:23 PM UTC-7, Sean Beckett wrote: >> >> For multi-tenant my first thought is each tenant gets their own d

Re: [influxdb] Measurement Schema Design

2016-09-30 Thread Sean Fitts
Sean, hi. Thanks for the responses. If you have the time I have some follow-ups below... On Thursday, September 29, 2016 at 8:25:23 PM UTC-7, Sean Beckett wrote: > > For multi-tenant my first thought is each tenant gets their own database. > It does lead to significant series duplication, but

Re: [influxdb] Measurement Schema Design

2016-09-29 Thread Sean Beckett
For multi-tenant my first thought is each tenant gets their own database. It does lead to significant series duplication, but it makes for performant add and remove tenant operations. If the cardinality gets too high, some databases can be backed up and restored into a new instance. Within the dat

Re: [influxdb] Measurement Schema Design

2016-09-29 Thread Sean Beckett
Correct. They cannot be joined in the database, but they can be queried simultaneously. The system will return independent results for all measurements queried. On Fri, Sep 23, 2016 at 7:48 AM, wrote: > > Interesting. Does this fact lead to most schemas consisting of a single > measurement?

Re: [influxdb] Measurement Schema Design

2016-09-23 Thread smfitts
Interesting. Does this fact lead to most schemas consisting of a single measurement? And just to be clear, the restriction is that you can't join between them in the DB itself, correct? Presumably you can issue queries against each so you can display them simultaneously (say in Grafana). Th

Re: [influxdb] Measurement Schema Design

2016-09-22 Thread Mathias Herberts
I would not use different measurements as InfluxDB does not allow you do to cross measurement analytics, so if you go the multi-measurements way you won't be able to crunch your storage metrics with your network ones if you used two different measurements. On Friday, September 23, 2016 at 2:42:

Re: [influxdb] Measurement Schema Design

2016-09-22 Thread smfitts
We are also in the process of figuring out how to store data for a multi-tenant system so this is very helpful. I have a couple of follow up questions along the similar lines (caveat -- we're very new to InfluxDB so I may have misused the terms). When thinking about our schema (ignoring tenan

Re: [influxdb] Measurement Schema Design

2016-08-19 Thread Sean Beckett
There's not much performance gain from segmenting the data. It will all live on the filesystem organized by time first, and series second. As long as your queries are bounded to particular times and series, the measurement schema won't make too much difference. However, DROP MEASUREMENT is more pe

[influxdb] Measurement Schema Design

2016-08-02 Thread ryan
Hi there, I'm not quite sure which schema design would be better and hoping someone could help: (1) Measurement = PageViews Tags = OrganisationId=XYZ, PageId=123 Values = BrowserAgent=Chrome, URL=test.com Measurement = Clicks Tags = OrganisationId=XYZ, PageId=123 Values = BrowserAgent=Chrome,