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

wwwsq

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

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

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

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

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

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

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

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

wwwsq

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

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

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


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

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

wwwsq

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

移动吧？

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

不过我不是移动行业的。

wwwsq

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


的确重要性不等，不过在很多用户路径的计算中是不可少的，也是需求的一部份，不能因为需求相对不重要而不进行计算。

是的。这样一些非核心东西，往往才是决定你是否比别人优秀的地方。因为基础的核心的东西，大家都会做，都做得不差。基础都做不好的人，早就出局了。

比如淘宝，能做网上交易的公司不要太多，肯定也都做得correct。但是在如何做得好用上，就体现出了差别。连correct都做不到的公司，根本就不用去比较。

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

wwwsq

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

我看啊, 还是由那位"高手"写出一个"能支持10000并发写同时10000并发读,且具备分布式事务支持功能"的broom filter,让大家开开眼界的. 我等是没有这种本事的.

很多事情其实去做做就可以了，没你想的那么难。大多数时候数据库确实可以解决问题，但是你要看到，也有很多时候，通用数据库并不是最佳解决方案。

布隆过滤器并不是什么很难的技术，只是你愿不愿意去掌握和使用的问题。布隆过滤器也不是万能的。布隆过滤器常常是只读的使用，往往几个小时甚至几天才更新一次。布隆过滤器往往和黑白名单结合使用，而黑白名单常常是数据库。布隆过滤器擅长的是以极小的代价在瞬间给出一个基本的判断。

布隆过滤器可以瞬间作出100w次的判断，其中99.99%是确定性判断。剩下万分之一的不确定性判断，如果需要确定性结果，再交给其他模块（比如数据库）作确定性判断。

在判断新用户名是否可用这种情况下，不需要完全的同步，一个用户名被删除之后，完全可以过几天再允许别人再次注册。也就是说在判断用户名是否可用的时候，布隆过滤器可以几天更新一次，在这期间，布隆过滤器是不用修改更新的。
判断新用户名是否可用，也不需要完全确定性的判断，一个用户名我只要判断它是否“可能重复”就可以了。在极小概率下，即使新用户名实际上没被别人使用过，我也完全可以告诉用户说“此用户名已被使用”。

[ 本帖最后由 wwwsq 于 2008-6-27 06:42 编辑 ]

wwwsq

原帖由 zszyj 于 2008-6-27 09:58 发表

不管做哪个系统, 技术方案都需要严谨, 经得起推敲, 做哪个行业都不重要.
这个世界上, 并没有任何一套方案, 可以通用于任何不同的需求, 正如前面提到的, 其实每个疑问都是很客观的.
再者, 不管是银行还是电信 ...

你没仔细分析需求。

在判断用户名是否可用的时候，我们不需要完全确定的结果。我们只要知道“肯定不会重复”与“99%可能会重复”就可以了。当99%可能会重复的时候，我们就告诉用户，换个用户名再注册。

wwwsq

原帖由 zszyj 于 2008-6-27 10:46 发表

写那么多字, 有什么用呢? 不就是歪曲别人原意, 歪曲用户需求,同时扭曲自已的心灵吗?
将用户需求从"是否重复"强行下降为"可能重复", 也许只有你能接受.
你的hotmail账户不删除,可我的确实已经不能登录了, 无 ...

比如用户想注册“mynewname”，然后用过滤器检查发现没有重复，那就确定的告诉用户“这个用户名可用，肯定不会重复。”

比如用户想注册“mynewnameabc”，然后用过滤器检查发现可能重复，那就告诉用户，“这个用户名已经被人用了，请换一个用户名”。实际上，在极小的概率下，“mynewnameabc”可能还没被使用，只是有个“sdfadfsadfsadf”恰好和“mynewnameabc”的哈希值相同，没关系，在这种极小概率下，我们就让用户换个名字再注册。

wwwsq

原帖由 zszyj 于 2008-6-27 10:59 发表

你还没看明白我说的话, 只要你不实时刷新, “肯定不会重复”是肯定实现不了的.,这就是我指出的问题,为什么"黑名单问题""用户ID重复"问题.  是我没分析需求, 还是某人在故意弱化需求呢?

如果要精确判断，就要有黑名单。黑名单里面只要放最近几天新注册的用户名就可以了。这比同步处理几亿个用户名容易多了，成本也低得多。

wwwsq

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

你还是没想清楚吧, 只要不断有新用户注册, 就要不断刷新过滤器,否则无法保证"用户肯定不重复"这个要求. 这明显是不适用于bloom filter的.如果象某人所说,几天才更新一次过滤器, 你认为"用户肯定不重复"在没更 ...

“肯定不重复”是基于几天前的数据做出的判断。要精确的实时判断，就再从最近几天新注册的用户名里面再查找一次就可以了。

实际上这种冲突的概率实在太小了，也许等到了真正创建用户的时候再检查都不迟。界面上提示是否可用的时候，都不一定需要去检查黑名单（这取决于用户想不想让这个提示严格的100%正确）。

wwwsq

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

其实我觉得你也没细看, 别人的用法刚好相反, 是将黑名单放过滤器, 只要是垃圾邮箱,肯定被查出来. 不幸被误判的, 才会再找一次白名单(通常是放数据库里). 因此别人查库的可能性,只有0.01%的可能性,代价是很低的 ...

在注册新用户的时候，当然“已注册用户”就是“黑名单”了。因为“已注册用户”此时是不可用，需要被“新用户注册流程”所禁止的。

你能不能灵活一点，别人把垃圾邮箱当黑名单，你就一定也要用垃圾邮箱当黑名单？

同步和维护一张只有一万条记录的表，和同步维护一个有几亿条记录的数据集，成本是不一样的。

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