Chinaunix

标题: 对Google算法优越性的一点小体会 [打印本页]

作者: zhangzhh05 时间: 2008-06-22 09:24
提示: 作者被禁止或删除内容自动屏蔽

作者: emacsnw 时间: 2008-06-22 10:37
这种比较本来就很快的吧。

作者: zhangzhh05 时间: 2008-06-22 10:46
提示: 作者被禁止或删除内容自动屏蔽

作者: emacsnw 时间: 2008-06-22 11:01

原帖由 zhangzhh05 于 2008-6-21 18:46 发表

那为什么别的网站做不到呢？
再说有将近上亿（保守估计）的用户名，你得去匹配吧！字符的比较有那么快吗？
那你说说如果让你来做，你会怎么去做？

查找树啊。

作者: system888net 时间: 2008-06-22 11:28

原帖由 zhangzhh05 于 2008-6-22 10:46 发表

那为什么别的网站做不到呢？
再说有将近上亿（保守估计）的用户名，你得去匹配吧！字符的比较有那么快吗？
那你说说如果让你来做，你会怎么去做？

没那么神秘!
每一个节点(机器)上当然要采用合适的算法. 然后.
每个节点上都存有部分数据,当查询ask到来时,多个节点一起匹配这个用户名, 速度自然快了.

作者: cugb_cat 时间: 2008-06-22 11:54
如果做了索引，这个数据量放在数据库中去查也很快的。

作者: aoegiss 时间: 2008-06-22 12:01
有没有让你一个一个的strcmp

作者: system888net 时间: 2008-06-22 12:05

原帖由 cugb_cat 于 2008-6-22 11:54 发表
如果做了索引，这个数据量放在数据库中去查也很快的。

赞同,方法的确很多.

在一定的数据量的前提下,一个用户的速度好处理(数据库和内存都有解决办法),当数据量过大或很大并发ask来时, 就要多节点一起匹配才能保证服务的实时性了.
这也就是google等采用多节点的原因了(实际上数据何止上亿)!

作者: flw 时间: 2008-06-22 13:08
还有一点：
理论上来讲，在利用了 ajax 技术的网站上，
这种检测在用户输入时就已经可以开始了。
手指的速度比机器和网络的速度慢了若干个数量级呢。

作者: system888net 时间: 2008-06-22 13:53

原帖由 flw 于 2008-6-22 13:08 发表
还有一点：
理论上来讲，在利用了 ajax 技术的网站上，
这种检测在用户输入时就已经可以开始了。
手指的速度比机器和网络的速度慢了若干个数量级呢。

这也是一个有效的补充.

作者: zhangzhh05 时间: 2008-06-22 17:12
提示: 作者被禁止或删除内容自动屏蔽

作者: hzcgz 时间: 2008-06-22 21:44
google 的技术是挺牛的.

作者: libinz 时间: 2008-06-22 22:22

喜欢Google.

作者: benjiam 时间: 2008-06-22 23:10
有人做过上亿用户吗？有上1kw个用户吗？

分开节点，会有很多问题。各个节点的及时更新，和状态处理是很麻烦的。

google 的确是nb 的。

qq 原来有道面提就是考如何快速从1亿个客户里面搜索出相要的数据。

从qq 里面查询的状态来看，好像不是很好。他们应该没完全解决这个问题。

作者: zszyj 时间: 2008-06-23 11:50

原帖由 zhangzhh05 于 2008-6-22 09:24 发表
前几天在注册Gmail邮箱时，在我输入用户名，检测是否被占用时，我没有感觉到一点点延迟，结果就出来了。
Google在全球有上亿的Gmail用户吧，这个检测速度也太快了，而且还没算上网络的延迟。比其它的门户网站都 ...

不要说1亿,即使是10亿行记录, 在数据库里按索引查找的话, 所花时间也不会超过1ms, 检测用户名明显就是按索引查找的, 因此也不会想得太神秘.
至于google网页显示速度快,那是因为它的WEB页面都是用CGI来生成的, 无论如何按生成网页的速度快, C肯定会远快于JAVA和.net
其实googlec真正的功夫，是体现在搜索上，那才真正是几千个节点上的海量数据并行搜索，比查找用户名之类的简单操作难度提高了不止上万倍．

作者: nbroot 时间: 2008-06-23 12:19

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

不要说1亿,即使是10亿行记录, 在数据库里按索引查找的话, 所花时间也不会超过1ms, 检测用户名明显就是按索引查找的, 因此也不会想得太神秘.

知其然不知其所以然。

至于google网页显示速度快,那是因为它的WEB页面都是用CGI来生成的 ...

是CGI就快吗？

作者: scutan 时间: 2008-06-23 12:26
下面这个是李开复写的"算法的力量"中的一部分, 讲了关于google的一些东西.

网络时代的算法
   有人也许会说：“今天计算机这么快，算法还重要吗?”其实永远不会有太快的计算机，因为我们总会想出新的应用。虽然在摩尔定律的作用下，计算机的计算能力每年都在飞快增长，价格也在不断下降。可我们不要忘记，需要处理的信息量更是呈指数级的增长。现在每人每天都会创造出大量数据（照片，视频，语音，文本等等）。日益先进的记录和存储手段使我们每个人的信息量都在爆炸式的增长。互联网的信息流量和日志容量也在飞快增长。在科学研究方面，随着研究手段的进步，数据量更是达到了前所未有的程度。无论是三维图形、海量数据处理、机器学习、语音识别，都需要极大的计算量。在网络时代，越来越多的挑战需要靠卓越的算法来解决。

   再举另一个网络时代的例子。在互联网和手机搜索上，如果要找附近的咖啡店，那么搜索引擎该怎么处理这个请求呢?

   最简单的办法就是把整个城市的咖啡馆都找出来,然后计算出它们的所在位置与你之间的距离,再进行排序,然后返回最近的结果。但该如何计算距离呢？图论里有不少算法可以解决这个问题。

   这么做也许是最直观的，但绝对不是最迅速的。如果一个城市只有为数不多的咖啡馆,那这么做应该没什么问题,反正计算量不大。但如果一个城市里有很多咖啡馆,又有很多用户都需要类似的搜索,那么服务器所承受的压力就大多了。在这种情况下,我们该怎样优化算法呢?

   首先，我们可以把整个城市的咖啡馆做一次“预处理”。比如，把一个城市分成若干个“格子(grid)”,然后根据用户所在的位置把他放到某一个格子里，只对格子里的咖啡馆进行距离排序。

   问题又来了，如果格子大小一样，那么绝大多数结果都可能出现在市中心的一个格子里，而郊区的格子里只有极少的结果。在这种情况下，我们应该把市中心多分出几个格子。更进一步，格子应该是一个“树结构”，最顶层是一个大格——整个城市，然后逐层下降，格子越来越小，这样有利于用户进行精确搜索——如果在最底层的格子里搜索结果不多，用户可以逐级上升，放大搜索范围。

   上述算法对咖啡馆的例子很实用，但是它具有通用性吗？答案是否定的。把咖啡馆抽象一下，它是一个点”，如果要搜索一个“面”该怎么办呢？比如，用户想去一个水库玩，而一个水库有好几个入口，那么哪一个离用户最近呢？这个时候，上述“树结构”就要改成“r-tree”,因为树中间的每一个节点都是一个范围，一个有边界的范围（参考：http://www.cs.umd.edu/~hjs/rtrees/index.html）。

   通过这个小例子，我们看到，应用程序的要求千变万化，很多时候需要把一个复杂的问题分解成若干简单的小问题，然后再选用合适的算法和数据结构。

   上面的例子在Google里就要算是小case了！每天Google的网站要处理十亿个以上的搜索，GMail要储存几千万用户的2G邮箱，Google Earth要让数十万用户同时在整个地球上遨游，并将合适的图片经过互联网提交给每个用户。如果没有好的算法，这些应用都无法成为现实。

   在这些的应用中，哪怕是最基本的问题都会给传统的计算带来很大的挑战。例如，每天都有十亿以上的用户访问Google的网站，使用Google的服务，也产生很多很多的日志（Log）。因为Log每分每秒都在飞速增加，我们必须有聪明的办法来进行处理。我曾经在面试中问过关于如何对log进行一些分析处理的问题，有很多面试者的回答虽然在逻辑上正确，但在实际应用中是几乎不可行的。按照他们的算法，即便用上几万台机器，我们的处理速度都跟不上数据产生的速度。

   那么Google是如何解决这些问题的呢？

   首先，在网络时代，就算有最好的算法，也要能在并行计算的环境下执行。在Google的数据中心，我们使用的是超大的并行计算机。但传统的并行算法运行时，效率会在增加机器数量后迅速降低，也就是说，十台机器如果有五倍的效果，增加到一千台时也许就只有几十倍的效果。这种事倍功半的代价是没有哪家公司可以负担得起的。而且，在许多并行算法中，只要一个结点犯错误，所有计算都会前功尽弃。

   那么Google是如何开发出既有效率又能容错的并行计算的呢？

   Google最资深的计算机科学家Jeff Dean认识到， Google 所需的绝大部分数据处理都可以归结为一个简单的并行算法：Map and Reduce（http://labs.google.com/papers/mapreduce.html）。这个算法能够在很多种计算中达到相当高的效率，而且是可扩展的（也就是说，一千台机器就算不能达到一千倍的效果，至少也可以达到几百倍的效果）。Map and Reduce的另外一大特色是它可以利用大批廉价的机器组成功能强大的server farm。最后，它的容错性能异常出色，就算一个server farm里面的机器down掉一半，整个farm依然能够运行。正是因为这个天才的认识,才有了Map and Reduce算法。借助该算法，Google几乎能无限地增加计算量，与日新月异的互联网应用一同成长

