Ask HN: How to measure the cost for read requests in Serverless DBaaS
I'm currently developing a serverless time-series cloud service and we've reached the juncture of designing an innovative cost metric system. Our goal is to move away from the convention of calculating costs based on memory and CPU usage, instead offering our customers a more precise price calculation method.
For write requests, the measurement method seems somewhat straightforward - we can measure according to data size. However, when it comes to read requests, the paradigm shifts. These requests often involve varying levels of analysis operations which could result in substantial differences in resource utilization.
I'm struggling to find a fitting and fair methodology to measure the cost for read requests, particularly those that involve complex analytical queries. I'd appreciate it if anyone could suggest suitable approaches to accurately factor in such diverse resource requirements in our pricing model.
Any help or pointers would be greatly appreciated. Thanks in advance. Take a look at how AWS Aurora does IO metering. Thanks, I quickly went through how Aurora performs IO metering. It divides IO into Read operations and Write operations, which seems suitable for OLTP services. However, for analysis purposes, there is also CPU consumption that cannot be ignored. Would it be a good idea to include Calculate operations similar to IO? I'm pretty confused about what you are asking. In the original post you made it sound like you don't want to consider CPU and RAM, and in this response, you do. You could also look at how AWS Lambda does it. They have a standard base configuration, and for that one, you only pay for invocation of a function, and that function has to finish in some period of time before it's killed. If you want more RAM, or more CPU, or same CPU but more time to finish calculation, you pay above the baseline. Also, it's not obvious to me that the Calculate component cannot be ignored. AWS Redshift Serverless and AWS Athena are all OLAP, and they all operate on a "data scanned" metering model, no CPU or RAM considerations. Also - I am mostly familiar with AWS, so that's what I am suggesting here. Obviously you and AWS have completely different scalability considerations, so this might not apply at all. But, if you wanted to be competitive, then in the end you'd have to be better than AWS on price, so starting there is not a bad idea, even if in the early days you are doing something different Apologies for any uncertainty regarding CPU and RAM factors. Initially, my thought was to decouple the cost model from conventional hardware factors from a user's view. However, from the service provider's viewpoint, I have to encompass aspects like CPU consumption, IO usage, and RAM utilization while crafting this cost model to bring mutual benefit. Utilizing AWS as a foundational reference is indeed a worthwhile approach, something I'll delve into by examining pertinent services. Thank you yet again for your insightful feedback!