Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distributed atomic counter support in JetStream KV #2656

Open
FalxDraco opened this issue Oct 30, 2021 · 8 comments
Open

Distributed atomic counter support in JetStream KV #2656

FalxDraco opened this issue Oct 30, 2021 · 8 comments
Assignees

Comments

@FalxDraco
Copy link

Feature Request

Add Distributed Atomic Counter support to JetStream KV.

Use Case:

Slack thread

Proposed Change:

  • add supporting code to kv
  • add command-line support
    • a new flag for kv add subcommand to specify whether the stream backing a bucket should be a file stream or a memory stream, e.g.:
      • nats kv add my_bucket --replicas 1 --history 5 --STORAGE=FILE
      • nats kv add my_bucket --replicas 1 --history 5 --STORAGE=MEMORY
    • two new subcommands:
      • incrby x, e.g.: nats kv INCRBY 20 my_bucket my_key_1
      • decrby x, e.g.: nats kv DECRBY 10 my_bucket my_key_1
  • allow interacting with the counters programmatically
    • 1st phase: via publishing messages to dedicated subjects; this would allow the new feature to be used before the official clients catch up.
    • 2nd phase: via Synadia official JetStream client(s).

Who Benefits From The Change(s)?

  • Synadia - by closing the feature gap between JetStream and more popular solutions.
  • Synadia - by making clients and users happy. Who doesn't need or use counters in production?
  • JetSstream users - who can say no to happiness ?

Alternative Approaches

  • The competition
    • Apache Kafka
    • Apache Pulsar
  • Other software
    • Redis
    • RDBMS
    • etc
@ajlane
Copy link

ajlane commented Jun 10, 2022

The Slack thread describing the use case has been archived, but I hope that the use cases are still easy enough to imagine.

I am currently doing this this by publishing +1s and -1s to a stream, then consuming that stream with another client that eventually puts the accumulated results into a kv store. It would be nice to skip that step.

@derekcollison
Copy link
Member

We continue to think through some of these patterns.

For now, the client can read and update only if no updates got in between. If the update rate is high this might not be a good solution however.

@elichai
Copy link

elichai commented Feb 14, 2024

Is anyone still working/thinking about this?

@ripienaar
Copy link
Contributor

it's on the short term roadmap yes

@derekcollison derekcollison self-assigned this Feb 16, 2024
@pySilver
Copy link

pySilver commented Mar 28, 2024

@ripienaar any chance this will be implemented in 2.11?

@ripienaar
Copy link
Contributor

I believe it's still the plan yes

@sloveridge
Copy link

sloveridge commented May 10, 2024

I have been checking for this in the 2.11 preview announcements but haven't seen it land yet. Could you let us know if this will be in 2.11 still?

Thank you!

@derekcollison
Copy link
Member

Yes it will be. We are admittedly behind, but not for lack of effort and commitment, we just been helping out customers and partners. But it will be there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants