主题：【原创】云里雾里的云计算 [1] -- 邓侃
搜索引擎之所以能搜索关键词，是因为其内部建了一个倒排索引（inverted index）。
譬如在一堆文档中，有一个编号为101的文档。某个关键词“西西河”，在它的第230字节处，第339字节处等等位置出现过。
当用户搜索“西西河”，搜索引擎在倒排索引中一查，发现在101文档中，出现过“西西河”这个词，于是返回给用户101文档的URL。
假设，我们预先对101文档加了密，那么建倒排索引的时候，怎样才能知道第230字节处，第339字节处等等位置出现过“西西河”这个词呢？
现在没有办法解决这个问题。
进一步讲，除非对倒排索引的数据结构，以及搜索引擎查询的算法做大手术，否则，即便有办法解决上述问题，也是不能用的。为什么呢？
如果倒排索引能够知道在加了密的101文档中，每个字节处是什么单词，那么就不难复原，加了密的101文档的原始内容。换句话说，对101文档加密，就变得毫无意义了。
周五晚上写完后，睡了一大觉。接近中午的时候醒来。
一醒来LD就说，“太守给你的帖子回复了，逮着你一个硬伤，如果文件加了密，是不能建倒排索引的。”
我哈哈一笑，“正愁没有办企业的创意呢。如果能想个办法给加了密的文件建索引，不愁Google不来收购呢。”
本帖一共被 1 帖 引用 (帖内工具实现)
不敢充当Google的发言人，只是从公开的论文猜测Google的检索系统架构大概如下：
- Google的检索系统不是一个大系统，网页搜索有自己的系统，其它verticles（如图片，地图等）有各自的系统。
－ 但是这些检索系统是在统一的基础架构之上，猜测为Google的GFS, MapReduce, BigTable等。这些检索系统有同质性，但也有各自特点。
－ 如果支持加密，个人认为应该是在基础架构层面。比如，Google在美国某次听证会上说明自己是如何对用户私人信息进行保护（这也是我在回应太守兄“这个云计算，不光是技术问题”一文时最后引用的那个例子）：Google当时回答的问题是怎么才能够让自己存储用户信息，使用用户信息，但自己又看不到用户信息（卖个关子，大家开动脑筋想一想？）
此算法应该是在BigTable里面实现。所以，我觉得，加密应该在Google的存储和计算层（即它的基础架构层）实现，所以前文提到“它目前的搜索架构是无法支持加密的”。
邓侃在他的“Google集群系列”里对上述架构有更详细阐述，望指教。
在线服务还是比不上本地的程序。
起码开展多线程比较有难度。
在就是相应速度上也不行。
最后，还有就是java平台的各种不兼容问题。
1、加密的目的是要保密，这必须在信息生成的时候就加密，并且不能在最终用户读取前进行解密，这在原理上决定了，加密和检索是不相容的（也许可有单独的非加密关键字，但是对正文的全文检索肯定不行的）
2、如果在Google的在基础架构层加密和不加密没什么区别。因为从技术上看，只要Google能解密就是不安全的。如果Google不能解密，那么也就不能检索。
本帖一共被 1 帖 引用 (帖内工具实现)
组件其实都过剩
除了 Word Excel PowerPoint Outlook/Entourage 之外, Office 2007 还包括如下组件:
* Microsoft Access
* Microsoft Publisher
* Microsoft InfoPath
* Microsoft OneNote
* Microsoft Project
* Microsoft Office SharePoint Designer
* Microsoft Visio
* Microsoft Office Accounting
* Microsoft Office Communicator
* Microsoft Office Document Imaging
* Microsoft Office Document Scanning
* Microsoft Office Groove
* Microsoft Office InterConnect
* Microsoft Office Picture Manager
从易用性和产品的整合角度看，这个马戏团式的套件完全该被划分为”去死去死“一族。
信心是无价宝
对于google现在的云计算来说，对于安全的信心现在是软肋
ps：
恭喜：你意外获得【通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
既然越来越多的河友对加密问题感兴趣或有质疑，我就把回帖直接放在邓侃原文下，期待更多的眼球，呵呵。
先总结一下大家的问题和论点：
－ 太守：（对于企业用户）如果只是把信息加密后存放在GOOGLE的服务器上，如何做加密后的搜索？
－ hansens 在“在基础架构层加密和不加密没什么区别”一文里说：加密的目的是要保密，这必须在信息生成的时候就加密，并且不能在最终用户读取前进行解密，这在原理上决定了，加密和检索是不相容的（也许可有单独的非加密关键字，但是对正文的全文检索肯定不行的）
上述问题是基本的，目前主流观点是搜索和加密并存在原理上不可行。
从实现上：
－ 对于我的“如果支持加密，个人认为应该是在基础架构层面”，hansens持相反意见：如果在Google的在基础架构层加密和不加密没什么区别。因为从技术上看，只要Google能解密就是不安全的。如果Google不能解密，那么也就不能检索。
从Google公开资料来看，它的确没有同时满足加密和检索的方案，但是，理论上是否可行？我先抛砖引玉一下，谈一个非常基本非常粗略的想法，很可能有大破绽，请太守，hansens和其他河友指教。
我们先来定义企业对于搜索的要求：相对于web search，企业搜索应该简单很多——没有spam，没有恶意点击，也许，email和docs搜索更简单，和传统information retrieval没有太大区别，连PageRank都不需要。
在这样的环境下：不考虑NLP，不考虑语义，不考虑name entity （例如，“张美美”明显是一个人的名字，所以搜索张美美最好不要出“一张美美的照片”等结果）等等，搜索就是看一篇文章是否含有搜索词：A, B, C, etc，以及这些词在该文中相隔的距离。
说到这，大家可能已经猜到我的答案了吧
——是的，办法就是：对原文加密，对于搜索关键词加密，只要它们用的是同一个密钥，就可以知道原文和搜索词之间的相关度了。在此过程中，原文和搜索词的加密都可以在信息进入Google的系统前进行，密钥可以掌握在企业手里，Google看到的就是一坨又一坨乱码。
所以，找到答案的最好办法是简化问题
。
如果真的这么简单，早就实现了。。。。。
我的想法是，搜索在客户端实现，但也有其他问题。。。。
绝对爱看，无深入不浅出！
虽然是同一个马甲，但是说话的人却有两个。
我觉得这个办法保密性不高。理由是这样的。
1. 虽然Google看到的是一坨又一坨乱码，但是通过索引，Google知道这坨乱码是怎么分词的。这个信息非常有助于Google解密。
2. 也是通过索引，Google能知道一篇文章中各个词出现的频率。这个信息也非常有助于解密。
所以，的确Google看到的是乱码，但是由于以上两个原因，Google很容易解密。
一旦解密了一篇文章，那么这个企业的密钥就被Google破解了。
这个办法可行，但是保密性不高。