作者: zhangzhh05 时间: 2008-06-23 13:21
提示: 作者被禁止或删除内容自动屏蔽

作者: zszyj 时间: 2008-06-23 15:30

原帖由 nbroot 于 2008-6-23 12:19 发表

知其然不知其所以然。

是CGI就快吗？

"不知其所以然的"是你, 只不过你以为别人不知罢了.
CGI快不快,你自已测去吧, 没人想和你争论这种无聊问题.

作者: zszyj 时间: 2008-06-23 15:33

原帖由 zhangzhh05 于 2008-6-23 13:21 发表

或许这些问题我们能想出解决的方法，觉的也是正确的，可在实际中环境中能不能用，或者能不能非常高效，那就不是我们能想到的，没有实践检验，做成成功的产品，一切都在我们的想像之中，想的都是应该就那么快 ...

google 算法优秀, 没人不承认, 但我说的是, 算法优秀,并不体现在查找一个用户名的这种小问题上,而是体现在其内容搜索上. 如果仅仅是查找用户名, 大家自已在一个10亿行记录的数据库上查找一下就明白了. b-tree已经达到非常令人满意的速度, 时间绝不超过1ms.

作者: FightForWin 时间: 2008-06-23 16:07

原帖由 flw 于 2008-6-22 13:08 发表
还有一点：
理论上来讲，在利用了 ajax 技术的网站上，
这种检测在用户输入时就已经可以开始了。
手指的速度比机器和网络的速度慢了若干个数量级呢。

支持

作者: zhangzhh05 时间: 2008-06-23 16:15
提示: 作者被禁止或删除内容自动屏蔽

作者: system888net 时间: 2008-06-23 17:25

讨论的不错,顶一下.

作者: netmwd 时间: 2008-06-23 18:06
google好牛阿

作者: system888net 时间: 2008-06-23 21:38

原帖由 scutan 于 2008-6-23 12:26 发表
下面这个是李开复写的"算法的力量"中的一部分, 讲了关于google的一些东西.

又是一个有效的补充,支持.

作者: 獨照づ幔紗 时间: 2008-06-23 22:58
算法+技术

作者: bbpet 时间: 2008-06-23 23:31

原帖由 zszyj 于 2008-6-23 15:33 发表

google 算法优秀, 没人不承认, 但我说的是, 算法优秀,并不体现在查找一个用户名的这种小问题上,而是体现在其内容搜索上. 如果仅仅是查找用户名, 大家自已在一个10亿行记录的数据库上查找一下就明白了. b-tree ...

难道是我不会用？？？

由于在大表中从来没见过ms级别的反馈，所以特意去试了一下
在db2上试的，分part了，24个批次跑，具体多少条不知道，反正没到10亿，等了好几分钟，总之就不是ms……
oracle上遍寻公司找不到亿级的数据
mysql上只有350万条的，非集群，平时查询还勉强，反正小慢，但是插入那叫一个慢啊，都不敢说……
另，db2调优了的

作者: bbpet 时间: 2008-06-23 23:35

原帖由 bbpet 于 2008-6-23 23:31 发表

难道是我不会用？？？
由于在大表中从来没见过ms级别的反馈，所以特意去试了一下
在db2上试的，分part了，24个批次跑，具体多少条不知道，反正没到10亿，等了好几分钟，总之就不是ms……
oracle上 ...

另补充下，mysql那台刀片上还跑有一个剧恶心的java应用，占了大量的内存，慢可能是这个的影响
不用讨论它（虽然俺知道google用的是mysql），说说db2那个为虾米比理想时间慢了~

作者: zszyj 时间: 2008-06-24 00:12

原帖由 bbpet 于 2008-6-23 23:31 发表

难道是我不会用？？？
由于在大表中从来没见过ms级别的反馈，所以特意去试了一下
在db2上试的，分part了，24个批次跑，具体多少条不知道，反正没到10亿，等了好几分钟，总之就不是ms……
oracle上 ...

真弄不懂你到底在做什么操作, 查找一行记录需要分24批次跑吗?
按索引查找一行记录要好几分钟? 你做的是全表扫描吧?
不要说现在这么强的机器,在2002年,我在移动公司每月20亿条的话单表(单表), 查找一个电话某天的所有通话记录,也就是ms级.
你非要说你家的机器要几分钟,我也没办法. 只是不明白你们公司的技术人员是干什么用的.

[ 本帖最后由 zszyj 于 2008-6-24 00:18 编辑 ]

作者: zszyj 时间: 2008-06-24 00:17

原帖由 bbpet 于 2008-6-23 23:31 发表

难道是我不会用？？？
由于在大表中从来没见过ms级别的反馈，所以特意去试了一下
在db2上试的，分part了，24个批次跑，具体多少条不知道，反正没到10亿，等了好几分钟，总之就不是ms……
oracle上 ...

另外你说的在大表中没见过ms级别的反馈, 那就再告诉你一个事实吧:
在我们公司实现的银行系统中, 每个季度结息的速度一般是1000万户/小时, 分户表的数据量大约是1亿户, 每结一户利息所执行的SQL语句大约是60句左右. 你自已算算, 这叫不叫达到ms级别吧.

作者: bbpet 时间: 2008-06-24 00:22

原帖由 zszyj 于 2008-6-24 00:17 发表

