This document - http://www.aerospike.com/docs/operations/plan/capacity/ explains the overhead of having bins based on the number of bins and the datatype used.
I am wondering, does the bin name length affect the overall storage somehow? i.e. a record with bin names of length = 1, occupies less storage than a record with bin names of length = 14.
what are the fine details of the string table implementation that imposes the 14 char limit, 32k unique bins per ns?
I am wondering, does the bin name length affect the overall storage somehow? i.e. a record with bin names of length = 1, occupies less storage than a record with bin names of length = 14.
No, bins are stored fixed length so the actual size of the string doesn’t affect the amout of resulting storage. You may view the actual 28 bytes struct here.
what are the fine details of the string table implementation that imposes the 14 char limit, 32k unique bins per ns?
The 32K unique bin name restriction is on new bin names when the client writes a new bin. When the server replicates a bin name to a node that doesn’t have it yet there is a 64K unique bin name restriction. This is done to ensure that we will be able to safely replicate records within the cluster.
Since we write bin names in a fixed length field, the 14 byte bin name limit was chosen to be not too big or too little for typical applications.