Live data from Hacker News

DynamoDB 10 years later

amazon.science

191–200 of 225 posts

Re: DynamoDB 10 years later

#191

As a developer, I really have a love-hate relationship with Dynamo. I love how fast and easy it is to setup and get rolling. The partitioning scheme came off as confusing and opaque but I think that says more about Amazon's documentation than the scheme itself. I do not like that there's no really third party tooling integration to be able to query. Their UI in the console is _so freaking terrible_ yet you have no ot…

* SQL support is so new (https://aws.amazon.com/about-aws/whats-new/2020/11/you-now-c...) I have not seen it used in real life yet.

* No way to "DELETE * FROM T"

Re: DynamoDB 10 years later

#192

Earlier quoted context omitted.

They probably view it as a competitive advantage that Azure or GCP would try to copy if they figured out the "secret sauce."

I kinda doubt it. It's probably just that open sourcing it won't provide much utility (I bet lots of code is aws specific) and just adds a new maintenance burden for them.

The way you need to write code for a massively scalable service is just different. And the things you need to operate a service are also just different.

Re: DynamoDB 10 years later

#193

I can safely say that the team members working in DynamoDB are very skilled and they care deeply about the product. They really work hard and think of interesting solutions to a lot of problems that their biggest customers face which is great from a product standpoint. There are some pretty smart people working there. Engineering, however, was a disaster story. Code is horribly written and very few tests are maintain…

>Engineering, however, was a disaster story. Code is horribly written and very few tests are maintained to make sure deployments go without issues. There was too much emphasis on deployment and getting fixes/features out over making sure it won't break anything else. It was a common scenario to release a new feature and put duct tape all around it to make sure it "works". And way too many operational issues. There ar…

AWS level of disaster is very different to an average disaster. :)

Re: DynamoDB 10 years later

#194
post #133

We realized how great Dynamo was only after we migrated off AWS. Dynamo was a key factor to us when we were releasing the MVP of our News API [0]. We used Dynamo, ElasticSearch, Lambda and could make it running in 60 days while being full-time employed. Also, the best tech talk I saw was given by Rick Houlihan on re:Invent [1] I highly recommend every engineer to watch it: it's a great overview of SQL vs NoSQL [0] ht…

BTW Rick Houlihan left AWS recently to work for Mongo. https://twitter.com/houlihan_rick/status/1472969503575265283 On that thread he criticizes AWS regarding DynamoDB openly. > I will always love DynamoDB, but the fact is it is losing ground fast because AWS focuses most of their resources on the half baked #builtfornopurpose database strategy. I always hated that idea, I just bit my tongue instead of saying it. > T…

Interesting. MongoDB actually came to mind while I was reading the other comment here:

> No one uses DynamoDB alone: they bolt it onto Postgres after realizing they have availability or scale needs beyond what a relational database can do, then they bolt on Elasticsearch to enable querying, and then they bolt on Redis to make the disjointed backend feel fast. And I'm just talking operational use cases; ignoring analytics here.

Perhaps MongoDB is prime for a comeback?

Re: DynamoDB 10 years later

#195
I absolutely love DynamoDB. Would definitely recommend the DynamoDB Book by Alex Debrie and Advanced DynamoDB Patterns by Rick H on YouTube.

Once you understand how to properly use dynamo and what it’s good at it you get so much power; at a fraction of the cost depending on your workload.

Was a breeze to setup multi region applications that utilize the single table design strategy.

If you ever need complex queries just use dynamo streams to power whatever search solution you are comfortable with.

Re: DynamoDB 10 years later

#196
post #61

Earlier quoted context omitted.

In my experience, leave DynamoDB alone and it will work great. My experience agrees with yours and I'm likewise puzzled by the grandparent comment. But just a shout out to DAX (DyanmoDB Accelerator) which makes it scale through the roof: https://aws.amazon.com/dynamodb/dax/

In my experience, NoSQL is almost never the right answer. And DynamoDB is worse than most. My prediction is that the future is in scalable SQL; CockroachDB or Yugabase or similar. NoSQL actually causes more problems than it solves, in my experience.

There are plenty of reasons when NoSQL is the right answer. The biggest is when you care more about predictable performance: https://brooker.co.za/blog/2022/01/19/predictability.html?s=...

Re: DynamoDB 10 years later

#197
post #168

Earlier quoted context omitted.

Are you calling the person who did the core DynamoDB Technical Deep Dive sessions at reInvent, for the last 4 years in a row, a sales person?

What do you think Solutions Architects and Developer Advocates (between the two groups who do most Re:invent sessions) are? Hell, what do you think re:Invent is? It's a sales conference. In any company you have two groups of people: Those that build the product, and those that sell it. Ultimately, solutions architects and developer advocates are there to help sell the product. Of course Amazon is customer obsessed. A…

I think I understand now why he left...

Re: DynamoDB 10 years later

#198
post #89

Earlier quoted context omitted.

Dynamo is incredibly hard to use correctly I’d urge you to start writing a prototype, a lot of your assumptions might get thrown out the window. Dynamo is not necessarily good for reading high volume. You’ll end up needing to use a parallel scan approach which is not fast.

I'd say Dynamo is extremely good at reading high volume, with the appropriate access pattern. It's very efficient at retrieving huge amounts of well partitioned data using the data's keys, but scanning isn't so efficient.

You can only ever fetch 1MB of data at a time though, even when using the more efficient query method (as opposed to scan). If your individual entities are not very tiny, it is hard to get for instance 2M items back in a reasonable amount of time.

Re: DynamoDB 10 years later

#199
post #168

Earlier quoted context omitted.

Do you expect the engineers on your team to know the top sales person at your company? This person might be responsible for the majority of evangelism and revenue for the company. Do you expect the SDEs to know about him? Again, no shot against against Rick - he is amazing, smart, technical, competent, and a deep owner. But the average SDE on the team won't know about these or watch these talks. There are too many de…

Are you calling the person who did the core DynamoDB Technical Deep Dive sessions at reInvent, for the last 4 years in a row, a sales person?

There are over a thousand breakout sessions at every reinvent every year. Some of the speakers are sales people, some are engineers, some are managers. There are L5 or junior engineers who give reinvent session talks. It's a fun gig, but it doesn't mean that the speaker is some top executive or anything like that.

Rich was in the sales org. His primary job was sales. Reinvent is a sales conference. Speaking at reinvent is a sales pitch. He was a salesperson. I'm not sure why you're so offended by that. Being a salesperson isn't bad, it's just an explanation for why engineers wouldn't have heard of him.

Re: DynamoDB 10 years later

#200
post #81

Earlier quoted context omitted.

"And way too many operational issues." I've seen this kind of thing mentioned many times, pretty baffling TBH based on Dynamo's pretty good reputation in industry. Are these mostly to the stateless components of the product, or do they see data loss?

I can't say in risk of violating some NDA but a lot of it is internal stuff that customers will never even be aware of or it would require too much effort for them to break. There are times when bad deployments happen and customers were impacted.

Careful about running your systems in us-east-1, folks
Post reply on HN