IT牛人博客聚合

简介：IBM Research最近在Big Data领域有很多工作，例如我们组在4月份在10台采用POWER7处理器的P730服务器上成功地用14分钟跑完了1TB数据的排序，这项工作已经发表为一篇IBM Research Report，欢迎大家围观，并提出宝贵意见，谢谢。

The use of Big Data underpins critical activities in all sectors of our society. Achieving the full transformative potential of Big Data in this increasingly digital world requires b

查看全文: http://www.udpwork.com/item/7259.html

Google 发布了 Search, plus Your World，简称 Google Search+，带来最大的改变包括 3 点：

跟个人相关的搜索结果：你跟 Google+ 上好友发表过的链接和照片都会出现在搜索结果内，包括通过 Circle 限制为非公开的。

Google+ Profile：如果搜索人名，自动完成和搜索结果都会出现对应的 Google+ Profile。

相关 Google+ Profile：如果 Google+ 上有 Profile 跟你搜索的关键字相关，会出现在搜索结果页右侧。

其中最直接影响搜索结果排名的是第 1 点，后面两点都只是往搜索结果里插入少数 Google+ Profile 条目而已。

查看全文: http://www.udpwork.com/item/6767.html

先说一下搜索的原理，其实就是不管你搜索什么，都是将你要搜的东西提取出特征值，然后按照特征值比较相似度，按照相似度排序呈献给用户就可以了，所以总共来说需要解决两个问题，一个是如何取得特征值，一个是如何计算相似度。

首先说特征值，特征值可以用图片的颜色比例来，比如python用PIL中的histogram函数就可以得到颜色分布

这幅图的颜色分布直方图是这样的

通过这样我们就得到了一个图像的特征值，这种方法是得到的颜色的分配，还有另一种方式得到的则是图像的内容特征。
基本想法是将图片弄成8*8的小图片这样摒弃掉细节内容，将图片灰度，根据灰度确定一个阈值，然后转换成01矩阵，其他的内容都好说，简要说一下确定阈值的方法，有一个知名

查看全文: http://www.udpwork.com/item/6399.html

我们曾发布过一张图，显示微软帝国正四面临敌。
不仅如此，微软帝国似乎也在停止进化。请看下图。

同时，这张图也传达了一些当前各大公司追逐的热点或者核心业务：Google +1或Facebook Like，iPhone和iPad，Search或Social，Music Store或者App Store.
大公司都如此copy，小公司自然“不甘示弱”。只是，有些copy是大公司能做而小公司无法做到的。（创业，在哪都不简单。同志们加油！）
 
关于作者
何李石, PE.VC, Author
为用户提供以下咨询服务： 1. 海外VPS/共享主机购买。 2. LNMP(Linux, Nginx, Mysql & PHP)环

查看全文: http://www.udpwork.com/item/4768.html

看到这样一句话，想查查其出处：
Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
用Google一搜索，得到这个链接。其中有个出处是百度百科的这篇文章，截图如下：
用百度一搜，发现在百度上也根本没有文库的份儿:

用文库一搜，更是没有结果：

百度，你流量还要Google给你带来，难道转做SEO而非搜索了？
PS：可能有百度的员工会看到本文。本文只针对百度搜索引擎，没有针对人，更没有针对你们。
关于作者
何李石,

查看全文: http://www.udpwork.com/item/4726.html

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: fastsearch快速字符串查找算法

最近在做一个项目需要涉及到快速的字符串匹配，每秒几十万次的那种。之前我用过linux内核的的textsearch库的KMP,BM,FSM的算法觉得还不错，这几个算法用于Linux网络模块的关键词过滤系统，支持非线性的字符查找，但是对性能还是不够印象深刻。于是我想起了python的fastsearch. Python这样的脚本语言字符查找用的非常的密集，所以这个算法是非常的高效的，可以说这个算法很大程度影响着python的性能。我们来看下 作者的网站 怎么说的：

