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

lose

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


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


而且goog ...

看到这里，我突然明白google只是在查询一个用户名是否存在时才用这个算法。而真正存储用户名就用其他的方法了。

同时也想起了上次奥运门票把服务器搞死的事情。这里面的学问还是很大的。

wwwsq

原帖由 benjiam 于 2008-6-25 13:49 发表
你们什么行业 每天几亿？

外星科技。每天分析太空中可能的外星人电报。

----------------------
以上是开玩笑


----------------------

什么行业不重要。确实有这样一些行业，需要面对非常海量的数据。

lose

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



外星科技。每天分析太空中可能的外星人电报。

----------------------
以上是开玩笑


----------------------

什么行业不重要。确实有这样一些行业，需要面对非常海量的数据。

移动吧？

flw

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

同时也想起了上次奥运门票把服务器搞死的事情。

奥运服务器死掉，是因为那套程序是花 3000 块钱从水木上找人做的。

zszyj

原帖由 benjiam 于 2008-6-25 13:49 发表
你们什么行业 每天几亿？

说到每天几亿行的数据量, 我觉得除了中国移动将全国数据集中的情况下, 其呼叫记录数量还有可能. 其它行业,想不出有这种可能性.
但是中国移动也只是省级集中, 每月10亿之内的话单内还有可能,每天几亿的,真想不出来有什么行业有这种可能性.
那当然,如果象QQ一样,每发一条信息都记录下来,并当作重要信息保存,那还是有可能,但看不出来意义何在.如果按这样算, 网络监控服务器将每个网络报文都记录下来的话,其数据量更是不可估量. 但是大家想想,这种能够犯得上提升到"管理信息"的层面去管理吗?

wwwsq

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

移动吧？

移动的话务日志确实数据量很大。我有朋友在给移动做项目。移动的数据好像是分市县存储的，所以每个市县的数据实际上并不是很多。

不过我不是移动行业的。

cx6445

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

说到数据分析, 不得不提目前世界非常热门的OLAP及data mining技术. 这些技术都建立在数据仓库体系之上.
而目前世界上最大的数据仓库, 由沃尔码建立, 号称数据量达到了PB级别. 而数据挖掘技术的出现及首先应用 ...

NCR的Teradata数据仓库界的老大，的确线性可扩，且不需要象oracle对于细节进行调优，
，沃尔马全球1600个节点。但就是贵。

oracle的cluster，还不是太成熟，似乎没有超过100节点的应用。

zszyj

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



移动的话务日志确实数据量很大。我有朋友在给移动做项目。移动的数据好像是分市县存储的，所以每个市县的数据实际上并不是很多。

不过我不是移动行业的。

移动的CDR确实是分布存储,由不同的交换机分别下来不同的数据文件. 但现在基本上都是集中上传到省中心批价,当然这个批价还是可以分开多台机器,多个进程处理.
但每月末, 还是会将本月所有清单记录装入BI系统的数据仓库中,一般在数据仓库里的存放时间要求是半年至12个月,因此还是能达到数十亿的数据规模. 不过,以这个规模, 也就是TB级, 尚离PB级远得很.

cx6445

每天数亿条记录现实中是不少见，ebay每天产生的日志全部入数据库，好象是1.2T一天。yahoo比这个数据量还大几倍，google不清楚，肯定也不会少。

zszyj

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


NCR的Teradata数据仓库界的老大，的确线性可扩，且不需要象oracle对于细节进行调优，
，沃尔马全球1600个节点。但就是贵。

oracle的cluster，还不是太成熟，似乎没有超过100节点的应用。

oracle适合做OLTP, 不适合做OLAP, 其OLAP组件, 其实是集成了原来的darwin express, 其本质还是MOLAP.
至于其RAC, 不要说100节点了, 就算是两节点,也达不到1+1=1.5的效果.
如果是我选的话, 我会考虑oracle做oltp, sysbase iq做olap.