Hi Kyrulo, I don't understand how UUIDs are related to counters, but I use counters to increment the value of a cell in an atomic manner. I could try reading the value and then writing to the cell but then I would lose the atomicity of the update.
F Javier Pareja On Mon, Mar 5, 2018 at 1:32 PM, Kyrylo Lebediev <kyrylo_lebed...@epam.com> wrote: > Hello! > > Can't answer your question but there is another one: "why do we need to > maintain counters with their known limitations (and I've heard of some > issues with implementation of counters in Cassandra), when there exist > really effective uuid generation algorithms which allow us to generate > unique values?" > https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html > > <https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html>(the > article is about keys in RDBMS's, but its statements are true for NoSQL as > well) > > > Regards, > Kyrill > ------------------------------ > *From:* jpar...@gmail.com <jpar...@gmail.com> on behalf of Javier Pareja < > pareja.jav...@gmail.com> > *Sent:* Monday, March 5, 2018 1:55:14 PM > *To:* user@cassandra.apache.org > *Subject:* How do counter updates work? > > Hello everyone, > > I am trying to understand how cassandra counter writes work in more detail > but all that I could find is this: https://www.datastax.com/dev/ > blog/whats-new-in-cassandra-2-1-a-better-implementation-of-counters > From there I was able to extract the following process: > (click here to edit > <https://www.draw.io/?lightbox=1&highlight=0000ff&edit=_blank&layers=1&nav=1&title=Untitled%20Diagram.xml#R7VpRc6M2EP41nmkfcgPCYPKYOPHdTXudzCXtNY8yCKMGkCvk2LlfXwkkjATYjo0dp5O8BK2kZdldfftJ8sAZp6vPFM7jbyREyQBY4Wrg3AwAsIfA4%2F%2BE5KWU%2BP5lKZhRHMpBa8E9%2Fomk0JLSBQ5Rrg1khCQMz3VhQLIMBUyTQUrJUh8WkUR%2F6xzOUENwH8CkKf2BQxZLqW1Z644vCM9i%2BWrflR1TGDzNKFlk8n0D4ETFX9mdQqVLjs9jGJJlTeTcDpwxJYSVT%2BlqjBLhW%2BW2ct6ko7eym6KM7TRhhKDnjZDtBoCbGlwAXxrGXpQzUMh9I5uEspjMSAaT27X0uvhgJFTavBWzNJGPCZyi5LryyZgkhPKujGRiWs4gZVciXIZsghOhwVJtmSAub6MsVDOCBOY5Dh5inJUdcppdtmqT%2FkGMvcg2XDDCResP%2BZ2QuZyVM0qekLKSx84q%2FqoelQtibEQyNoEpTkSK%2F4VoCDMoxfJNvmy26ePhoS9%2Fi2%2F85Krmo%2FxktMKs1sVbj%2FKdzejKgOdkQQOVu45cMJDOkBwGSpGIZG2eTInPiKSIv58PoCiBDD%2FrqwDKxTSrxlVT7wjmlgBLLnwwlGktl%2F3Qt3QVpZ1yVj0tDUVDy1DkGorKj2so4qkBX2rD5mJA%2FgqDL62Ndjmbx%2FOH0gLVqjl3LSqWYPtydEvtzzBZIAUgB6xGS1%2BNuy6DTcnZmkjbc9KEGQXqtRy1vQNzshaFjU7uMqbm9dsVChYMceGYO5Mhyp%2F%2BnIdQiLyEG3w95SJvxiqP1CLEMX0uHmO0gty1fMgcUczNRHQtvVuLrpcxZuh%2BDgtvLXlF1cOmx7OqGNYO%2BPoKOOPYWRspi9YuMGeDDTgHEzzLBFajrPzWznR5RpSh1WATOqnekbEIZXNZq9RKFteLtHWE3AGN3PlBcZE5HDgI%2F%2FcNpQxOeW6YaaIXzS05cEjUvcBH02iXqIcQ%2BVFwnlH39aC7oCXqoCXqwx6ivjXIY5KmmCVk9nZRDkeX013XNvKC40W5EdKWwHdG%2BU3D7HxQ3zOnvq%2FmHS1cuB3Cz5gL24Yi7zy4sH1kLmxfnhcZtrVkrRK0z3QdtmSrc5TsHAI9eI6ZnR1JtUcchy1hlBxaUejvCIYDYVEp5xqrrmBBC5cpBcCKKEn5vxucPx1WbbvKYndp7aHAOZ7ueOCdsMB5jVBMyqOqSdOTMUmni3y7F%2Fso%2BsZuv43R%2B0ci9B%2FHXSep%2BT0D5aFHBR0V0DXIp7nmdi3ZZil1Lo%2BGrs0i%2BYjyRk7ztcmMQwWU45%2FFvrRMPMkO%2BGj3euDetNF7scZxAJMr2ZHiMCzWQ0fa148ROlFCnuBLSwbVwXg9AfyN6HFhffKA7%2BkOL1v75oMaQqIoR4dGSNG3D4g5CcTYNYAp4eacIcZx9oSYBo%2FYkcC9dldQGWi8p9OuzeMP3xU0D2v%2FIP8zvLOtwbsGPKcRoq9ZQFGq8%2Fip%2BCQWi8eFPFo3YTJJ8DxH2zkozOflLXCEVwI0j0FKHd89GSm1Rw0PHlRD9tz67gectszM%2Bi72ZFc7zR3OQ%2FGmxpaT7rHlXN8FjWEQH3ii33X03n1830NSm1cndtvus%2B3upJdTdKsRnO9X37jglwnM2a8b3GmdqTvNa2q%2FxZtHu5NoFsKbr%2Fe%2FCXfeJ2TZrztPczZiutNuu9k7mj%2FBdszlyPBcre8mb9ZdqBNcQURDmMfVdNG4g4zjSVZIgLVfGs8oDDHSOLE44EavuaxvRqTmcbfF4Up2IBu2DRJrbpN33m8bpLO6NeqZDJv2KrLbeURu3GYNnX7JMGgyrUahUwKxb9Ky2ft3QVTHRV6wgSuRhcP5at2ptNxdPXwpUnRdL0uF%2BkvqZXSHX0q8b5peAsQmmm6NvKFeIHpZNmJbW9d64QBdRS80vvXg%2Fq0BMYqCEPgbC1ELIEYRdK33AIgO6AkQvdMAommvve10wOCfYAuAuoZ%2B5eddxyv7Ov10aYzv%2BQ6z9Qd9xwRo8AHQNYAevhFAA03n6HBw5s31b8LL4esf3ju3%2FwE%3D> > ). > > > PATH 1 will be much quicker than PATH 2 and its bottleneck (assuming HDD > drives) will be the commitlog > PATH 2 will need at least an access to disk to do a read (potentially even > in a different machine) and an access to disk to do a write to the > commitlog. This is at least twice as slow as PATH 1. > > This is all the info that I could get from the internet but a lot is > missing. For example, there is no information about how the counter lock is > acquired, is there a shared lock across all the nodes? > > Hope I am not oversimplifying things, but I think this will be useful to > better understand how to tune up the system. > > Thanks in advance. > > F Javier Pareja >