5 ms·
If you have a lot of connections doing similar things, just batch requests to get the data in bulk. Scaling your database up should only be attempted once you
by twawaaay 4y ago
If you have a lot of connections doing similar things, just batch requests to get the data in bulk.
Scaling your database up should only be attempted once you can no longer improve efficiency of your application. It is always better to first put effort into improving efficiency than scaling it up.
For example, one trick that allowed me to improve throughput of one application using MongoDB as a backend by factor of 50 was capturing queries from multiple requests happening at the same time and sending them as one request (statement) into the database, then when you get the result you fan them out to the respective business logic that needs them. The application was written with Reactor which makes this much easier than a normal thread based request processing.
For example, if you have 500 people logging at the same time and fetching their user details, batch those requests for example every 100ms up to 100 users and fetch 100 records with a single query.
You will notice that executing a simple fetch by id query even for hundreds of ids will only cost couple times more than fetching a single record.
The application in question was able to fetch 2-3 GB of small documents per second during normal traffic (not an idealised performance test) with just couple dozen connections.
- lifeisstillgood 4y agoJust wanted to come back and defend you (a little :-) I read "if you have a million database connections then you are doing it wrong" less as a ad hominem attack and more as "if one is doing X one should try a different approach" I did like the "architectural strategy" of I can call it that of batching the calls. It's "tricks" like that, expressed at this level that are somehow missing from the common software dev parlance. They are not in l33tcode tests, they don't fit into neat boxes but they are vital "common knowledge" I wish I had a better term for these sort of optimisations. Anyway. Thanks for the comment. Don't take the blowback personally - frankly I was surprised even if it was a small storm in a teacup. And always do as dang says ;-)
- DSingularity 4y agoBut the lost elegance!
- andrewbarba 4y agoHow could you possibly say this is doing it wrong? The only way you could batch requests in the way you describe is if you have 1 (or very small number) compute nodes. You would need all those requests to hit same node so you could try and batch. With serverless compute infrastructure (which is what this blog is demonstrating by using lambda) you can have 1 isolated process per request and therefore need a database that can actually handle this kind of load.
- vbezhenar 4y agoIntroduce intermediate server which accepts multiple requests and groups them into single batch requests. With enough trickery you can even implement it using postgres wire protocol, I guess, so it'll be transparent.
- cbrewster 4y agoNow you need to batch your requests to your intermediate server
- yamtaddle 4y agoNo, you don't. You have one per 100 nodes or whatever. Not a single one for all nodes to talk to.
- mjb 4y agoBut why? Why have an additional component if your database can do it?
- vbezhenar 4y agotwawaaay claimed that similar approach allowed him to improve throughput by factor of 50. Apparently database couldn't do it efficiently in that case.
- deleted 4y ago[deleted]
- yamtaddle 4y agoBut then you can't put "led implementation of a highly-scalable $80m/yr cloud-native solution" on your resume. And bigger numbers mean bigger salary. Now, if you wait for someone else to do this then you swoop in and cut that spending by 90%... now you're talking. Then the next person can reverse what you did and we all keep making money digging holes then filling them back up. Pay it forward.
- Kiro 4y agoWhy are people upvoting low-effort snark like this?
- _boffin_ 4y agoBecause it’s sadly true
- twawaaay 4y agoYeah, it is better to manage 50 people and millions in hardware than do the same work with just 2 engineers and one server. You then get those completely unnecessary feats of technology when really, a single server is usually good to run hundreds of thousands of transactions per second. It infuriates me that incompetence is promoted and the only way to get rewarded is to be good at internal politics.
- themenomen 4y agoI thought this was just a PoC
- dang 4y agoCan you please edit swipes like "you are doing it wrong" out of your HN comments? It acidifies the thread and evokes worse from others. The site guidelines are pretty clear about this: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- twawaaay 4y agoEdited out but the issue is it really is technically wrong. From a person that is actually building real world large scale applications this is super naive. There exists no networking hardware or disk IO that can adequately support this many active connections. What you really want to do is to do the same work with much less connections which will save you a ton of overhead and also memory that can be used to actually cache useful data. My goal is to share this little bit of insight so that hopefully fewer people make this fatal mistake. Just because you can technically do something does not mean this is a good idea. If you need to run a million connections to the database instance you really need to rethink this entire problem.
- nixgeek 4y agoI’m not sure I’d say anything is a “fatal mistake” if it works, and this appears to? Feels like you’re coming at this from “it’s suboptimal”, calling it a fatal mistake is a bit much? I would look at it this way: Firstly, it’s just a demonstration of how far a technology can scale, not an endorsement of technical approach for the customers. Secondly, on serverless, PlanetScale is just solving things their customers want? They don’t have a business if they don’t do that. Finally, even if you are “right” or at least making a valid point, isn’t the “rethink this entire problem” take principled more than practical? There’s always 47 things to do and time only exists to do a few.