Thanks for the clarification. So in this case, would it still make sense to split the data in multiple databases ? For me it means it will be easier to export the DB of a given org and import it on an other influx server let's say when the org ask for on-premise solutions.
It would also allow me to set retention policies / org for all the measurements in this org. I saw the last thread about multiple databases and you seem completely against this usage so I was thinking there may be a limitation I was not aware of. Thanks :) Le mardi 21 juin 2016 18:05:16 UTC+2, Sean Beckett a écrit : > > When tag values are dependent they don't increase cardinality at all. For > example, let's say I store user emails as a tag (terrible idea, btw, but > just for the example here.) Emails are by definition globally unique. So, > if I have a series defined by email, I can store whatever else I want, like > First Name, Last Name, Phone Number, Physical Address, Nickname, etc. and I > have defined no more series than I did before. Sure, I just added a new tag > like First Name with an infinite cardinality, but it's not multiplicative. > For any given email address there is one and only one First Name. First > Name is dependent on email, it is implied by email. So the series count > doesn't rise. Email is globally unique, so I can't have more series than I > have emails, no matter what other metadata I add to the series. > > Yes, first names can change and emails can be recycled, but overall the > cardinality is perhaps 10% higher than the total emails? Certainly not the > multiplication of the cardinality of each tag. > > On Tue, Jun 21, 2016 at 10:00 AM, Sean Beckett <[email protected] > <javascript:>> wrote: > >> The cardinality is not multiplicative unless every possible combination >> actually exists in the database. What you've described is the maximum >> possible cardinality, but if OrgA and OrgB have distinct values for Tags 1, >> 2, and 3, then there is no possibility of a series like: >> >> Tag1A, Tag2A, Tag3B >> >> Therefore the total cardinality is never going to approach 1000. >> >> If TagA and TagB are actually the same, and the above series is >> reasonable, then you don't have 10 possible values in Meas1, you have 5. >> The cardinality of the database would still be ~125, although presumably >> you need a tag to differentiate OrgA and B, so that doubles it to 250. >> That's also the sum of the cardinality of the two separate databases. >> >> On Tue, Jun 21, 2016 at 3:54 AM, Alexandre Grais < >> [email protected] <javascript:>> wrote: >> >>> Hi guys, >>> >>> I recently read the following post : >>> https://groups.google.com/forum/#!topic/influxdb/4AzHnMdhyJ0 >>> >>> Let's say you have the following use cases: >>> >>> *-> CASE 1 : One database to store metrics for 2 organizations named A & >>> B* >>> >>> Measurement1 >>> Tag1 -> 10 values (5 values for orga A and 5 for orga B) >>> Tag2 -> 10 values (5 values for orga A and 5 for orga B) >>> Tag3 -> 10 Values (5 values for orga A and 5 for orga B) >>> >>> Cardinality: 10*10*10 = *1000* >>> >>> *-> CASE 2 : One database for each organization* >>> >>> Measurement1A >>> Tag1 -> 5 values >>> Tag2 -> 5 Values >>> Tag3 -> 5 values >>> >>> Cardinality: 5*5*5 = *125* >>> >>> Measurement1B >>> Tag1 -> 5 Values >>> Tag2 -> 5 Values >>> Tag3 -> 5 Values >>> >>> Cardinality: 5*5*5 = *125* >>> >>> So from my understanding, in this case, when tags values are highly >>> dependant of other values, it may make sense to split the data in different >>> base. >>> >>> Could you confirm ? >>> >>> >>> >>> >>> -- >>> 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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/23486fd5-4f40-4ae7-9573-a09eb55e6683%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/influxdb/23486fd5-4f40-4ae7-9573-a09eb55e6683%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 >> > > > > -- > 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 [email protected]. To post to this group, send email to [email protected]. 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/af9071bd-2b4a-4424-baba-62998a8721fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
