对Google算法优越性的一点小体会

zszyj

原帖由 haiyan_qi 于 2008-6-26 10:41 发表
不知道zszyj到底是在阐述一个什么观点，算法无用论吗？

我阐述的观点其实很简单, 对于普遍性的问题, 如果成熟的解决方案已经满足要求,没有必要花很大的代价另辟蹊径。技术人员的精力不应该放在这种低收益的工作上．
另外，数据库并不代表没有不重视算法，　恰恰数据库里大量的算法，才是已经证实行之有效的，适合管理大规模数据量，适合在大规模数据量上进行查询，统计和更新．
目前为止，前面各位所提到的所谓ＨＡＳＨ算法，本质上都是原始的内排序算法，并不适合大规模数据上的应用，也没有实际案例证实其行之有效．
总结一点就是，　不要轻视成熟的技术方案，　如果要采用未经证实的技术，最好先综合考虑和验证其技术，经济及管理方面的可行性，　再作结论．

zszyj

原帖由 zszyj 于 2008-6-26 11:11 发表

我阐述的观点其实很简单, 对于普遍性的问题, 如果成熟的解决方案已经满足要求,没有必要花很大的代价另辟蹊径。技术人员的精力不应该放在这种低收益的工作上．
另外，数据库并不代表没有不重视算法，　恰恰数 ...

我看有些人还是没弄明白我的观点, 特转贴一个小品文, 希望大家能有所启发.

[转贴]


在遥远的古希腊，有一天柏拉图正在学院里看书，停下来休息的时候，正看到他的学生亚里士多德从外面走来。
亚：老师，马其顿王刚才有个任务交给我们，让我们处理一下学院内所有学生的资料。老师，我们怎么做呢？我听说遥远的东方那边有一个新东西，叫关系数据库，据说还不错，我们是不是拿来用一下。
柏：撇了撇嘴角：切，我们伟大的希腊，伟大的柏拉图学院怎么会用它们的东西，不就是存一些学生的数据么，我们自己来解决。你过来，我们设计一下。
亚走进前来，柏从书架上拿出一卷羊皮纸，开始画图，并给亚解释：嗯，你看我们在羊皮纸上顺序的存所有的学生，然后给每个学生编一个连续的号码，然后直接根据学号跳到对应的页数，不就可以了么。这样的效率可是O(1)的。听说那个数据库光准备阶段就要10张羊皮纸，还得把一些张做成服务型，真是没必要。慢死了。
亚：可是老师，如果某些学生被征去兵役，或者病死，那不是中间的某些号码就要缺失了么？
柏：嗯，这是个问题，这样吧，我们依旧要顺序存储，但是是排序的，找的时候像查字典那样，对半翻，这样效率也可以达到O(lgN)。怎么样？
亚：这样很好，不过我们可能会在前面插入学生的，因为听说那些长老院的子弟很喜欢带8的数字，他们一定会插到前面的。
柏：那我们可以做成链接的，有一个索引的表，就像两千多年后的B+树那个样子，这样就解决了插入的效率问题。。
亚：老师，可是。。
柏：你怎么这么多问题，真是的。
亚：老师，我是说，你连2000年后的事情都知道，真是希腊最伟大的哲学家！
柏：呵呵。。
亚：对了，老师，但是王一般都是按着名字来找人的，那我们怎么办？
柏：嗯，这个难不住我，我们另建一个索引表，把名字进行HASH查找，这样的效率是近似于O(1)的。
亚：老师真厉害，不过王还需要根据别的多个条件，比如大于18岁，家里父母健在的要去服兵役的。
柏：这个王也够麻烦的，那我们创造一个结构化查询语言好了，就叫他SQL好了，他的语法是这样这样的。。。。，对了，还得弄个接口去解释他。还有，后面那些东西业的弄个东西去管理。
不知不觉中，柏所画下的图已经铺满了整个大厅。
亚：老师，可是我听说东方那个关系数据库就是这个样子的，既然这样，我就去东方学系好了，因为听说他们已经作了很多年了，应该有很多人用！
说完，亚转身走出了学院，对这遥远的东方，亚喃喃自语：吾爱吾师，吾更爱真理！

flw

圣人之道是什么？就是中庸！
如果我是决策者，我会采纳 zszyj 的建议，我觉得他的想法很对，让他去实施这个项目好了。
同时我也会给他的反对者一定的时间和资金，去做前瞻性的预研。当然如果公司资金紧张那就算了。

haiyan_qi

原帖由 zszyj 于 2008-6-26 11:11 发表

