TE
테크에코
홈24시간 인기최신베스트질문쇼채용
GitHubTwitter
홈

테크에코

Next.js로 구축된 기술 뉴스 플랫폼으로 글로벌 기술 뉴스와 토론을 제공합니다.

GitHubTwitter

홈

홈최신베스트질문쇼채용

리소스

HackerNews API원본 HackerNewsNext.js

© 2025 테크에코. 모든 권리 보유.

Just make it scale: An Aurora DSQL story

134 포인트작성자: cebert4일 전

6 comments

Demiurge4일 전
Many interesting things, for instance, I&#x27;ve been hearing a lot about how fast Java is, that it can be as fast as C++, and then I see this:<p>&gt; But after a few weeks, it compiled and the results surprised us. The code was 10x faster than our carefully tuned Kotlin implementation – despite no attempt to make it faster. To put this in perspective, we had spent years incrementally improving the Kotlin version from 2,000 to 3,000 transactions per second (TPS). The Rust version, written by Java developers who were new to the language, clocked 30,000 TPS.<p>I feel like there is more to this, like some kind of a bottleneck, memory footprint, some IO overhead?<p>&gt; Our conclusion was to rewrite our data plane entirely in Rust.<p>The point is well taken, figuring it out is not worth it, if you can just &quot;rewrote&quot; or have green field projects.<p>&gt; These extension points are part of Postgres’ public API, allowing you to modify behavior without changing core code<p>Also, interesting. So PostgreSQL evolved to the point that it has a stable API for extensibility? This great for the project, maintain a modular design, and some stable APIs and, you can let people mix and match and reduce duplication of effort.
评论 #44108231 未加载
评论 #44114349 未加载
kondro4일 전
It would be really great to get more context on what a DPU is for pricing: <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;rds&#x2F;aurora&#x2F;pricing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;rds&#x2F;aurora&#x2F;pricing&#x2F;</a><p>I understand that AWS did one TPC-C 95&#x2F;5 read&#x2F;write benchmark and got 700k transactions for 100k DPUs, but that’s not nearly enough context.<p>There either needs to be a selection of other benchmark-based pricing (especially for a primarily 50&#x2F;50 read&#x2F;write load), actual information on how a DPU is calculated or a way to return DPU per query executed, not just an aggregate CloudWatch figure.<p>We were promised DSQL pricing similar to DynamoDB and insofar as it’s truly serverless (i.e. no committed pricing) they’ve succeeded, but one of the best parts of DynamoDB is absolute certainty on cost, even if that can sometimes be high.
评论 #44111301 未加载
glzone14일 전
Early dsql had some weird limits I think - anyone actually using in production with feedback on current corners and limits?
评论 #44107867 未加载
评论 #44108094 未加载
评论 #44107905 未加载
评论 #44108900 未加载
geodel4일 전
Good read. I like the part that both writing low level as well as high level component in Rust was proven worthwhile.<p>Maybe one can transform slow code from high level languages to low level language via LLMs in future. That can be nice performance boost for those who don&#x27;t have Amazon engineers and budgets
评论 #44108133 未加载
评论 #44108106 未加载
评论 #44108514 未加载
mrkeen3일 전
Where can I go to read about distributed SQL and big JOINs or WHERE IN clauses? I was hoping this article would cover that elephant in the room, rather than Rust being significantly more performant than JVM languages.
评论 #44114879 未加载
karl_p4일 전
The JVM can relocate memory to avoid fragmentation. Rust can&#x27;t, at least natively. Are they not worried about this regression?
评论 #44108353 未加载
评论 #44113335 未加载