It would be really great to get more context on what a DPU is for pricing: https://aws.amazon.com/rds/aurora/pricing/ I understand that AWS did one TPC-C 95/5 read/write benchmark and got 700k transactions for 100k DPUs, but that’s not nearly enough context. There either needs to be a selection of other benchmark-based pricing (especially for a primarily 50/50 read/write load), actual information on how a DPU is calc…
> one of the best parts of DynamoDB is absolute certainty on cost
That depends if its On Demand or Provisioned, even if they recently added On Demand limits.
It would be really great to get more context on what a DPU is for pricing: https://aws.amazon.com/rds/aurora/pricing/ I understand that AWS did one TPC-C 95/5 read/write benchmark and got 700k transactions for 100k DPUs, but that’s not nearly enough context. There either needs to be a selection of other benchmark-based pricing (especially for a primarily 50/50 read/write load), actual information on how a DPU is calc…
> one of the best parts of DynamoDB is absolute certainty on cost That depends if its On Demand or Provisioned, even if they recently added On Demand limits.
You still have absolute certainty. Read or write x amount of data and it will use exactly y R/WCU.
It then just becomes a modeling problem allowing you to determine your costs upfront during design. That’s one of the most powerful features of the truly serverless products in AWS in my opinion.
Early dsql had some weird limits I think - anyone actually using in production with feedback on current corners and limits?
Which features would you like to see the team build first? Which limits would you like to see lifted first? Most of the limitations you can see in the documentation are things we haven't gotten to building yet, and it's super helpful to know what folks need so we can prioritize the backlog.
> Maybe one can transform slow code from high level languages to low level language I think you are describing a compiler?
I mean reading this article: 1) Kotlin code --> Java byte code --> JVM execution (slow) vs 2) Kotin code --> Rust/Zig code --> Zig compiler --> native execution (fast) Compiler is involved in both cases but I was thinking of 2) where slower code in high level lang is converted to another lang code. The compiler of which is known to produce fast runinng code.
You’re describing a transpiler, but the problem is that idioms in a GC language like Kotlin don’t necessarily translate to a non-GC language like Rust or Zig. Add in the fact that Rust doesn’t have OO inheritance which is essential for a lot of JVM code to work (I don’t know much about Zig) and I’d be very suspicious of code generated by a Kotlin to Rust transpiler. (On the other hand, one of the first transpilers I ever encountered, web2c, worked well because the source language, Pascal, could be fairly easily translated into functional C without much if any sacrifice of speed or accuracy.)
Which features would you like to see the team build first? Which limits would you like to see lifted first? Most of the limitations you can see in the documentation are things we haven't gotten to building yet, and it's super helpful to know what folks need so we can prioritize the backlog.
Why does it not support TRUNCATE?
My understanding is the way Aurora DSQL distributes data widely makes bulk writes extremely slow/expensive. So no COPY, INSERT with >3k rows, TRUNCATE etc
My understanding is the way Aurora DSQL distributes data widely makes bulk writes extremely slow/expensive. So no COPY, INSERT with >3k rows, TRUNCATE etc
TRUNCATE is DROP TABLE + CREATE TABLE, it’s not a bulk delete. It bypasses the typical path for writes entirely.
The JVM can relocate memory to avoid fragmentation. Rust can't, at least natively. Are they not worried about this regression?
With 10x the throughput (TPS) and the lack of GC pauses (which were the cause of the rewrite), how would they measure such a regression, let alone worry about it?
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.
Many interesting things, for instance, I've been hearing a lot about how fast Java is, that it can be as fast as C++, and then I see this: > 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…
> I feel like there is more to this, like some kind of a bottleneck, memory footprint, some IO overhead?
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.
Marc Brooker has written and spoken about DSQL quite a bit. It’s still rather high level. I’d expect one or more papers to come out in the next few months, similarly to other Amazon databases.