abd12

278 ms·

1.
IBM to acquire Confluent(confluent.io)
449 points by abd12 9mo ago|362 comments
2.
by abd12 4y ago
I always tell people there are two clear areas where DynamoDB has some major benefits: - Very high scale applications that can be tough for an RDBMS to handle - Serverless applications (e.g. w/ AWS Lambda) due to how the connection mod
3.
Inconsistent Thoughts on Database Consistency(alexdebrie.com)
2 points by abd12 4y ago|0 comments
4.
Does Laravel Scale?(usefathom.com)
44 points by abd12 4y ago|5 comments
5.
by abd12 5y ago
One difference with DynamoDB is that there's no query planner, so you can have a pretty good sense of how many items you'll hit and how big that read is.
6.
by abd12 5y ago
Nice post! Question for you -- what are the performance implications of "re-keying" my records during the transform? Should I try to keep the same key for my transformed record as from my original record so that they align with th
7.
by abd12 6y ago
Wow! Congrats to you, Jay and Frank. I've been a fan of your work on both Seed.run & Serverless Stack for a while. Best of luck, and I'm excited to see Seed grow :)
8.
by abd12 6y ago
I highly recommend this book and Swyx's other work. He's thorough while also distilling down to the most important bits. Great book for people that are just starting their coding career but also for those with a good bit of experi
9.
by abd12 6y ago
Yep! There are entire chapters on sorting & filtering. Note: it's different than in a relational database, but it's doable :)
10.
by abd12 6y ago
Yep! It comes with PDF, MOBI, and EPUB formats :)
11.
by abd12 6y ago
It depends! For me, I like that 98% of DynamoDB work is frontloaded. I spend the time building the model but once it's done -- set it and forget it. With RDBMS, it's like there's a hidden 5% tax that's lurking at all tim
12.
by abd12 6y ago
Thank you! I really appreciate it :) Hit me up if you have any questions!
13.
by abd12 6y ago
Haha, I love that story at the end. I promise not to tell your company that it is a database.
14.
by abd12 6y ago
luhn responded to this one pretty well :) Basically, most of these issues are gone. As long as you don't have extreme skew in your partition keys, you don't need to worry about throughput limits.
15.
by abd12 6y ago
I recommend On-Demand pricing 'until it hurts'[0], but that's because a ton of people I talk to are spending <$50/month on DynamoDB. At that point, it really doesn't make sense to spend hours of time optimizing y
16.
by abd12 6y ago
Daniel, I'm a big fan of yours but disagree with this take :). It's definitely a database. The modeling principles are different, and you won't get some of the niceties you get with a RDBMS, but it still allows for flexible q
17.
by abd12 6y ago
All the examples are specific to DynamoDB and use DynamoDB features. That said, the principles apply pretty well to other popular NoSQL databases, especially MongoDB and Cassandra. There will be some slight differences -- MongoDB allows bet
18.
by abd12 6y ago
True! I'm not a huge fan of Aurora Serverless and the Data API. The scaling for Aurora Serverless is slow enough that it's not really serverless, IMO. And the Data API adds a good bit of latency and has a non-standard request &a
19.
by abd12 6y ago
Good point! I would usually not recommend using a database from a different cloud provider just because of different hassles around permissions, connections, etc. I've never found the speed an issue, but YMMV. To me, the best thing is
20.
by abd12 6y ago
Awesome! Hit me up if you have any questions :)
21.
by abd12 6y ago
I can understand the sentiment and don't fault you for it. That said, I think you can definitely handle complex, relational patterns in DynamoDB pretty easily. It will take some work to learn new modeling patterns, but it's absolu
22.
by abd12 6y ago
Thank you for your support! The biggest advice I can give you is not about any specific tool, it's about an approach. You need to think about how you will market the book if you're self-publishing. Engage with the community that w
23.
by abd12 6y ago
Thanks for your support! I'm grateful for the fix you suggested as well :)
24.
by abd12 6y ago
I'd much rather pay for reads & writes directly rather than guessing at how my CPU and RAM will translate to the reads and writes that I need. RDBMS capacity planning basically goes: 1. How much traffic will I get? 2. How much RAM
25.
by abd12 6y ago
In a nutshell: - It was designed for super high scale use cases (think Amazon.com retail on Cyber Monday). It has decent adoption there. Competes mostly with Cassandra or other similar tools. - With the introduction of AWS Lambda, it got mo
26.
by abd12 6y ago
Thank you for the kind words! :) Glad you're liking it.
27.
by abd12 6y ago
My contention is that it's much easier to have an access pattern that won't scale in a relational database than in DynamoDB. DynamoDB basically removes all the things that can prevent you from scaling (JOINs, large aggregations,
28.
by abd12 6y ago
Fair enough! I think that's a reasonable position. IMO, there are two times you should absolutely default to DynamoDB: - Very high scale workloads, due to its scaling characteristics - Workloads w/ serverless compute (aka Lambda)
29.
by abd12 6y ago
Thanks, Matthew! Appreciate it, and I agree with you :)
30.
by abd12 6y ago
Email me, and I'm happy to discuss :). alex@alexdebrie.com

More ›