Java 存储大量资金总额和内存/存储影响-BigDecimal vs Integer和最佳实践？

BigDecimal

类是Java中处理货币单位的标准方法。然而，当存储大量数据时（每个用户有数百万～数十亿条条目），与诸如

int

之类的原语相比，必须考虑额外的存储空间：根据答案，单个

BigDecimal

对应于大约

36+上限（log2（n）/8.0）

字节（不包括一些元数据描述符等），而

int

通常是

4

字节

当存储数以百万计的条目时，这当然会导致非常显著的增加，不仅是内存使用量，而且是存储空间（例如，将MongoDB与该类型的描述符一起使用，或使用PostgreSQL

numeric

类型，该类型似乎至少对应于

8

字节，我不熟悉例如Cassandra，因此我不确定其存储含义）

使用

BigDecimal

类型的另一种选择是存储整数形式的美分（或选择最小面额的任何形式，即

$1==10000百分之一美分

，根据精度要求）。这不仅可以减少程序的压力，还可以减少数据集中除最大值以外的所有值所需的存储（这些值无论如何都是异常值，可能需要单独处理）

这是一个可行的替代方案吗？在这种情况下，是否有任何必须避免的陷阱？这种方法是否符合现行标准（例如外部审计）

注：这仅适用于存储数据，根据各种因素（即地区，例如，我们为31383.22美元），数据仍将以适当的格式显示给用户。

• 在数据库端，DECIMAL没有问题（不过可能在NOSQL数据库中）
• 在java方面，如果您不在内存中保存大量数据，则BigDecimal也没有问题。另外，对于int范围内的普通数字，BigDecimal与字符串相当。这些都是可以接受的小对象，java可以很好地处理

美分是可行的，但不能完全避开大小数。大多数国家都要求像税收这样的金融计算有一定的精度，比如6位小数。 标准java组件也不提供“虚拟”小数点。 从标准输出/输入JSF到JasperReports等等

应该提到的是，BigDecimal的用法也是冗长的

因此，我将从BigDecimal开始，以快速获得一个工作系统，并且仅在大量的“电子表格”工作上恢复为美分