Your schema seems fine as long as the assetID count doesn't get too high.
Above 1 million unique series or so InfluxDB schemas need to be well tuned.

Using multiple databases will lead to greater RAM needs and slightly
elevated disk usage. I wouldn't recommend it unless you frequently need to
evict a customer's data. DELETE or DROP SERIES is a relatively expensive
operation, but DROP DATABASE is pretty cheap.

On Sun, Oct 9, 2016 at 6:58 AM, <nodethirt...@gmail.com> wrote:

> Hi,
>
> I'm about to start a little project of mine where i think influxdb will be
> the centerpiece.
> What i'm going after is a way to store the servermetrics of a few
> thousands of servers that belongs to diffrent teams and customers.
> The endgame will be something along the lines of the following queries.
> 1) Select all servers for with a unique customer id for a brief overview
> with fresh data
> 2) Select all metrics for the server  (cpu,ram,disk,processes, IO etc.)
> 3) Select individual metrics per server (only fetch cpuload, and query it
> in different timeframes and resolutions with the help of CQ)
> 4) And probably a lot more.
>
> I'm thinking about storing all customer and team assets in the same fixed
> measurements
> A) ServerMetrics
> B) NetworkMetrics
> C) StorageMetrics
> Having the Tagkey assetid=[uuid of some sort] and customerid=[id of some
> sort] and all metrics as fields
>  'fields': {
>         'cpuload': 1.05,
>         'cpuused: 85,
>         'anothervalue': 3',
>         'memused': 5,
>         'memfree': 3,
>         'memtotal': 10,
>     }
>
> I will need to minimize the amount of series created per server i collect
> metrics for.
> At the same time i can afford myself being cheap so i will need to have a
> few CQ's for downsampling etc.
> Hardware will not really be an issue.
>
> I believe another option would be to separate teams/customers by letting
> them have their own database, but i'm not sure
> about the actual pros/cons of doing this,
>
> I'm trying to read through the docs but i fail to really understand what i
> should do in my scenario.
> Once things start to grow i plan on switching to a clustered influxdb
> setup.
>
> InfluxDB seems like a master of timeseries, it would be so great if i
> could use it.
> Will i be able to do the things i'm thinking about or am i way of the
> chart ?
> Would anyone mind commenting on my thoughts?
> And perhaps suggest schemadesign if what i'm trying to achieve is not
> doable.
>
> Sincerly
> Daniel Olsson
>
> --
> Remember to include the InfluxDB version number with all issue reports
> ---
> You received this message because you are subscribed to the Google Groups
> "InfluxDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to influxdb+unsubscr...@googlegroups.com.
> To post to this group, send email to influxdb@googlegroups.com.
> Visit this group at https://groups.google.com/group/influxdb.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/influxdb/15d5cd60-25f4-4f68-8692-84c484b1076f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Sean Beckett
Director of Support and Professional Services
InfluxDB

-- 
Remember to include the version number!
--- 
You received this message because you are subscribed to the Google Groups 
"InfluxData" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to influxdb+unsubscr...@googlegroups.com.
To post to this group, send email to influxdb@googlegroups.com.
Visit this group at https://groups.google.com/group/influxdb.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/influxdb/CALGqCvM-b8fsbB7vzYSeVjDw0wiGTShBxoH9m9acxF92qbaF%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to