[外语]节约了5分钱，但是Code却不可读了 ---转
I found myself reading this post, and at some point, I really wanted to cry:
We had relatively long, descriptive names in MySQL such as timeAdded or valueCached. For a small number of rows, this extra storage only amounts to a few bytes per row, but when you have 10 million rows, each with maybe 100 bytes of field names, then you quickly eat up disk space unnecessarily. 100 * 10,000,000 = ~900MB just for field names!
We cut down the names to 2-3 characters. This is a little more confusing in the code but the disk storage savings are worth it. And if you use sensible names then it isn’t that bad e.g. timeAdded -> tA. A reduction to about 15 bytes per row at 10,000,000 rows means ~140MB for field names – a massive saving.
Let me do the math for a second, okay?
A two terabyte hard drive now costs 120 USD. By my math, that makes:
- 1 TB = 60 USD
- 1 GB = 0.058 USD
In other words, that massive saving that they are talking about? 5 cents!
Let me do another math problem, oaky?
Developer costs about 75,000 USD per year.
- (52 weeks – 2 vacation weeks) x 40 work hours = 2,000 work hours per year.
- 75,000 / 2,000 = 37.5 $ / hr
- 37.5 / 60 minutes = 62 cents per minutes.
In other words, assuming that this change cost a single minute of developer time, the entire saving is worse than moot.
And it is going to take a lot more than one minute.
Update: Fixed decimal placement error in the cost per minute. Fixed mute/moot issue.
To those of you pointing out that real server storage space is much higher. You are correct, of course. I am trying to make a point. Even assuming that it costs two orders of magnitudes higher than what I said, that is still only 5$. Are you going to tell me that saving the price of a single cup of coffee is actually meaningful?
To those of you pointing out that MongoDB effectively stores the entire DB in memory. The post talked about disk size, not about memory, but even so, that is still not relevant. Mostly because MongoDB only requires indexes to fit in memory, and (presumably) indexes don’t really need to store the field name per each indexed entry. If they do, then there is something very wrong with the impl.
我无意间看到一篇文章，里面有些观点，读来让我想哭：
MySQL里的命名都有点长，带有描述性，例如timeAdded或valueCached。对于不多的数据来说，每行只会多占用几个字节，但当你有1亿行时，每行用100个字节存字段名，这样一下子就白白用掉了你的硬盘的大量空间。仅仅是字段名就用掉了100 * 10,000,000 = ~900MB！
如果我们把名称减到2-3个字符，这也许会使代码变得有点难懂，但节省下来的硬盘却是物有所值的。使用一些简炼的名称看起来也不是那么糟，例如timeAdded -> tA。每行节约15个字节，那么一亿行就意味着只从名称上就能省大约140MB， – 一个很大的节省。
让我们花几秒钟做道算术题，好吗？
一个2TB的硬盘目前价值120美元。根据我的数学知识，我得出：
- 1 TB = 60 美元
- 1 GB = 0.058 美元
换句话说，他们说的这很大的节省是多少呢？5分钱！
那么，让我们来做另外的一道算术题吧。
一个程序员每年的劳力成本大概是75,000美元。
- (52 周 – 2 周假期) x 40 工时 = 2,000 工时每年。
- 75,000 / 2,000 = 37.5 美元 / 小时
- 37.5 / 60 分钟 = 62 美分每分钟。
换句话说，假设这个改变要花费一分钟的程序员的时间，那整个的节省还不及消耗的。
而且肯定花费的时间不止一分钟。
有些人指出实际的服务器磁盘空间要更贵一些。当然，你说的没错。我只是在简单的说明一个问题。即使假设按你说的价格再高出2个数量级，那也只有5美元。难道你要对我说省下这一杯咖啡的钱很有意义吗？
有人指出MongoDB为了提高效率，把整个数据都加载到了内存里了。这篇文章谈论的是磁盘空间，可没说到内存，但即使这样，那也没关系。因为MongoDB只是把索引放到了内存里，但我想(推测的)每行索引里并不需要存储字段名。如果它真的存了，我想它们的实现方式里肯定有严重的错误。
