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
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
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
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?
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
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:
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
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
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,