另外你说的在大表中没见过ms级别的反馈, 那就再告诉你一个事实吧:
在我们公司实现的银行系统中, 每个季度结息的速度一般是1000万户/小时, 分户表的数据量大约是1亿户, 每结一户利息所执行的SQL语句大约是60句 ...

在db2上试的，确实没达到ms级~
另，亿级的数据处理要分part，貌似是常识，也许我是教条了~
反正分part了应该只会快吧？

[ 本帖最后由 bbpet 于 2008-6-25 21:09 编辑 ]

作者: bbpet 时间: 2008-06-24 00:26

原帖由 zszyj 于 2008-6-24 00:12 发表

真弄不懂你到底在做什么操作, 查找一行记录需要分24批次跑吗?
按索引查找一行记录要好几分钟? 你做的是全表扫描吧?
不要说现在这么强的机器,在2002年,我在移动公司每月20亿条的话单表(单表), 查找一个电话某 ...

咿，对哦，也许不慎做到全表扫描了，明天去看看再re啊~
就做一个select对吧，好像不应该那么久的~

作者: zszyj 时间: 2008-06-24 00:43

原帖由 bbpet 于 2008-6-24 00:22 发表

在下正好也是银行的，所以才在db2上试的，确实没达到ms级~
另，亿级的数据处理要分part，貌似是常识，也许我是教条了~
反正分part了应该只会快吧？

分patiotion, 也要看你是否将db container也同时分开在不同的硬件设备上了,否则没有意义. 同时,数据分布的条件, 是否与索引条件一致了,否则还是逐个分区扫描, 也是得不偿失.
另外,还要看看你的操作系统, 如果是AS400, 根本上硬盘设备不由你管理, 那么分区是根本没有作用的.
最后,你说的达不到ms级, 那就看你们的机器了, 我只在很老的400上(02年的830)发现按索引查询的速度是300行/秒左右, 其它UNIX平台上,包括DB2,ORACLE以及INFORMIX都是飞快的.
当然, 如果是以循环方式执行SQL以测试数据库性能的话, 还要看看你写SQL的水平, 传参数与传常量, 性能可以相差7倍, 如果你写的是以下方式:

char sql[128];

for (int i=0; i<10000; i++)
{
sprintf(sql , "select f1 from t1 where k1='%d'", i);
... // 执行SQL语句
}

那么我就无话可说,也不想说了.

[ 本帖最后由 zszyj 于 2008-6-24 01:10 编辑 ]

作者: bbpet 时间: 2008-06-24 00:57

原帖由 zszyj 于 2008-6-24 00:43 发表

分patiotion, 也要看你是否将db container也同时分开在不同的硬件设备上了,否则没有意义. 同时,数据分布的条件, 是否与索引条件一致了,否则还是逐个分区扫描, 也是得不偿失.
另外,还要看看你的操作系统, 如果 ...

别急别急，别冒火，刚找了个加班的弟兄确认了，是我迷糊了，改了个扫全表的程序测，土了土了~

我是做平台的，属于大机小白，见谅见谅
看到10亿1ms觉得也太牛了于是抢了个pcomm改批量程序，得了个错误结论出来，回去定学学db2
由于平时确实没看到旁边人有在大表中做select的，所以说从没见过ms级的大表反馈
附，机器是s390~
另，个人相信ms结论，因为联机查询数据正常来说好像都是ms级的

作者: zszyj 时间: 2008-06-24 01:09

原帖由 bbpet 于 2008-6-24 00:57 发表

别急别急，别冒火，刚找了个加班的弟兄确认了，是我迷糊了，改了个扫全表的程序测，土了土了~
我是做平台的，属于大机小白，见谅见谅
看到10亿1ms觉得也太牛了于是抢了个pcomm改批量程序，得了个错误 ...

没什么,只是互相讨论. 不过, 象你这样针对一些小事情也认真去求证的态度, 我还真是很佩服的.
在这见多了自以为是信口开河的人, 看到你这么认真对待问题的人真是很难得了, 希望以后多交流.

[ 本帖最后由 zszyj 于 2008-6-24 01:11 编辑 ]

作者: bbpet 时间: 2008-06-24 01:34

原帖由 zszyj 于 2008-6-24 01:09 发表

没什么,只是互相讨论. 不过, 象你这样针对一些小事情也认真去求证的态度, 我还真是很佩服的.
在这见多了自以为是信口开河的人, 看到你这么认真对待问题的人真是很难得了, 希望以后多交流.

下线了，明天去做个select再回来贴结论~
因为我实在没想到db能这么快，按习惯碰到这种问题第一个反应就是hash~

作者: magicd 时间: 2008-06-24 09:49
不过……的确不能因为这个就说google牛吧

作者: emacsnw 时间: 2008-06-24 10:06

原帖由 zhangzhh05 于 2008-6-22 21:21 发表

或许这些问题我们能想出解决的方法，觉的也是正确的，可在实际中环境中能不能用，或者能不能非常高效，那就不是我们能想到的，没有实践检验，做成成功的产品，一切都在我们的想像之中，想的都是应该就那么快 ...

Google很多应用上用的的确是开源的（主要是MySQL）数据库，但是核心的底层（搜索、gmail、google earth）不是这些，没有所谓的违背开源软件的宗旨吧。

作者: yaoaiguo 时间: 2008-06-24 11:12
我觉得这个查询应该不算难吧，建立好索引会很快。
假如你的用户名有10个字符，查10次不就得到结果了吗？

作者: fan12 时间: 2008-06-24 11:14
顶，有看头

作者: zszyj 时间: 2008-06-24 12:20

原帖由 yaoaiguo 于 2008-6-24 11:12 发表
我觉得这个查询应该不算难吧，建立好索引会很快。
假如你的用户名有10个字符，查10次不就得到结果了吗？

为什么要查10次, 以用户名为索引, 数据库查询也就一次!

作者: netchecking 时间: 2008-06-24 12:49
没有懂技术的！！！

作者: 可恶的 时间: 2008-06-24 13:04
期待bbpet的结果。
晚上再来关注。

作者: chliang315 时间: 2008-06-24 13:42

作者: zhangzhh05 时间: 2008-06-24 13:47
提示: 作者被禁止或删除内容自动屏蔽

作者: ljily000 时间: 2008-06-24 14:07
google的技术确实不错！

作者: shan_ghost 时间: 2008-06-24 15:22
看 Google黑板报数学之美系列关于布隆过滤器（Bloom Filter）的介绍

俺稍微做个学习总结吧^_^

简单点说，这是基于hash算法思想的一个拓展算法。

一般的hash实现都是用以存储数据的；但如果用于检查某个东西是否存在的场合，那么仅需存储一个占用标记（1个二进制位）即可，通用的实现就太浪费空间了——尤其是上亿甚至几十亿数据（如google的email黑名单）的情况。

但如果仅存储一个二进制位，又怎样识别碰撞？

一种办法是：做8个hash表，用8个不同的散列函数；选择得当的话，一个词在8种hash方案中都有碰撞的概率就极小了。

如果你完全理解了hash算法，那么下一步优化就是理所当然的了：

为了减小碰撞，除了选择好算法，我们还必须保证hash地址空间足够大；但为了减少内存占用，hash地址还不能太大。

怎么办？

布隆过滤器的思路是：用一个16倍大的地址空间；但让所有8个hash函数都映射到这个地址空间里面。

