我无意间看到一篇文章,里面有些观点,读来让我想哭:
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只是把索引放到了内存里,但我想(推测的)每行索引里并不需要存储字段名。如果它真的存了,我想它们的实现方式里肯定有严重的错误。
哈哈,有意思,看来简短难懂的字段名的确没啥意义啊!
被批判的作者已经写了篇 Blog 回应了:
http://blog.boxedice.com/2010/10/23/on-shortened-field-names-in-mongodb/
简单总结下:
1. 计算本身有问题,远不止 5 分钱
2. 对高级 Server 来说,硬盘空间很贵
3. 如果加上 backup,shard 等考虑,浪费的硬盘会倍增
4. 对 starup 来说,这些多出来的钱可能就是活下去的关键
5. 完全可以从程序里加一层来把简写的表名等映射到代码里的完整的有意义的名称。这样既省了空间,又让代码可维护。
6. 对 mongodb 来说,更重要的是它会用内存来做 cache,节省空间不但能节省硬盘,更能充分利用内存来 cache 更多的数据。
好文,顶了~
本来,缩写是为了节约人的时间,比如函数名doSearchEngineOptimization() 肯定不如 doSEO() 来得快,来得直接,更节约人力成本。
不过真是为了节约存储空间,非要吧 userName 改为 un,把 regDate 改为 rd……就太过分了。
那 userNote 怎么办? un2?recordDate 怎么办? rd2?那真是灾难啊!
字段名每行都重复一遍????
you got the point. 这个显然是不懂数据库设计实现的人造出来的故事。
MongoDB这种NoSql会每次都重复记录字段名
服务器硬盘不是桌面硬盘。你查一下SAS 15K硬盘的价格,一般还要做个raid10,算算这个成本。
而且他举例1KW行不代表真的只有1KW行,海量存储随便都要上PB
raid啥?hadoop ,mongo这些都不用raid的
而且我看楼主引用的那段翻译得面目全非,估计对原文理解得也不会透彻,还是不要随便“发布在 幽默讽刺”,有时觉得好笑是因为自己不懂
被批判的对象已经写了篇 Blog 回应了
简单总结下:
1. 上面的计算公式本身有问题,远不止 5 分钱这么少
2. 对高性能 Server 来说,硬盘空间很贵
3. 如果加上要对数据库进行 backup,shard 等,浪费的硬盘会倍增
4. 对 starup 来说,这些多出来的钱可能就是活下去的关键
5. 完全可以从程序里加一层代码,把数据库里简写的表名映射到代码里的完整的有意义的名称。这样既省了空间,又让代码可维护。
6. 对 mongodb 来说,更重要的是它会用内存来做 cache,节省空间不但能节省硬盘,更能充分利用有限的内存来 cache 更多的数据。这个对运行效率有很大影响
我是外行
我想知道
需要写一亿行代码的项目
大概需要投资多少钱
不是说一亿行代码,而是随着用户增长,该写法导致在需要存储一亿条数据时多浪费了些硬盘空间。
还没听说有1亿行代码的项目,如果真有这么大的项目,预计需要花费数十亿或者更多,可能这个项目因为太庞大复杂度成几何级数上升根本无法完成。
类似于这样的问题,谁都能列出很多支持的/不支持的理由,只好当时权衡一下了。
很好,就因为英语这道门槛,无法读懂IT外文,工作人员们你们很优秀,谢谢你们
如果有必要,不能在MySQL层面上自动做优化么?简单的压缩处理而已。
据说如果微软把所有文档中的Microsoft都换成MS的话,文档缩小很多。。。当然,这只是个笑话。
程序是给人读的,只是凑巧机器也能执行。
程序是给人读的,只是凑巧机器也能执行。
所以我们现在新的数据库表名/ 字段名都 直接用汉字
直接用汉字做表名和字段名我持保留意见,可以假想下你看到某种火星文写的scheme时的感受,而如今的软件一不小心就要被国际化了。
对server来说,SQL节省的空间哪怕是1MB,也是非常珍贵的。
还没算维护的代码的成本呢.
如果要去数据库看看数据,还要根据映射表才知道字段的含义. 真会让人发疯的
同意,一个项目开发还是比维护简单的
MySQL 将数据存在 *.frm, *.MYD, *.MYI 三种文件之中,而 timeAdded 或 valueCached 应该只是记录在 *.frm 里,再以自动产生 id 的方式与 *.MYD 的相同 id 简单做连结。
这样基本的数据关联的概念 MySQL 的开发人员应该不会不懂,所以名称的长度应该不致于会影响数据库的储存容量,否则如果要改名称,这一亿行时的数据不就要储存好几个钟头。
适当精简还是有好处的,甚至只用26个字母代替字段名都行,只要我们写一份文档说明这26个字母分别代表什么就可以了。甚至每个字段的值都可以全部用数字来代替。
这个人是项目管理人员, 而要求执行变更的是技术开发人员。
对开发人员来说,少用一个字节都是一种成就。
在80年年,能少用一个字位,他们都可以多花上一天的时间
顶,你是对的楼主。更多的技术“大牛”做这种所谓的优化,只不过是自欺欺人罢了。应为他已经没有更多更好的知识来体现自身价值了。
很多时候我们总是花了太多时间去浸淫在所谓的“高超技术”上,早已忘了,技术只不过是工具罢了,本末倒置
战斗机操作系统