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).
A Decade of Dynamo
31–40 of 58 posts
Re: A Decade of Dynamo
#32Re: A Decade of Dynamo
#33Lots 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
#34Re: A Decade of Dynamo
#35Need 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.
You mean like RDS?
Re: A Decade of Dynamo
#36Re: A Decade of Dynamo
#37Earlier 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…
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
#38No, 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
#39I 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…
Re: A Decade of Dynamo
#40DynamoDB 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.