这样，对设计良好的hash函数来说，碰撞的概率几乎小到可以忽略不计；虽然同时多了8个散列函数相互影响的问题，但总碰撞会比8个不同hash函数在独立的2倍大小地址中的碰撞少得多。

于是，这个算法就不仅大幅度降低了时间、空间消耗，又保证了足够的准确率。

对于检查用户名有否重复这种应用来说，一方面数据量肯定要比垃圾邮件地址少得多；另一方面，即使发生了碰撞，也不过是导致极少几个用户名无法使用而已，完全不必理会。

综合起来，这个算法不过是8个无碰撞检测的散列和8次通过下标的数组访问而已；不考虑页错误，即使在pc机上跑，时间消耗也不会超过微秒级。

PS：这个算法没有复杂的逻辑；不需要深刻的数学知识；只要吃透并灵活运用那些基础算法，你也能发明出来！
可见，把知识吃透学活是多么的重要啊！

[ 本帖最后由 shan_ghost 于 2008-6-24 15:24 编辑 ]

作者: lose 时间: 2008-06-24 15:35

原帖由 zszyj 于 2008-6-24 12:20 发表

为什么要查10次, 以用户名为索引, 数据库查询也就一次!

想问一下，数据库怎么实现的以用户名为索引，不会开一个超大的数组吧。

作者: 思一克 时间: 2008-06-24 15:48
用户名字是关键字.

而关键字的精确查找(判断存在否)是几乎不需要时间的(非常快)----因为索引等算法.

你自己用DB写个程序实验, 给100万个email地址(随机生成), 查找实验看.

某种程度上, 和用户数量几乎无关------你可以递归地理解:

如果1亿用户查找时间是T, 10亿呢? 如果你HASH到10个库中了, 查找时间也还是T(HASH的计算分配时间几乎是0).

不是DB专家, 自己的想法.

作者: zszyj 时间: 2008-06-24 16:51

原帖由 lose 于 2008-6-24 15:35 发表

想问一下，数据库怎么实现的以用户名为索引，不会开一个超大的数组吧。

数据库的索引算法是b-tree, 自已拿本数据库原理的书看看吧. 其中<数据结构>一书中也有介绍这个算法. 都是由数据库实现了的, 开发人员根本不需要自已重新实现.
B-tree最大的作用, 就是数据量几何增长的情况下,而查找时间只是线性增长. 因此, 分别在1000万,1亿,10亿的数据量上查找一行记录,差别可能只是0.1ms, 02ms, 03ms.

作者: lose 时间: 2008-06-24 16:55

原帖由 zszyj 于 2008-6-24 16:51 发表

数据库的索引算法是b-tree, 自已拿本数据库原理的书看看吧. 其中一书中也有介绍这个算法. 都是由数据库实现了的, 开发人员根本不需要自已重新实现.
B-tree最大的作用, 就是数据量几何增长的情况下,而查找时间 ...

多谢指点，一眼看到以为是数据结构，再看是数据库原理，好我去看看。

作者: zszyj 时间: 2008-06-24 17:00

原帖由 lose 于 2008-6-24 16:55 发表

多谢指点，一眼看到以为是数据结构，再看是数据库原理，好我去看看。

"数据结构"是很多年前看的书了, 印象中在排序和查找一章中,是有b-tree算法的. 也可能是我记错了, 不妨看看.

作者: system888net 时间: 2008-06-24 22:07

继续关注大家的讨论!

作者: bbpet 时间: 2008-06-24 22:16

原帖由 可恶的 于 2008-6-24 13:04 发表
期待bbpet的结果。
晚上再来关注。

呵呵，晚上踢球去了，不幸让你等惨了~
这回的结果让我相当的吃惊，居然到了0.1ms的级别去了

由于自己对db不熟，这回干脆让做数据库维护的人测，应该不犯错了
主机z990（长进了，不用s390了），两张表，一张7亿数据，另一张30亿
查找索引，两张表结果一样，联机查5-6ms，批量1ms以下
囧rz，差一个数据级的记录数竟然结果没有啥差别
由批量时间和数据量得出的结果，非主索引，0.001s以下，主索引0.0001s左右
靠，无语了，看来主要还是看索引设置
联机5-6ms的原因，是有很多相对查询比较耗时的操作混在中间
仅就db查询而言，批量那个比较准确，对于查用户名这种，联机的时间似乎更有参考价值~

that is all，期待高人出来讲解，因为这个数据太无敌了，db的强悍超出了我的想象
也可指点下是不是测试方法有不妥或有改进的地方……

作者: wwwsq 时间: 2008-06-24 23:55
用“布隆过滤器”可以瞬间进行判断，这个用户名是否已经被用过。

不用查数据库，也不用查RB-Tree。

过滤器的构建：构造一个巨大的bit array，比如10亿比特（占用约125 M内存），把这个array的所有bit都初始化为零。然后把现有的user name都做hash，再把hash结果对10亿求余。得到的余数作为bit array的偏移量，把这个bit置1

过滤器的使用：把新的用户名求hash再对10亿求余，得到的余数作为array的偏移量，看这个bit是否为零。为零则这个新的用户名肯定没被用过；为1则99%的可能已经被用过了，那么就告诉用户这个用户名已经被用过了。

[ 本帖最后由 wwwsq 于 2008-6-25 00:14 编辑 ]

作者: leotalk 时间: 2008-06-25 00:14
无语，一个字符串匹配，就算法优越了？

省省吧，就搜索算法这玩意，以目前的理论水平，在没有获得重大突破前，google与其它公司不过50步与100步的差别，在某些领域还差些。

瞧你们吹捧的，大汗... ...

评论的诸位，估计连个算法导论都没看个全，话说回来便是看个全也不顶用，在国内，诸位怕是都没有这样的工程实践机会

最后，提醒一下楼主，这么随随便便就给Gmail用户上亿了，当真了不得，

作者: emacsnw 时间: 2008-06-25 03:43

原帖由 leotalk 于 2008-6-24 08:14 发表
无语，一个字符串匹配，就算法优越了？

省省吧，就搜索算法这玩意，以目前的理论水平，在没有获得重大突破前，google与其它公司不过50步与100步的差别，在某些领域还差些。

瞧你们吹捧的，大汗... ...

...

baidu的？

作者: zszyj 时间: 2008-06-25 09:02

原帖由 bbpet 于 2008-6-24 22:16 发表

呵呵，晚上踢球去了，不幸让你等惨了~
这回的结果让我相当的吃惊，居然到了0.1ms的级别去了

由于自己对db不熟，这回干脆让做数据库维护的人测，应该不犯错了
主机z990（长进了，不用s390了），两张表，一 ...

这就是数据库的真实能力, 即使数据量几何级数增长, 查询时间也就是线性增长.
而且说实在, 你做的联机之所以慢, 估计你是没有将服务常驻了, 如果服务常驻的话,性能与批量是一样的.
联机超过1ms的原因, 估计是因为你查询时才建立数据库连接, 而没有使用连接池等技术.
在我们的程序里,不仅使用连接池, 还建立了statment池, 速度还可以提升5倍. 够吓人吧?

作者: zszyj 时间: 2008-06-25 09:11

原帖由 wwwsq 于 2008-6-24 23:55 发表
用“布隆过滤器”可以瞬间进行判断，这个用户名是否已经被用过。

不用查数据库，也不用查RB-Tree。

过滤器的构建：构造一个巨大的bit array，比如10亿比特（占用约125 M内存），把这个array的所有bit都初 ...

