Skip to content
New issue

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

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

Already on GitHub? # to your account

How best to support different underlying value storage models? #21

Open
ideasasylum opened this issue Jan 4, 2024 · 0 comments
Open
Assignees

Comments

@ideasasylum
Copy link
Contributor

In the simplest case, counter values are just integers.

  • But then what if you wanted to count really large numbers. BigInt?
  • We needed to count percentages (calculated from other counters) such as spam rate. So Float? Or Double? Or even Decimal?
  • We will need to store counters as HLL values enabling us to approximately count unique values
  • We may want to support slotted counters to allow higher concurrent writes without locking
  • We will need to support counters over time, i.e., number of emails sent per month
  • We might want to support counters/events in external systems like Redis

It's hard to support these different representations in a single database table. We could make Counter::Value an STI table but then we'd be storing Integer, Float, HLL, and maybe JSONB columns for each counter.But maybe that's fine if those columns are nil since they only require ~1bit of storage??

Alternatively, the counter should write to different tables depending on the configuration?

…which gets be reconsidering having separate counter definitions. Perhaps values should just be Rails models? e.g.

# This will be stored on the counter_values table with an type value of "MyCounter" (i.e., using STI)
class MyCounter < Counter::Value
  # Some configuration methods to specific what it is counting, conditionals, hooks etc
  count…
end

# This will be stored in the counter_hll table with a type value of "PageVisitsCounter"
class PageVisitsCounter < Counter::HLL
  # some config…
end

Using different tables might make sorting/filtering a little harder but probably doable.

@ideasasylum ideasasylum converted this from a draft issue Jan 4, 2024
@ideasasylum ideasasylum self-assigned this Jan 4, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
Status: Noodling on
Development

No branches or pull requests

1 participant