Thanks for you help. Regarding the cardinality, your explanation is really great and deserves to have a dedicated part in InfluxDb docs.
Thanks again for your support. *Alexandre Grais - kapptivate* *Website: http://www.kapptivate.com <http://www.kapptivate.com>* *Email: [email protected] <[email protected]>* *Phone: +33 7 89 80 03 56* *Skype: alexandre.grais* 2016-06-21 18:13 GMT+02:00 Sean Beckett <[email protected]>: > In this case there's no real difference to having them in one or two > databases. Since you have other maintenance considerations that push you > towards using discrete dbs for each org, that totally makes sense. > > On Tue, Jun 21, 2016 at 10:10 AM, Alexandre Grais < > [email protected]> wrote: > >> 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]> >>> 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]> 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]. >>>>> 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/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 >> <https://groups.google.com/d/msgid/influxdb/af9071bd-2b4a-4424-baba-62998a8721fc%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 a topic in the > Google Groups "InfluxDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/influxdb/YZ_ZcJjfabM/unsubscribe. > To unsubscribe from this group and all its topics, 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/CALGqCvOnOr%3Dg0YWdL3q0yXcEm%2BnySRvZiUSA0P7%3DHFyAL37UuQ%40mail.gmail.com > <https://groups.google.com/d/msgid/influxdb/CALGqCvOnOr%3Dg0YWdL3q0yXcEm%2BnySRvZiUSA0P7%3DHFyAL37UuQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAKdBnM%2BdgjQd%2B4WzvnZDZocXx0OzKy%2Bf-DM%3DmUy9y%2BtCan%2Bxtw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