省省吧, 用户名匹配, 犯得着什么复杂算法吗? 数据库查询, 即使是10亿以上,也不超过1ms, 前面的已经测试了, 0.1ms, 你这个hash能快到哪去?
再说了, 即使机器内存多,将用户名换成bit都放在内存, 用户详细信息放哪? 增删改用户, 这个hash表维护起来会简单? ACID怎么保证?
另外,都放在一台机器的内存,也就一台机器可用, cluster怎么办? 几千台机器, 并发数据库查询的吞吐量,绝对远高于单机上的所谓hash内存查询的吞吐量.
一看这种唯"算法论", 就是完全无视大型系统整体架构规划,完全无视工程实施可行性的学术派思想.
一

作者: benjiam 时间: 2008-06-25 09:14

原帖由 bbpet 于 2008-6-23 23:31 发表

难道是我不会用？？？
由于在大表中从来没见过ms级别的反馈，所以特意去试了一下
在db2上试的，分part了，24个批次跑，具体多少条不知道，反正没到10亿，等了好几分钟，总之就不是ms……
oracle上 ...

mysql

我插入到87w 条就没信心等下去了。
1个亿..... 不知道要等多久。

还有把1格亿的用户名放在一个数据库里的想法很烂。足以成为最大的瓶颈

作者: benjiam 时间: 2008-06-25 09:16

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

省省吧, 用户名匹配, 犯得着什么复杂算法吗? 数据库查询, 即使是10亿以上,也不超过1ms, 前面的已经测试了, 0.1ms, 你这个hash能快到哪去?
再说了, 即使机器内存多,将用户名换成bit都放在内存, 用户详细信息放 ...

你认为在一个数据库里就好了，更烂。每个查询就行一次数据库查询。和hash 的差别是n次方的差距。

作者: zszyj 时间: 2008-06-25 09:28

原帖由 benjiam 于 2008-6-25 09:14 发表

mysql

我插入到87w 条就没信心等下去了。
1个亿..... 不知道要等多久。

还有把1格亿的用户名放在一个数据库里的想法很烂。足以成为最大的瓶颈

一看又是一个数据库盲, 根本没接触过什么过大型数据库. 1亿行数据居然成瓶颈了? 不知道现在TB级的数据库已经是家常便饭? PB级才是当前的挑战?
在庞大的数据量下, 你自已管理内存的能力居然比DB强? ACID你能保证? 真是笑话!
看过某个公司给移动做的BOSS系统,就是所谓将客户信息和账单信息全放内存, 数据量增长到几百万时,那个查询速度, 可真叫等待啊....更要命的是,动不动机器因内存用完就当机,所有数据丢失, 哈哈, 3个月的数据全部丢失,大量信息还要手工补录, 笑死人了....
有些人自以为很强, 从来不将成熟的技术放眼内, 但这种人做出来的应用系统, 才真叫一个烂.

作者: 思一克 时间: 2008-06-25 09:30
插入87W? 你这里是个循环, 每一个插入都要查询有无同关键字. 所以慢.

你插入一条就快了.

查询一个最快.

原帖由 benjiam 于 2008-6-25 09:14 发表

mysql

我插入到87w 条就没信心等下去了。
1个亿..... 不知道要等多久。

还有把1格亿的用户名放在一个数据库里的想法很烂。足以成为最大的瓶颈

作者: cx6445 时间: 2008-06-25 09:58
目前用户数最多的系统应该是QQ，分布式的mysql就能解决问题了。一个mysql负责一部份qq帐号，前端接受登录请求的时候根据q号判断一下哪个库就行了。性价比，比集中式的db高多了。

[ 本帖最后由 cx6445 于 2008-6-25 10:01 编辑 ]

作者: 可恶的 时间: 2008-06-25 10:07

原帖由 bbpet 于 2008-6-24 22:16 发表

呵呵，晚上踢球去了，不幸让你等惨了~
这回的结果让我相当的吃惊，居然到了0.1ms的级别去了

由于自己对db不熟，这回干脆让做数据库维护的人测，应该不犯错了
主机z990（长进了，不用s390了），两张表，一 ...

踢球好，混挨踢也要多锻炼身体嘛

没想到数据库能够那么强大，学无止境啊。

感谢zszyj的言论，指点迷津了。

作者: benjiam 时间: 2008-06-25 11:04

原帖由 zszyj 于 2008-6-25 09:28 发表

一看又是一个数据库盲, 根本没接触过什么过大型数据库. 1亿行数据居然成瓶颈了? 不知道现在TB级的数据库已经是家常便饭? PB级才是当前的挑战?
在庞大的数据量下, 你自已管理内存的能力居然比DB强? ACID你能保 ...

说你烂是有根据的。
gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常连还是暂时连接？

插入的时候，锁不锁表。锁多久，颗粒多大。异常怎么处理？如何处理数据库的异常。  数据库出一点问题。整个google 就停下来？

比DB强页没不是什么难事， db 是人写的。 db 的设计是有考虑的。因为db 并不是为了你这个业务设计的。

就好比飞机也会设计很多种，有飞得快也有飞得高，也有窄重多的。

当然对于只能操作一下数据库的人，的确只能对 db 顶礼膜拜了。  因为他们做不到吗？

按照他们的逻辑  google 的结构是一个很大的db.  所有的网页都放在db里面
一个客户以查询就运行一条 select * from htmlrecord where body like %+ req+%

唉 google 找那么多大牛干什么呢？ oracle 居然没开发 google  真是很奇怪啊！

作者: benjiam 时间: 2008-06-25 11:07

原帖由 思一克 于 2008-6-25 09:30 发表
插入87W? 你这里是个循环, 每一个插入都要查询有无同关键字. 所以慢.

你插入一条就快了.

查询一个最快.

不太懂，什么叫插入一条就快了？

作者: zszyj 时间: 2008-06-25 11:31
[quote]原帖由 benjiam 于 2008-6-25 11:04 发表

"gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ... "

还是显示你自已的幼稚．　先去弄清楚什么是多层架构，什么是数据库连接池，　什么叫分布式数据库，　再回来讨论吧．　就你？还差得远！
说你烂是有根据的。

＂插入的时候，锁不锁表。锁多久，颗粒多大。异常怎么处理？如何处理数据库的异常。  数据库出一点问题。整个google 就停下来？＂
不懂什么叫行锁吧？　数据库的异常处理能力，不正是它最大的强项？　自已先了解清楚再说吧．

＂比DB强页没不是什么难事， db 是人写的。 db 的设计是有考虑的。因为db 并不是为了你这个业务设计的。＂
相信就是有这样的人，　也绝不会是阁下你！从你的肤浅言论已经可以得出结论．

"当然对于只能操作一下数据库的人，的确只能对 db 顶礼膜拜了。  因为他们做不到吗？"
ＤＢ只是一个工具，满足设计指标就行，　犯不着顶礼膜拜. 或许你有这爱好，这是你的个人权利．　另外我确实承认做不到ＤＢ所做的事情，如果我做到了，我就和层次型，网络型及关系型数据库的三位理论提出者一样，成为图灵奖得主了．但似乎阁下能做到似的，大家拭目以待看你的好戏吧，到时别忘通知我．

＂按照他们的逻辑  google 的结构是一个很大的db.  所有的网页都放在db里面
一个客户以查询就运行一条 select * from htmlrecord where body like %+ req+%＂
求你别再献丑了吧，　越说越显你无知．不知道多层架构，总知道什么叫ＭＶＣ吧？只有数据会放在ＤＢ里面，　会有人将网页放里面吗？或许你会这样，　我不会觉得奇怪．

