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

benjiam

有人做过上亿用户吗？ 有上1kw个用户吗？

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

google 的确是nb 的。

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

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

benjiam

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


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

mysql

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



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

benjiam

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

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

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

benjiam

原帖由 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-6-25 09:30 发表
插入87W? 你这里是个循环, 每一个插入都要查询有无同关键字. 所以慢.

你插入一条就快了.

查询一个最快.

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

benjiam

原帖由 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 台服务器当机。   

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

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

benjiam

原帖由 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

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



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

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

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

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

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

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

benjiam

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



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

你要是用个My ...

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

benjiam

最后说一下 kfc 200格座席 在行业里是非常少的， 1000格座席起步。