The Fast Search Algorithm (ak

查看全文: http://www.udpwork.com/item/4521.html

文章来自ReadWriteWeb。大致内容如下：

改变非常细微，以至于大多数人并不能感觉到变化。改变了算法，会影响11.8%的查询结果，同时也想让网民明白算法的改进。惩罚低质量网站：对用户没多少价值的，或者拷贝无用信息的网站。提升高质量网站的排名：有原创内容和信息的网站，如研究、深度报告和有思考的分析等。

这一举措对于互联网的发展非常有意义。特别是在互联网行使其作为一种查找和传播信息的工具的功能时。

在大家满嘴挂着团购、SNS和电子商务等时尚词汇的时代，Google能够静下来持续改进其算法，这是非常难能可贵的。功在当代利在当代啊。

 

查看全文: http://www.udpwork.com/item/4371.html

前两天在solr邮件组看到一封广告帖，一个叫searchblox的搜索产品可免费使用，好奇心驱使我简单了解并使用了一下。searchblox是基于lucene的搜索解决方案，现在的版本已经是6.1,看来也有些年头了。searchblox不是个开源产品，有免费的版本，也有收费的版本，看文档介绍，收费版本除了提供服务支持还多了复制功能。

功能上看，searchblox集成了爬虫和搜索功能，也提供Http API接口供索引和查询，可以在http://www.searchblox.com/developers/documentation上更多的了解searchblox的功能。但搜索功能方面，它也就是solr的子集。试用它很简单，下载解压缩

查看全文: http://www.udpwork.com/item/3706.html

据我不完全统计，solr代码中使用引用计数的用途有两种：一个是引用资源，一个是引用对象。技术上来说引用计数的使用没多少可大说的，不过如果没有正确的close获得的资源和对象，泄漏的bug就出现了。

引用资源

solr中供使用的IndexSearcher是SolrIndexSearcher，使用时它是寄存于RefCounted。RefCounted的代码如下：

public abstract class RefCounted<Type> {
protected final Type resource;
protected final AtomicInteger refcount = new Ato

查看全文: http://www.udpwork.com/item/3413.html

今天偶然发现google搜索结果的第一页上多了一个Beta版功能，非常强大。如果你搜索的时候已经登入了Google账户，google搜索结果的第一页的最后一项会是这样的：Results from people in your social circle for “…”，引号中省略的是你搜索的关键字。也就是说，google会在与该登入账户相关联的网络社交圈中搜索相关结果。
每个网民的网络社交圈界定了他/她的兴趣爱好，每次搜索的时候应该都是跟自己兴趣爱好有关的，而且Google拥有海量关于网民的数据，因此在网络社交圈中寻找结果可能得到更好的答案。不过，目前这个功能是Beta版。如果你搜索的时候只看前几项结果，可能会因为大意而

查看全文: http://www.udpwork.com/item/2999.html

当习惯于粗略浏览google reader中的未读条目后便似完成任务般的“全部标记已读”，我就经常性的错过不错的精彩条目，比如这篇 Twitter’s New Search Architecture。我是订阅了engineering.twitter.com的，但这并不影响我没有注意到它就把它mark过。今天看到这篇文章时，已经有别的网站将该文翻译成中文了，比如新 Twitter，新搜索，比如 新 Twitter，新搜索，我在这也就算是炒冷饭了。

twitter之前的搜索使用的是被它收购的Summize公司的技术，是基于mysql的搜索，具体技术细节不祥。 Finding A Perfect Match有提到，Summi

查看全文: http://www.udpwork.com/item/2997.html

可以大言不慚地吼著說：“我寫的！”

複用不好，很多冗餘代碼。設計不好，接口不明。寫法丑，不夠Pythonic。

唯一的優點是它確實能解決我的問題。數學建模一個題目“最佳陣容”，要算出所有得分會大于某個特定分數的出場陣容。

其實是一個0-1背包問題，但是約束條件比較多，算法自己又不在行，用回溯剪枝寫不出來。Lingo的規劃又只能做出一個解。

還好，動手算了一下，這個組合數也不過百萬級別，這對於現代的電腦完全是小case。所以用最丑的辦法寫了一個出來，當然，還是有點優化的。

程序我也不打算別人看懂，自己以后估計也不會再看，所以就不多解釋了。放這里做個留念，看看自己寫的程序有多丑。

#!/usr/bin/env python

查看全文: http://www.udpwork.com/item/2540.html

有网友留言询问我对zoie的DocIDMapperImpl实现是否有了解。说实话，之前看zoie也只是大面上的，知道DocIDMapperImpl的用处，但没有仔细分析它的算法。就趁着夜深人静，把这个类好好琢磨了下。但我得承认，看这种伤脑筋的算法让我有些吃不消，下面就列出我对它的大致分析，如果有不恰当的地方，也望指正。

还是说下DocIDMapperImpl的作用吧。在zoie中，uid和lucene的docid有一一对应关系。从docid到uid的映射很简单，就是分配个maxdoc大小的数组，索引位置是docid，值是uid。这样做也是因为docid是从小到大自增的，大小总有限。但uid是long型的，使用数组反映射是不行了，一

查看全文: http://www.udpwork.com/item/2066.html

Quine，或者说可以打印自己源代码的程序，通常被认为是比递归更神奇的东西，我以前也聊过这个话题。这次再提起来，是因为发现了另一个有趣的例子。

真相是，今天早上实验室网络检修，没法上网，而且由于考试周的接近自习室和图书馆都成了人山人海，几乎没有我等“散户”的容身之地，于是无聊中就把昨天下载的一篇传说很有趣的论文翻出来看了——发现果然很有趣。其实就是 Dahua 之前曾经介绍过的今年 CVPR 会议上分发的一篇最有趣的论文 Paper Gestalt。论文主要是讲了如何用 Computer Vision 的方法来自动判别提交到会议的论文的好坏并决定是否 accept，Dahua 的 blog 上已经介绍得很详细了，我在这里也就不多说

查看全文: http://www.udpwork.com/item/1844.html

Sphinx 0.9.9及以前的版本，原生不支持实时索引，一般的做法是通过主索引+增量索引的方式来实现“准实时”索引，最新的1.10.1（trunk中，尚未发布）终于支持real-time index，查看SVN中文档，我们很容易利用Sphinx搭建一个按需索引(on demand index)的全文检索系统。

参考文章：http://filiptepper.com/2010/05/27/real-time-indexing-and-searching-with-sphinx-1-10-1-dev.html

首先，从sphinxsearch的SVN下载最新的代码，编译安装：

svn checkout http://sphinx

查看全文: http://www.udpwork.com/item/1837.html

Zoie是LinkedIn开源的实时检索系统，它本身用于LinkedIn的用户profile页检索。且不说专业的搜索引擎，大多数的站内检索基本都不是实时的，一般都会有几分钟的延迟。但LinkedIn认为，用户profile信息的检索需要实时的效果，因为如果搜索结果不正确或不理想会很影响用户体验。所以，LinkedIn的Zoie实现了秒级别的实时检索效果。Zoie在LinkedIn跑了有两年多时间，这个开源项目可以说是起点就比较成熟的，这个项目提供了较为丰富的功能和工具，除了核心的API外，它还提供了管理和监控工具、嵌入jetty的Web server demo、一些实用的DataProvider等。实现上自然是基于lucene了，也

查看全文: http://www.udpwork.com/item/1646.html