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

benjiam

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

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

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

zszyj

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


mysql

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



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

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

思一克

插入87W? 你这里是个循环, 每一个插入都要查询有无同关键字. 所以慢.

你插入一条就快了.

查询一个最快.

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


mysql

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



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

cx6445

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

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

可恶的

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

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

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

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

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

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? 你这里是个循环, 每一个插入都要查询有无同关键字. 所以慢.

你插入一条就快了.

查询一个最快.

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

zszyj

[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

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


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

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

cx6445

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


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

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