Hacker News Reader

Comment by emmelaich | Hacker News Reader

So they do joins in code rather than SQL? Wouldn't that risk hiding scaling problems?

It can but it's usually more obvious what's happening with code and how to fix it. Amazon wants you to think about the scaling issues while building as they don't want to lose the area under the customer curve on the far right.

The theory is that with rdbms you have a magical box that scales vertically until it doesn't. And when it doesn't all you can do is scale back the customers until you fix it with sharding or a re-architecture. Basically you tend to hang yourself with indexes and transactions. Also generally when an RDBMS fails it fails down to like 30% throughput.

I recently finished a contract at a company who has gone full on dynamo with the idea that if we have slow queries and dynamo is good for Amazon, then it's good for us too. I've ran some explain on the queries causing issues and of course those queries didn't leverage indexes like they thought ....

How did you run explain queries on DynamoDB? Or may be you mean something different and I misunderstood you?

I ran explain on the original mysql implementation. The basis of the migration project to dynamo was mysql couldn't cope with our scale but that was bullshit

That doesn't make sense, you have to specify the index when you're using Dynamo.

You can do scan operations and if they use PartiQL it hides whether you are using indexes.

I usually have an explicit DENY for dynamodb:Scan for the IAM role used to access the DDB table

Look up design patterns in DynamoDB. If you know your access patterns and you often do with well defined microservices. You don’t need to do joins.

Amazon Retail has multiple systems to allow you to basically use SQL across databases (eg Datapath).

I’m not sure about AWS.

Reply on news.ycombinator.com