Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DynamoDB 10 years later

amazon.science

Post reply on HN
Print view View original

221–225 of 225 posts

Re: DynamoDB 10 years later

#221

Post by leetrout »

jd_mongodb wrote: post #213
leetrout wrote: post #202

Earlier quoted context omitted.

Not snark: did MongoDB ever go away? I've seen it used in many places over the years. Today I would choose JSON in Postgres before I would just jump to Monogo but it certainly serves a purpose for many shops and it is still widely used AFAIK. I _really_ miss RethinkDB.

What do you miss about RethinkDB?

The table model with joins that mostly "just worked" and the sweet web ui that came with it by default.

Hat tip for compass, very nice tool I was just losing last week.

We use Atlas and it "just works" so no comment on administering mongo vs rethink haha.

Re: DynamoDB 10 years later

#222

Post by oriettaxx »

The only experience I had with dynamodb has been in aws: we set up a testing DB with defaults... then we left it there.... two months later we realized we've lost about 1500$: our mistake was to use the setup defaults (which had some sort of auto-scaling): I hope in the meanwhile AWS corrected this: we did let them know)

Re: DynamoDB 10 years later

#223

Post by cmollis »

Jach wrote: post #143
cmollis wrote: post #91

we use DynamoDB like a big hash table of s3 file locations.. we look up these locations via a key (at the time, it sounded like a pretty good use-case for it). I suppose we could have used some other managed redis or memcached thing, but being an AWS shop, it was, and is, pretty useful. I have to say, it's been pretty effortless to configure.. read/write units are really the only thing we've had to configure (other t…

I remember talking to someone who was playing with AWS stuff for the first time and they had a similar architecture, using Dynamo for a lookup store. It still seems a bit odd to me though. It's been a long time since I've worked with the S3 API, so maybe it just doesn't support the same sort of thing, but wouldn't it be nicer to just query S3 with some key and get back either the path/URL to render a link, or the con…

You're not going to get O(1) lookup using the S3 API. The APIs are basically O(n). So we we use DynamoDB to store the S3 URL.

Re: DynamoDB 10 years later

#224

Post by cmollis »

cmollis wrote: post #223
Jach wrote: post #143

Earlier quoted context omitted.

I remember talking to someone who was playing with AWS stuff for the first time and they had a similar architecture, using Dynamo for a lookup store. It still seems a bit odd to me though. It's been a long time since I've worked with the S3 API, so maybe it just doesn't support the same sort of thing, but wouldn't it be nicer to just query S3 with some key and get back either the path/URL to render a link, or the con…

You're not going to get O(1) lookup using the S3 API. The APIs are basically O(n). So we we use DynamoDB to store the S3 URL.

Moreover, storing a large binary file (in this case) in Dynamo is probably not the best use-case for it..most likely would have to convert to base64 in and out of it.

Re: DynamoDB 10 years later

#225

Post by SomeCallMeTim »

deanCommie wrote: post #196
SomeCallMeTim wrote: post #180

Earlier quoted context omitted.

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=...

As long as you consider "can just fail if it gets too busy" to be "predictable."

Which I don't. I'd rather see reliable operation than "predictable except for when it fails outright" in almost every situation.

If you've encountered that other situation, where failures are fine? Then great. But I still assert that's a tiny minority of real-life DB use cases.

Post reply on HN