jmhummel
commented
5 years ago Not sure why you are converting to binary before calculating the string length, as far as I know it's based on the length of the number directly, not its binary representation
Should be fixed now by this PR: https://github.com/mcwhittemore/dyno-item-size/pull/7
Also trailing 0 should be removed only if they are after the decimal point, not if let's say the number is 1000.
Not sure I agree. Based on the official docs, all numbers are stored as decimals in Scientific Notation. So 1000 should be in the form as 1E3 (1 * 10^3).
It at most, take up two bytes, one for the significant, and one for the signed exponent. So perhaps, in decimal: 1 131 (3 represented as 131 when signed with the first bit), hex: 0x0183, and binary: 0000 0001 1000 0011
However, It's representation in Dynamo may be only one byte if they are doing something clever with the extra bits (only 7 needed to represent two digits). It wouldn't surprise me if AWS took advantage of any unused bytes to further reduce the size.
Not sure why you are converting to binary before calculating the string length, as far as I know it's based on the length of the number directly, not its binary representation. Also trailing 0 should be removed only if they are after the decimal point, not if let's say the number is 1000.
In any case, I have a item that Dynamo report using 10 write unit, but in your tool it report 27 write units and 26657bytes: