[HN Gopher] A minimalistic Python wrapper to AWS DynamoDB
___________________________________________________________________
A minimalistic Python wrapper to AWS DynamoDB
Author : nsonachalam
Score : 31 points
Date : 2021-05-30 16:36 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| qaq wrote:
| I hope DynamoDB is relegated to the niche use cases it's
| appropriate for. The hoops people are jumping through trying to
| use in place of say Aurora make for a very sad developer
| experience.
| jugg1es wrote:
| Dynamo is indeed a very powerful tool for specific use cases. A
| total heartbreak if the developer doesn't understand how/when
| to use it.
| harrisonjackson wrote:
| Agreed!
|
| Dynamodb has some really great features and high performance
| when used correctly but it also has a steep learning curve
| especially for anyone coming from sql and other relational
| databases.
|
| AWS tries to push the concept of single table design which
| allows you to store an entire application's data in a single
| dynamodb table and using a bunch of complicated indexing and
| overloading columns with multiple types of data to sort of
| get relational data without any joins.
|
| This is really easy to get wrong and you need to have all
| your access patterns figured out ahead of time so that you
| can create the indices you'll need when you create the table.
| You can't create new local indices later... only global
| secondary indices which duplicate the entire table (and
| double your storage costs).
|
| Dynamodb streams are really cool - great way to setup
| webhooks for data changes.
|
| Dynamodb pay per request is super cheap and fast for a
| serverless db. Aurora serverless isn't pay per request and
| has slow cold starts.
|
| My recommendations if you are using dynamodb because you want
| something serverless and NOT because nosql is actually the
| best storage option:
|
| * don't do single table design - just make more requests to
| different tables and join your data in code
|
| * if joining in code is too slow then use a sql database...
|
| * abstract all your data access calls so you can eventually
| migrate to a sql database
| tylerchurch wrote:
| Do you have a good recommendation for learning about what
| use cases DynamoDB makes sense for? I've used MongoDB and
| various SQL databases extensively, and when I tried
| DynamoDB it felt like a solution in search of a problem
| compared to my usual DBs of choice.
| qaq wrote:
| Problem is the way AWS is marketing it and people gobbling it
| up.
| jugg1es wrote:
| yea, the worst part is that the mistake isn't often
| realized until after the initial implementation is complete
| and it's time to iterate. The barrier to entry is very low
| so people don't bother taking the time to understand how it
| works until it's too late.
| dragonwriter wrote:
| > Problem is the way AWS is marketing it
|
| Isn't that always the case?
|
| (I especially like how they market any schemaless database
| capable of strong consistency in the CAP sense as fully
| ACID compliant RDMS alternative, because if you can't
| specify a rule making database states invalid than the
| consistency in the ACID sense is trivial because every
| database state is valid.)
| politelemon wrote:
| Can you expand on that? This is my understanding so far, feel
| free to correct it:
|
| It looks like a good place for quick key-values lookups. It's
| a "table" as a service, with 1 (or 2) columns that you can
| index on. Anything else and you need an RDBMS.
|
| It's useful for simple storage, without the overhead of
| setting up an RDS.
| isbvhodnvemrwvn wrote:
| The issue is that the keys can be used to various extent to
| handle relational data (this re:Invent video shows this
| well: https://youtu.be/HaEPXoXVf2k?t=1363). What people
| miss though is that in order to not shoot themselves in the
| foot, you have to have stable, known access patterns which
| meet the constraints of DynamoDB.
|
| Even the documentation of DynamoDB says so:
|
| https://docs.aws.amazon.com/amazondynamodb/latest/developer
| g...
|
| This means that it's a good use case for shopping cart of
| Amazon since there's limited innovation possible there and
| it fits the bill nicely, but for a new application with
| relational data where the requirements change all the time
| - it's a terrible, terrible choice for which you will pay
| dearly.
| blowski wrote:
| The problem is that at the low-end where you just want
| something cheap and simple, it's too complicated compare to
| Aurora. At the higher-end where you want something with
| extreme-performance, it's got too many weird edge cases.
|
| If you have a team of people that know how to use it well,
| I'm sure it's an excellent tool. But it shouldn't be
| casually thrown into an architecture, because there is
| nearly always a better solution.
| catlifeonmars wrote:
| Maybe I'm missing something, but looking at the examples in the
| README, I'm not sure what value this is providing over the boto3
| DynamoDB client. Why would I want to use this library over the
| SDK client?
| crad wrote:
| Looks like it's a thin wrapper on top of boto3 that removes
| some of the boto-isms.
| valbaca wrote:
| I agree. Looks to be just a pet project. It's missing the "why"
| villasv wrote:
| You lost me at the camelCase package name
| jugg1es wrote:
| do you mean PascalCase?
| politelemon wrote:
| It appears this was specifically made for use with IAM
| key/secrets; you should consider making these optional so that
| boto3 can pick up the corresponding environment variables itself.
| And you could also allow for temporary IAM credentials
| keys+secret+session.
|
| https://github.com/dineshsonachalam/Lucid-Dynamodb/blob/mast...
| orf wrote:
| The code as it stands is of course really dumb, but I think you
| can just pass `None` to each of those and have boto3 use the
| standard credential precedence.
|
| On top of that they have mutable keyword arguments and
| generally quite terrible code: no exceptions thrown, just
| logging.error(), `if len(x)` rather than `if x`, etc etc.
| TruthWillHurt wrote:
| A Dynamo wrapper must simplify AND/NOT/AND NOT filters (which are
| a pain) to be useful in my opinion
| navels wrote:
| I've been pretty happy using PynamoDB, an ORM-like wrapper with a
| straightforward interface:
|
| https://github.com/pynamodb/PynamoDB
| strictfp wrote:
| Ah, Shopping Cart DB is at it again :)
___________________________________________________________________
(page generated 2021-05-30 23:00 UTC)