Live data from Hacker News

A Decade of Dynamo

allthingsdistributed.com

31–40 of 58 posts

Re: A Decade of Dynamo

#31
post #27
post #21

Earlier quoted context omitted.

> Anything that can go to dynamo, can go to s3, especially at that volume. Please think very carefully before architecting your app with S3 as a makeshift-database. S3 would be a valid option if you don't care about millisecond latency; don't require safe updates; never expect your application to scale past 100 requests per second; and don't have multiple query patterns for the same data (unless you're okay with seve…

I am going to say that I did this, and will add "are willing to pay some insane amount of money to store and manipulate your data" (this was a mistake that cost me at least one if not two hundred thousand dollars).

Could you explain more please about what you mean?

Re: A Decade of Dynamo

#33
I was at AWS from 2008 to 2016. Werner Vogels, Amazon's CTO (yep, not just AWS', but Amazon's, as he had to point out numerous times) has been one of the most talented, humble and generous senior exec I've ever met in my life.

Lots of good memories of time spent with him, and one of the sad aspects for me of leaving Amazon.

His blog writings are really interesting. If you haven't already, I suggest you search the archives, there are several hidden gems there.

Re: A Decade of Dynamo

#34
Need a library sdk for a Dynamo Sync feature to allow easy development of offline mobile apps. Similar function to Cognito Sync. Also hope that AWS will release a serverless SQL db. And cheaper price.

Re: A Decade of Dynamo

#35
post #34

Need a library sdk for a Dynamo Sync feature to allow easy development of offline mobile apps. Similar function to Cognito Sync. Also hope that AWS will release a serverless SQL db. And cheaper price.

> Also hope that AWS will release a serverless SQL db.

You mean like RDS?

Re: A Decade of Dynamo

#36
Congrats to aws on the impact DynamoDb has had on the ecosystem & industry. The article does make it seems like DynamoDb was the first to publish a unique noSQL architecture. Is this true?

Re: A Decade of Dynamo

#37
post #22
post #11

Earlier quoted context omitted.

This is the good side of Dynamo, and it's awesome that you've had that experience. The flip side: Dynamo gets expensive and it gets expensive quick , and being a custom API (and, indeed, a very different way to think about datastores) makes migration difficult. It's great to use, if you understand the tradeoffs. Just make sure you understand them before you make the leap.

>Dynamo gets expensive and it gets expensive quick, DynamoDB's pricing scales sublinearly with volume; if it starts getting expensive it was an initial misuse of DynamoDB that got obvious with scale. There are a lot of factors that go into whether you should use DynamoDB and how you implement it. I recommend anyone who is considering using it very carefully understand this page first: http://docs.aws.amazon.com/amazo…

This is how enterprise developers use the database, sometimes:

https://thedailywtf.com/articles/The-Query-of-Despair

You do this on your own server, slowness and bad performance are the result (but it may never, or very rarely get called). You do it on dynamo, a $10k bill may be the result.

Re: A Decade of Dynamo

#38
> The Dynamo paper was well-received and served as a catalyst to create the category of distributed database technologies commonly known today as "NoSQL."

No, sorry, it was Memcached and Bigtable paper that popularized "NoSQL" term. Although there were many NoSQL databases tracing way back to 60s [1], those were the ones that "served as catalyst" for the term "NoSQL".

[1] http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.h...

Re: A Decade of Dynamo

#39
post #9

I don't know why amazon is so taken with Dynamodb. I find it to be incredibly unintuitive and lacking real world application, requiring applications to perform gymnastics to work with it.

I've found just the opposite actually. While it's far from perfect, it has been amazing for rapidly standing up new apps (especially prototypes). We've used quite a few different strategies and found it to be flexible and performant. The only downside is we do find ourselves sometimes implementing relational DB functionality at the application level to compensate for Dynamo DB's "flexibility." Postgres is still the g…

Prototypes are far bettered suited with Postgres or Mysql on RDS. When you don't know your schema or your use case upfront, traditional databases are far easier to work with, since you can change them. Once you know what your doing scaling up works far better on something like Dynamo or Cassandra, but you will be sacrificing dev time

Re: A Decade of Dynamo

#40
post #11
post #10

DynamoDB is amazing for the right applications if you very carefully understand its limitations. Last year I built out a recommendation engine for my company; it worked well, but we wanted to make it real-time (a user would get recommendations from actions they made seconds ago, instead of hours or days ago). I planned a 4-6 week project to implement this and put it into production. Long story short: I learned about…

This is the good side of Dynamo, and it's awesome that you've had that experience. The flip side: Dynamo gets expensive and it gets expensive quick , and being a custom API (and, indeed, a very different way to think about datastores) makes migration difficult. It's great to use, if you understand the tradeoffs. Just make sure you understand them before you make the leap.

[deleted]
Post reply on HN