＂唉 google 找那么多大牛干什么呢？ oracle 居然没开发 google  真是很奇怪啊！＂
碰巧我有朋友在那，告诉你我知道的一些也未尝不可．不过可能你听都没听过的名词．＂并行计算＂，＂information retrieval", "frequent pattern", 还有web3.0.

作者: lose 时间: 2008-06-25 11:31

原帖由 benjiam 于 2008-6-25 11:04 发表

说你烂是有根据的。
gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ...

就事说事，千万别呛着说话，我等还想多学习一些呢。

作者: cx6445 时间: 2008-06-25 11:34

原帖由 benjiam 于 2008-6-25 11:04 发表

说你烂是有根据的。
gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ...

看具体情况吧，也不是不能用数据库，就注册页面的应用来说可以独立出来，大型网站需要将数据库应用尽量模块化区分，不要集中式的db。

作者: benjiam 时间: 2008-06-25 11:47

原帖由 zszyj 于 2008-6-25 11:31 发表
[quote]原帖由 benjiam 于 2008-6-25 11:04 发表

"gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务 ...

"gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ... "

还是显示你自已的幼稚．　先去弄清楚什么是多层架构，什么是数据库连接池，　什么叫分布式数据库，　再回来讨论吧．　就你？还差得远！
说你烂是有根据的。

第一 google 在创立初期根本没有能力建这样的多层连接池。

第二多层连接池这样的架构根本不适合 google

第三建系统核心架设在db 上面，靠db完成本来就是错误的。

＂插入的时候，锁不锁表。锁多久，颗粒多大。异常怎么处理？如何处理数据库的异常。  数据库出一点问题。整个google 就停下来？＂
不懂什么叫行锁吧？　数据库的异常处理能力，不正是它最大的强项？　自已先了解清楚再说吧．

行锁？  虽然我db不太玩，但是行锁还是知道的。  考虑一下google 的用户量吧。考虑一下 google的服务器数目吧，考虑一下
每分钟 google 都有可能有1 台服务器当机。

想像一下，一个数据库瞬间被几万格服务器连上，然后的几十万格请求锁住，然再放开。很壮观！然后再有很多服务器当机，不断的有新服务连上数据库，再断掉。

分布式解决。很好，但不是你这么解决的。  延迟，稳定，故障。

作者: zszyj 时间: 2008-06-25 11:51

原帖由 可恶的 于 2008-6-25 10:07 发表

踢球好，混挨踢也要多锻炼身体嘛
没想到数据库能够那么强大，学无止境啊。

感谢zszyj的言论，指点迷津了。

客气了，　我只是实话实说，欢迎参与客观讨论．

作者: wwwsq 时间: 2008-06-25 11:56

原帖由 zszyj 于 2008-6-25 11:31 发表
[quote]原帖由 benjiam 于 2008-6-25 11:04 发表

"gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务 ...

区区不才，需要每天处理几亿条新增消息，一年是几百亿。经常要从所有数据（几千亿条）中做特定的查询。所以根据业务需要写了一个特别的存储系统，速度比标准数据库要快几个数量级，软硬件成本降低了几个数量级。

标准数据库肯定是强大的，凝聚了无数天才的努力。但是具体到我们的特殊的业务，有特殊的需要，有时候标准数据库就不如特定的解决方案了。

你自己没做过，就不要以为别人也一定没做过。

[ 本帖最后由 wwwsq 于 2008-6-25 12:01 编辑 ]

作者: cx6445 时间: 2008-06-25 12:01

原帖由 wwwsq 于 2008-6-25 11:56 发表

区区不才，需要每天处理几亿条新增消息，一年是几百亿。经常要从所有数据（几千亿条）中做查询。所以根据业务需要写了一个特别的存储系统，速度比标准数据库要快几个数量级，软硬件成本降低了几个数量级。 ...

这个同意，但如果不是特别的牛，还是利用数据库比较保险。

作者: wwwsq 时间: 2008-06-25 12:04

原帖由 cx6445 于 2008-6-25 12:01 发表

这个同意，但如果不是特别的牛，还是利用数据库比较保险。

不需要特别牛。真的不用。那个存储系统，随便找几个合格的计算机系毕业生都可以做好。只是你想不想去做的问题。标准数据库难做，是难在要“面面俱到”。而我们恰恰不需要“面面俱到”。

你只要考虑：什么时候用什么技术。

当标准数据库合适的时候，就用标准数据库。当标准数据库不合适的，就用其他技术。这是再简单不过的道理。

不要“唯数据库论”。

[ 本帖最后由 wwwsq 于 2008-6-25 12:07 编辑 ]

作者: zszyj 时间: 2008-06-25 12:05

原帖由 benjiam 于 2008-6-25 11:47 发表

"gmail 需要多少台 web 服务器，他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ... "

还是显示你自已 ...

看你技术眼界挺一般，但倒说得自已是googlec的老板似的，有机会你自已先到google了解系统架构再说吧．
顺便纠正一下你混乱的逻辑：
１．使用连接池技术，并不需要你说的几万吧服务器同时连上数据库又同时断开，你还是没弄明白什么叫数据库连接池．
２．使用连接池技术，几万台ＷＥＢ服务度在同一瞬间占用的并发连接数也就1000个之内．
３．即使是google，也没有繁忙到同一瞬间新增几万用户的可能性，能达到几百就不错了．
４．你还是没弄明白数据库锁机制，行锁是只有并发更新同一行记录时会使用，　查询是根本不会加锁的，因此更不可能出现你说的，几十万吧数据库服务器同时对数据库加锁的情况．
５．ＧＯＯＧＬＥ的服务器数目也就是数千的级别，没有你说的几十万这么可怕．可以不同的数据内容，是放在不同的数据库上的．
最后不得不说一句不客气的话，再和你纠缠下去，我都觉得有点丢人，感觉是和一个外行人在吵架一样．咱们都还是省省吧，留点时间给真正的高手说说话．

作者: cx6445 时间: 2008-06-25 12:09
想像一下，一个数据库瞬间被几万格服务器连上，然后的几十万格请求锁住，然再放开。很壮观！然后再有很多服务器当机，不断的有新服务连上数据库，再断掉。
－－－－－－－－－－－－－－－－－－

哪个公司的一个数据库服务能被几万个应用服务器相连？没见过这么牛B的数据库，db并发连接能上万的，能不能介绍一下。

作者: lFANS 时间: 2008-06-25 12:09
因为庞大的数据库里面安装一定规律处理，所以不是在1亿里面查找，可能是1万条比较，例如cndefu这个用户，会在user_c表里面查找，表示重c开头的用户名！

作者: wwwsq 时间: 2008-06-25 12:09

原帖由 zszyj 于 2008-6-25 12:05 发表

看你技术眼界挺一般，但倒说得自已是googlec的老板似的，有机会你自已先到google了解系统架构再说吧．
顺便纠正一下你混乱的逻辑：
１．使用连接池技术，并不需要你说的几万吧服务器同时连上数据库又同时断 ...

同学，有点常识再来参加讨论。

http://bbs.chinaunix.net/viewthread.php?tid=773865
“技嘉科技每月向Google公司供应的服务器主板数量已经达到3万块”

注意，是每个月。

作者: cx6445 时间: 2008-06-25 12:12

原帖由 wwwsq 于 2008-6-25 12:04 发表

不需要特别牛。真的不用。那个存储系统，随便找几个合格的计算机系毕业生都可以做好。只是你想不想去做的问题。标准数据库难做，是难在要“面面俱到”。而我们恰恰不需要“面面俱到”。

