com.sleepycat.je.tree

Class StorageSize

java.lang.Object

com.sleepycat.je.tree.StorageSize

public class StorageSize
extends Object

Contains static methods for estimating record storage size. Currently this only applies to KVS because we assume that VLSNs are preserved.

Method Summary

Modifier and Type	Method and Description
static int	getStorageSize(BIN bin, int idx) Returns the estimated disk storage size for the record in the given BIN slot.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

getStorageSize

public static int getStorageSize(BIN bin,
                                 int idx)

Returns the estimated disk storage size for the record in the given BIN slot. This method does not fetch the LN.

For KVS, a formula that customers will use to predict the storage for a given set of records, not including obsolete size (size available for reclamation by the cleaner), is as follows.

The storage overhead for a single Row (JE primary record) is:

  Serialized size of the Row, all fields (JE key + data size)
    +
  Serialized size of the PrimaryKey fields (JE key size)
    +
  Fixed per-Row internal overhead (64: LN_OVERHEAD + PRI_SLOT_OVERHEAD)
 

The storage overhead for an Index record is:

  Serialized size of the IndexKey fields (JE key size)
    +
  Serialized size of the PrimaryKey fields (JE data size)
    +
  Fixed per-IndexKey internal overhead (12: SEC_SLOT_OVERHEAD)
 

This method returns the size estimate for an actual record based on the use of that formula, getting the key and data size (or lastLoggedSize) from the BIN. The amount calculated using the formula above will normally be larger than the size returned by this method, for several reasons:

• This method uses the key size after it is reduced by prefix compression.
• For a separate (non-embedded) LN, this method uses the lastLoggedSize rather than adding LN_OVERHEAD to the data size (this is why LN_OVERHEAD is not referenced in code here). This is more accurate since the actual LN overhead is reduced due to integer packing, etc. Also, this method cannot fetch the LN, so the data size is unknown.
• For an embedded LN in a primary DB, the returned size does not include the LN size, since the LN is always obsolete. This means the primary key size is not counted redundantly and the LN_OVERHEAD is not included in the return value, as they are in the formula. These are significant differences, but since embedded LNs require a data size LTE 16, this is not expected to be a common use case. If it becomes common, we should add a new case for this to the customer formula.

In addition, the size returned by this method will normally be larger than the actual storage size on disk. This is because this method uses PRI_SLOT_OVERHEAD and SEC_SLOT_OVERHEAD to calculate the Btree slot space, rather than using the serialized size of the slot. These constant values are somewhat larger than the actual overheads, since they do not take into account integer packing, etc. See the comments above these constants. The serialized slot size was not used here for simplicity and speed, plus this additional size compensates for uncounted sizes such as per-BIN and UIN overhead.

Returns:

the estimated storage size, or zero when the size is unknown because a non-embedded LN is not resident and the LN was logged with a JE version prior to 6.0.