Programming

17494 readers

123 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Need to track feature usage for 50k+ users daily (programming.dev)

submitted 1 year ago by kris@programming.dev to c/programming@programming.dev

6 comments fedilink hide all child comments

Hi,

I need to track feature usage for an application so I can do the following:

track feature usage for a user. We have 20+ features and we want to limit feature usage. Think, select count(*) from db where user_id = 1 and feature_id = 1 that have to be calculated on the fly.
must have fast read write ops.
able to do machine learning on data
do I need horizontal scaling?

I've been pointed towards elastic search and wondering if there's better alternatives.

you are viewing a single comment's thread
view the rest of the comments

[–] abhibeckert@lemmy.world 8 points 1 year ago* (last edited 1 year ago) (1 children)

must have fast read write ops.

Often that's done with two databases - one database is fast to write, the other is fast to read.

Then you have a task that moves data from the fast write database over to the fast read one.

do I need horizontal scaling?

A simple table with no index at all on a fast server with a simple relational database should be able to handle several hundred thousand inserts per second. If you add indexes, it gets slower. Potentially unusably slow.

So, you have all your indexes on a second table. That one does have indexes, and with the right indexes it can handle hundreds of thousands of reads per second.

No scaling necessary, just two tables in one database. You should only need to scale when you run out of disk space.

You might also make it a little more complex, like have a write table for each day. Then you can copy the data over in a single batch and delete the table.

[–] Hexarei@programming.dev 1 points 1 year ago

Good ol' read replica pattern.