你只要考虑：什 ...

这个我还知道，呵呵，我们公司就有自己写的分布式小文件系统在用，用来替换最高端的netapp,但是真得问题也有一些。
我觉得似乎不是几个毕业生就能设计做的。可能我第一反映想到的存储系统，和你想得并不是太一样吧。

[ 本帖最后由 cx6445 于 2008-6-25 12:15 编辑 ]

作者: cx6445 时间: 2008-06-25 12:15

原帖由 wwwsq 于 2008-6-25 12:09 发表

同学，有点常识再来参加讨论。

http://bbs.chinaunix.net/viewthread.php?tid=773865
“技嘉科技每月向Google公司供应的服务器主板数量已经达到3万块”

注意，是每个月。

可能他说得是google中国。全球来说google的服务器似乎是超过10万台。

作者: wwwsq 时间: 2008-06-25 12:16

原帖由 cx6445 于 2008-6-25 12:12 发表

这个我还知道，呵呵，我们公司就有自己写的分布式文件系统在用，但是真得问题不少。
我觉得似乎不是几个毕业生就能设计做的。可能我第一反映想到的存储系统，和你想得并不是太一样吧。

眼界放开阔一点，什么叫“存储系统”。

“特定的存储系统”有多难做，取决于这个“特定的存储系统”要实现哪些功能。

不同的存储系统，可以有很大的差别。从内存到U盘到磁带机，从简单的文件存取，到复杂的联合查询。

你们公司的那个存储系统，可能需求比较多，所以难做。这可能是你们系统架构设计的问题。

作者: cx6445 时间: 2008-06-25 12:19

原帖由 wwwsq 于 2008-6-25 12:16 发表

眼界放开阔一点，什么叫“存储系统”。

“特定的存储系统”有多难做，取决于这个“特定的存储系统”要实现哪些功能。

不同的存储系统，可以有很大的差别。从内存到U盘到磁带机，从简单的文件存取， ...

嗯，如果你说的简单的那也有，比较简单的内存数据库，不好意思，我一想就是比较复杂的，眼界还要象你学习。其实需求也不多，就是读几个亿的1－100KB小文件，就是基本不会是重复的，不能cache的，只要能稳定支持几百兆的流量那也算很成功了。

[ 本帖最后由 cx6445 于 2008-6-25 12:22 编辑 ]

作者: zszyj 时间: 2008-06-25 12:34

原帖由 wwwsq 于 2008-6-25 12:09 发表

同学，有点常识再来参加讨论。

http://bbs.chinaunix.net/viewthread.php?tid=773865
“技嘉科技每月向Google公司供应的服务器主板数量已经达到3万块”

注意，是每个月。

