缩短MongoDB数据库中的属性名称是个好主意吗？

Question

有时，我们在DB中有很多字段和大数据集（我使用的是mongoDB）。关于通过在DB中保持缩短名称来保存DB中的一些字节，我想到了一件事。 喜欢

年：年

月：mn

isSameCity：isSmCt

那么，这种方法是好还是坏。或者，这取决于案例基础。

请指导我。

Answer 1

MongoDB的一个常见性能优化策略是在文档中使用短字段名称。

  

也就是说，而不是创建一个看起来像这样的文档......

     

{first_name：＆＃34; Jon＆＃34;，last_name：＆＃34; Hyman＆＃34;}

     

使用较短的字段名称，以使文档看起来像......

     

{fn：＆＃34; Jon＆＃34;，ln：＆＃34; Hyman＆＃34;}

由于MongoDB没有列或预定义模式的概念，因此这种结构是有利的，因为字段名在数据库中的每个文档上都是重复的。如果你有一百万个文件，每个文件都有一个＆＃34; first_name＆＃34;在他们身上的字段，你将该字符串存储了一百万次。这会导致每个文档占用更多空间，这最终会影响内存中可容纳的文档数量，并且大规模地可能会对性能产生轻微影响，因为MongoDB必须在读取文档时将文档映射到内存中。

摘自objectrocket

Answer 2

引用Donald Knuth：

过早优化是编程中所有邪恶（或至少大部分）的根源。

构建您的应用程序然而似乎最合理，可维护和合乎逻辑。然后，如果您遇到性能或存储问题，请处理那些影响最大的问题，直到表现令人满意或收益递减法则意味着进一步优化没有意义。

如果您不确定特定设计决策（如长属性名称）的影响，请创建一个原型来测试各种假设（例如“将更短的属性名称节省更多空间”）。不要指望测试的结果是决定性的，但它可能会教你不想要学习的东西。

参考：Is shortening MongoDB property names worthwhile?

Answer 3

在设计数据模型时，可以避免长命名属性（或“AbnormallyLongNameAttributes”）。在我之前的组织中，我们测试了保持简短的命名属性策略，例如，组织定义了4-5个字母编码的字符串，例如：

1. 名字= FSTNM，
2. 姓氏= LSTNM，
3. 每月利润损失百分比= MTPCT，
4. 年度销售预测= YOYSP，依此类推..）

虽然我们观察到查询性能有所提高，主要是由于通过网络传输的数据大小减少，或者（因为我们使用JAVA和MongoDB）MongoDB文档/ Java Map中“密钥”长度的减少堆空间，整体性能提升不到15％。

在我个人看来，这是一种微观优化，为每个数据模型维护/设计管理数据属性字典的附加系统带来了额外的成本（巨大的麻烦）。在调试应用程序/应答客户端查询时，要求该系统具有组织范围的透明度。

如果您发现自己处于这种策略性能提升高达20％的位置对您来说是有利可图的，可能是时候扩展您的MongoDB服务器/选择其他数据建模/查询策略，或者是完全选择一个不同的数据库。