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 performant than DROP SERIES, so I would think scoping each customer to a measurement (Schema #2) would be beneficial for overall organization. Schema #3 is not a great schema, as it puts important metadata in the measurement name. Typically that's an anti-pattern. Additionally, there are no JOINs across measurements, so you wouldn't be able to query for the COUNT() of all events across a customer if each page ID meant a new measurement. On Tue, Aug 2, 2016 at 11:05 PM, <r...@rmills.id.au> wrote: > 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, URL=test.com > > or > > (2) > Measurement = XYZ (OrganisationID) > Tags = PageId=123, Event=PageView > Values = BrowserAgent=Chrome, URL=test.com > > Measurement = XYZ (OrganisationID) > Tags = PageId=123, Event=Click > Values = BrowserAgent=Chrome, URL=test.com > > or > > (3) > Measurement = XYZ-123 (OrganisationId-PageId) > Tags = Event=PageView > Values = BrowserAgent=Chrome, URL=test.com > > Measurement = XYZ-123 (OrganisationId-PageId) > Tags = Event=Click > Values = BrowserAgent=Chrome, URL=test.com > > This would be a used in a multi-tenant environment where each customer > (organisation) has their own data. Does the use of a orgid-pageid > measurement help the underlying database? > > IE, with SQL having a table name as the OrgId-PageId would restrict the > indexing storage/speed to just that of that scope, however I'm not sure it > would be the same with InfluxDB as perhaps indexes are based on series > (which includes measurement and tags). > > So then in theory it would be much of a muchness - no performance gain by > segmenting data? > > Ryan > > -- > 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/0100a133-7b23-4d29-aa7a-33e2666991d7%40googlegroups.com > <https://groups.google.com/d/msgid/influxdb/0100a133-7b23-4d29-aa7a-33e2666991d7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Sean Beckett Director of Support and Professional Services InfluxDB -- 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/CALGqCvPuXvQ-oAchuZ1E_YBFqVN5MJVJjOfJZCbAAxvF4QD-Mw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