google公司全球服务器有很多，这是承认的，　但不见得就是都用于搜索网站．
另外，google其实是全世界有很多分公司，不同的分公司有自已的搜索服务器群，但其实从理论上讲，他们是属于不同的服务器群．本质上并不算是一个网站.
我前面所指的数千台，本意是指其一个地区网站(比如中国区）的服务器数量，因为我认为这才算是一个系统．如果因此引起争辩，我承认有误，收回此观点．
另外，是否用数据库，本来就是一个规划问题，不是技术问题，没人＂唯数据库论＂，但也反对＂反数据论＂．　是否采用数据库，其实更多地是一个系统性问题，判断标准如下：
１．功能和性能是否满足？　内存，文件系统，数据库，只要满足要求的，都是一个可选项．
２．性价比和技术难度如何？　一个很简单问题，用数据库一分钟能解决，我们需要组织一组人，花几天甚至几月时间是否值得？同样已经实现设计要求，是否有必要不计代价的追求最佳性能？
３．技术人员要求．哪种方案对技术人员要求低，以后维护修改容易？
４．稳定性．哪种方案稳定性更好，出现机器故障时能否尽可能恢复数据，减少损失？
５．并发性，可扩缩性．当数据规模增长时，哪种方式更容易简单通过扩容硬件即实现处理能力的扩展．
一个特殊问题，也许可以单独实现一个复杂算法以提高性能，但面对大量具有普遍性的信息管理需求，难道每个都需要这样去做吗？比如前面提到的用户信息管理，只是信息系统中最基本最普遍的一个简单问题，如何动则上升到自实现复杂算法的地步，那么面对其它大量的信息管理要求，该如何去面对？
所以，我在前面才说，不要将精力放在，任何人都可以通过简单方式轻易实现的功能上，比如用户管理．而要将精力放在有复杂技术难度的问题上，比如信息提取，语义识别，模式识别，内容搜索等方面．
不知道我到底表达清楚了没有．
还有哪些坚持要自已编算法，去实现简单查询功能的，我也不反对，必竟你有自已的权利，必竟是你对自已的公司和客户负责．

作者: wwwsq 时间: 2008-06-25 12:38

原帖由 cx6445 于 2008-6-25 12:19 发表

嗯，如果你说的简单的那也有，比较简单的内存数据库，不好意思，我一想就是比较复杂的，眼界还要象你学习。其实需求也不多，就是读几个亿的1－100KB小文件，就是基本不会是重复的，不能cache的，只要能稳定 ...

信息不充分：这些文件会不会经常增加删除，文件会不会被修改，查询的频率是怎么也的，最常用的查询方式和条件是什么。

另外，技术咨询是要收费的。

作者: wwwsq 时间: 2008-06-25 12:50

原帖由 zszyj 于 2008-6-25 12:34 发表

google公司全球服务器有很多，这是承认的，　但不见得就是都用于搜索网站．
另外，google其实是全世界有很多分公司，不同的分公司有自已的搜索服务器群，但其实从理论上讲，他们是属于不同的服务器群．本质上 ...

优秀的公司和卓越的公司，就是这么区别出来的。

优秀的公司可以很好的利用现有技术。而卓越的公司不但能很好的利用现有技术，而且能以批判的眼光看待现有的技术。

[ 本帖最后由 wwwsq 于 2008-6-25 12:54 编辑 ]

作者: benjiam 时间: 2008-06-25 13:02

原帖由 zszyj 于 2008-6-25 12:34 发表

google公司全球服务器有很多，这是承认的，　但不见得就是都用于搜索网站．
另外，google其实是全世界有很多分公司，不同的分公司有自已的搜索服务器群，但其实从理论上讲，他们是属于不同的服务器群．本质上 ...

按你的意思，在中国注册的用户在外国就不能登录了？
你上面的所谓连接池，行锁，这些都是最基础的。我也懒得回了，你连我说的什么意思都不明白。
至于服务器的数量，自己看看。

而且google 的服务器数量会不断的扩张，目前的gmail 服务下， db 是可以的。以后b c d e f 服务起来了
绝对就是瓶颈中的瓶颈。关键就在这里。

正是因为1亿用户查一下 0.1ms 都不到这种思想，导致了这种做法，没有什么伸缩性可言。
db 靠什么靠算法。
当goolge发现db 不能完成的时候 google 发明了bigtable.

最后申明一下我不是反对db 的人，改用的地方要用。但不是这样的用法。

作者: benjiam 时间: 2008-06-25 13:09

原帖由 wwwsq 于 2008-6-25 11:56 发表

区区不才，需要每天处理几亿条新增消息，一年是几百亿。经常要从所有数据（几千亿条）中做特定的查询。所以根据业务需要写了一个特别的存储系统，速度比标准数据库要快几个数量级，软硬件成本降低了几个数 ...

错了，我一直在尝试。  我一直在做类im的开发。

我也尝试过db 做完im  系统的中心。但是结果告诉我 NO

你的每天几一条  是实时处理吗？  相应的速度要求多少呢？和gamil的系统有可比性吗？做特定查询要求多久相应，数据的变化情况是怎么样的？每天变化多少？
实际比较起来根本就是2格概念的东西

最后最好能说一下  行业有几一条信息？一个公司？taobao .qq?

我们呼叫中心的信息细分出来点非常的多，都没有这么多。

作者: cx6445 时间: 2008-06-25 13:14

原帖由 wwwsq 于 2008-6-25 12:38 发表

信息不充分：这些文件会不会经常增加删除，文件会不会被修改，查询的频率是怎么也的，最常用的查询方式和条件是什么。

另外，技术咨询是要收费的。

可能你误会了，不需要技术咨询，呵呵！理论和实现是两回事！
你可以show一下你这方面的经验，不过如果你具有技术指导的资格，可能年薪几十万你不放在眼里。

[ 本帖最后由 cx6445 于 2008-6-25 13:17 编辑 ]

作者: wwwsq 时间: 2008-06-25 13:19

原帖由 benjiam 于 2008-6-25 13:09 发表

错了，我一直在尝试。  我一直在做类im的开发。

我也尝试过db 做完im  系统的中心。但是结果告诉我 NO

你的每天几一条  是实时处理吗？  相应的速度要求多少呢？和gamil的系统有可比性吗？做特定 ...

呼叫中心，只能算是“企业级应用”，用用J2EE那样的技术就足够了。后台么，用Oracle好了，反正企业有钱，我们省事。应用服务器么，用IBM的WebSphere吧，出了问题好和客户、IBM三方扯皮。

你要是用个MySQL，你们的销售都不好意思跟客户打招呼。

[ 本帖最后由 wwwsq 于 2008-6-25 13:21 编辑 ]

作者: benjiam 时间: 2008-06-25 13:25

原帖由 wwwsq 于 2008-6-25 13:19 发表

呼叫中心，只能算是“企业级应用”，用用J2EE那样的技术就足够了。后台么，用Oracle好了，反正企业有钱，我们省事。应用服务器么，用IBM的WebSphere吧，出了问题好和客户、IBM三方扯皮。

你要是用个My ...

恩不算多如果算上中国区肯德基3年（不算其他业务）的所有销售记录。做一个分析，你认为你能搞定？解破每个动作。计算订餐瓶颈在那里。靠你的db 要多久?

作者: wwwsq 时间: 2008-06-25 13:27

原帖由 cx6445 于 2008-6-25 13:14 发表

可能你误会了，不需要技术咨询，呵呵！理论和实现是两回事！
你可以show一下你这方面的经验，不过如果你具有技术指导的资格，可能年薪几十万你不放在眼里。

友好讨论，友好讨论，呵呵~~

每个人所处行业不同，采用技术的时候，倾向也会有所不同。我的经验未必适合你们。互相讨论提高吧。

作者: cx6445 时间: 2008-06-25 13:27

原帖由 benjiam 于 2008-6-25 13:25 发表

恩不算多如果算上中国区肯德基3年（不算其他业务）的所有销售记录。做一个分析，你认为你能搞定？解破每个动作。计算订餐瓶颈在那里。靠你的db 要多久?

TB或PB级的数据？用map-reduce的模型可以吗？

作者: benjiam 时间: 2008-06-25 13:27
最后说一下 kfc 200格座席在行业里是非常少的， 1000格座席起步。

作者: cx6445 时间: 2008-06-25 13:32

原帖由 benjiam 于 2008-6-25 13:27 发表
最后说一下 kfc 200格座席在行业里是非常少的， 1000格座席起步。

kfc那么多座席干吗的？我从来没打过kfc的电话。除了百胜的宅急送。

作者: wwwsq 时间: 2008-06-25 13:38

原帖由 benjiam 于 2008-6-25 13:27 发表
最后说一下 kfc 200格座席在行业里是非常少的， 1000格座席起步。

从数据量来说，每天产生的数据不超过1000w条，我觉得比较适合用数据库搞定。具体采用什么数据库，以及是否用数据库，还要综合其他要求来看，比如速度要求，查询复杂度，数据使用频率等。

[ 本帖最后由 wwwsq 于 2008-6-25 13:41 编辑 ]

作者: benjiam 时间: 2008-06-25 13:41

原帖由 cx6445 于 2008-6-25 13:27 发表

TB或PB级的数据？用map-reduce的模型可以吗？

原始数据不多的。3年一般是250*200*365*3 左右。节假日可能多1,2倍。

分解出来就多了一般 10个分析点左右。复杂的翻n倍。然后就做历史比较吧。计算趋势和找弱点。类似数据挖掘了。不过我们是给报表。

宅急送上海北京各一个中心，其他各自为证的。至于kfc 是不是走宅急送就不太清楚了。毕竟我是开发不是实施。

[ 本帖最后由 benjiam 于 2008-6-25 13:44 编辑 ]

作者: wwwsq 时间: 2008-06-25 13:45

原帖由 benjiam 于 2008-6-25 13:41 发表

原始数据不多的。一般是250*200*365*3 左右。
分解出来就多了节假日可能多1,2倍。

宅急送上海北京各一个中心，其他各自为证的。至于kfc 是不是走宅急送就不太清楚了。毕竟我是开发不是实施。

总共约5000w条数据，应该是可以用数据库解决的。

业务要求比较复杂，可以设不同的功能数据库服务器。

分析一般都是针对历史数据吧。把历史数据拷贝过去分析就是了，反正才5000w条记录。

系统的难点应该不是在于性能或者集群。我猜，难点应该是在业务功能的实现上，比如如何比较数据，如何挖掘数据。

[ 本帖最后由 wwwsq 于 2008-6-25 13:50 编辑 ]

作者: benjiam 时间: 2008-06-25 13:49
你们什么行业每天几亿？

作者: zszyj 时间: 2008-06-25 13:49

原帖由 cx6445 于 2008-6-25 13:27 发表

TB或PB级的数据？用map-reduce的模型可以吗？

说到数据分析, 不得不提目前世界非常热门的OLAP及data mining技术. 这些技术都建立在数据仓库体系之上.
而目前世界上最大的数据仓库, 由沃尔码建立, 号称数据量达到了PB级别. 而数据挖掘技术的出现及首先应用, 就是IBM常讲的"啤酒与尿布"的故事,也是来自于该公司的应用案例.
也许很多人都知道,但偏偏有一些人不知道的事实, 就是该数据仓库恰恰是建立在关系型数据库之上的--NCR的Teradata数据库! 这也是目前世界上数据规模案例最高记录保持者.
目前数据仓库的存储模式发展,分为两种方向,一种是MOLAP,其本质是文件系统,另一种是ROLAP,其本质是关系型数据库. 而事实上,真正能够承担TB级以上数据量,而且能够支持10维以上数据模型的,只有ROLAP. 不过, 好的ROLAP数据库与常规的关系型数据库是不同的,它提供了针对OLAP的大量新技术,比如按列存储,位图索引,static表,中间汇总表自动生成及上下钻取操作的支持等,在这种数据库上进行海量数据的实时统计,性能比传统关系型提高数十倍. 至今为止,优秀的ROLAP关系型数据库有ncr的teradata, sysbase IQ, informix red brick.
至于某些人坚持认为可以在文件系统上建立数据仓库, 那还是拿出案例,拿出数据对比再说吧.

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)