3 ms·
No mention of caching? If your database is getting hammered with SELECTs, isn't putting a cache in front of it something that should at least be considered?
by gary_0 3y ago
No mention of caching? If your database is getting hammered with SELECTs, isn't putting a cache in front of it something that should at least be considered?
- deathanatos 3y agoI've been in the OP's situation, and this exact suggestion was made in my case. Welcome to one of the hardest problems in CS: cache invalidation. If you have a dataset for which cache invalidation is easy (e.g., data that is written and never updated), yeah, absolutely go for this. In our case, and most cases I've seen, it wasn't so simple, and "split this off to a DB better suited to it" was less complex (maybe still a lot of work, but conceptually simple) than figuring out cache invalidation.
- lern_too_spel 3y agoThere are systems that will do that for you like https://readyset.io/ https://readyset.io/.
- Scarbutt 3y agoThey mentioned adding a DB replica for reads.