Great write-up! Never really thought of it from that perspective. I do see another scenario where this won't be the case and that is with Single Table design where you have many different entities stored in the same table.
You would have to scan through all records, just to find the "type" of record you are looking for. Which isn't the end of the world and might still be cheaper than doing a scan as yo u pointed out but it might/will be slower than a Query and GetItem which is O(n).
So I guess it comes down to context as you said, I still believe that discouraging scans are bad, unless you really know what you are doing. Especially for those coming from a relational world. They soon realize that Dynamo is very "restrictive" that they can not just "where" and "group" as they like. Then they turn to scan for every operation (I have actually seen this in the wild a few times)
Good point. With Single Table Design, it probably makes no sense to scan except when exporting the full datastore. The hash key should be designed so that Query is the "get a set of items" optimal operation. But a DynamoDB table should not be compared to a SQL tables but to a datastore. Thus a Scan is actually like scanning the whole database.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great write-up! Never really thought of it from that perspective. I do see another scenario where this won't be the case and that is with Single Table design where you have many different entities stored in the same table.
You would have to scan through all records, just to find the "type" of record you are looking for. Which isn't the end of the world and might still be cheaper than doing a scan as yo u pointed out but it might/will be slower than a Query and GetItem which is O(n).
So I guess it comes down to context as you said, I still believe that discouraging scans are bad, unless you really know what you are doing. Especially for those coming from a relational world. They soon realize that Dynamo is very "restrictive" that they can not just "where" and "group" as they like. Then they turn to scan for every operation (I have actually seen this in the wild a few times)
Good point. With Single Table Design, it probably makes no sense to scan except when exporting the full datastore. The hash key should be designed so that Query is the "get a set of items" optimal operation. But a DynamoDB table should not be compared to a SQL tables but to a datastore. Thus a Scan is actually like scanning the whole database.