我阐述的观点其实很简单, 对于普遍性的问题, 如果成熟的解决方案已经满足要求,没有必要花很大的代价另辟蹊径。技术人员的精力不应该放在这种低收益的工作上．
另外，数据库并不代表没有不重视算法，　恰恰数 ...

呵呵，你以为数据库可以解决所有的问题吗？在所谓的（恶心的）“企业级应用”系统中，数据库确实是包打天下，但是你觉得Google,baidu这样的应用会用Oracle这类的数据库吗，这类的数据库适合Google那样的应用吗？

请你弄清楚你所谓的成熟的解决方案是那类问题的解决方案。

所谓的企业级应用的并发性和单位时间内的访问量跟Google这类的应用能比吗？有可比性吗？

haiyan_qi

原帖由 flw 于 2008-6-26 11:50 发表
圣人之道是什么？就是中庸！
如果我是决策者，我会采纳 zszyj 的建议，我觉得他的想法很对，让他去实施这个项目好了。
同时我也会给他的反对者一定的时间和资金，去做前瞻性的预研。当然如果公司资金紧张那就 ...

Oracle跟联通要6000万美金，你好像比联通还有钱。

haiyan_qi

是不是你觉得Google的人都是白痴，有现成的技术不用，非要自己搞什么GFS,big table，看来应该请你去做Google的首席技术官。

zszyj

原帖由 haiyan_qi 于 2008-6-26 11:52 发表



呵呵，你以为数据库可以解决所有的问题吗？在所谓的（恶心的）“企业级应用”系统中，数据库确实是包打天下，但是你觉得Google,baidu这样的应用会用Oracle这类的数据库吗，这类的数据库适合Google那样的应 ...

google使用的是LINUX+MYSQL, 虽然不用ORACLE, 但MYSQL不算是数据库吗?

cugb_cat

google也用数据库啊，他们好像自己修改mysql？

shan_ghost

有做硬件的吗？咱们一起做个项目吧。

硬件需求为100MHZ以上的CPU，200M内存，一个100M网卡；耗电量没要求，越高越好～～


软件我来做。一个bloom filter而已。

预计支持1亿用户名的冲突检索。100，000，000用户 × 16bit /8 = 200,000,000字节=200M字节。
这个数字按10进制算的。加上嵌入操作系统和软件代码，200M字节的按16进制算的内存（通常用256M这个整数）应该还能余下不少。没事咱可以做几个俄罗斯方块之类小游戏放里面当彩蛋～～


成本嘛，除去软件，限制在100元以内——现在的技术想必还是很容易做到的。


做完了，估计看起来也就和一个usb硬盘差不多；这玩意儿要卖10万8万的，怎么也显得有点不太厚道～


咱再整一大铁箱子，里面放10套咱这系统做成热备；剩下的空间做成水箱，里面放根电炉丝～～
这系统一跑起来，跟茶炉子似的，还得一个人专门负责添水——那叫一个帅～～
搬次家至少得10个人抬，里面冷却水哗楞哗楞直响，倍儿有面子～～


你说咱这玩意儿得卖多少？
什么？你说2000？您也太看不起数据库大佬们了！

甭说小型机了，就一中等档次的服务器得多少？买一份oracle多cpu核心licensing要多少？光这份licensing，够不够咱做上百套的？！

再说了，咱这东西，只需要8个hash运算+8次内存访问+8次位与——没细算，跑到微秒级想必不成问题。

再怎么说，咱这茶炉子——错，是超级热备字符串冲突检索系统——至少也得卖个10万8万吧？


咱还真不卖8万。
中国制造嘛，打的就是价格战，薄利多销嘛——跳楼出血大甩卖：6万，一口价，还不打折！
当然了，回扣可以商量，国情嘛。

——刚才谁说俺那是水货？俺的茶炉子里装的不是水，是知识。
知识无价。

shan_ghost

呵呵，开个玩笑而已。

仅仅做用户名检测的话，怎么都行，但最便宜还是bloom filter。

要几十上百万的上高级服务器+oracle的话，养那些一个月几万的软件工程师干嘛？


现在我们说的是gmail，不仅仅是一个字符串查询。

它的设计目标咱不清楚，但想必应当是上亿乃至数十亿用户。
每个用户1G邮箱空间，按每个电子邮件百K字节算，可存上万的邮件——继续用数据库吗？

每个用户每天都要被数十甚至数百上千封垃圾邮件骚扰；已知的发送垃圾邮件的地址有几十亿个——继续和用户名查询挤一个数据库吗？您还能保证响应速度在ms级吗？

这还不考虑google早已有了big table等高效算法。

现在，算算成本吧。