西西河

主题:【原创】云里雾里的云计算 [1] -- 邓侃

共:💬620 🌺1262 新:
全看树展主题 · 分页
/ 42
上页 下页 末页
家园 对加了密的文档,搜索引擎内部的倒排索引目前无法建

搜索引擎之所以能搜索关键词,是因为其内部建了一个倒排索引(inverted index)。

譬如在一堆文档中,有一个编号为101的文档。某个关键词“西西河”,在它的第230字节处,第339字节处等等位置出现过。

当用户搜索“西西河”,搜索引擎在倒排索引中一查,发现在101文档中,出现过“西西河”这个词,于是返回给用户101文档的URL。

假设,我们预先对101文档加了密,那么建倒排索引的时候,怎样才能知道第230字节处,第339字节处等等位置出现过“西西河”这个词呢?

现在没有办法解决这个问题。

进一步讲,除非对倒排索引的数据结构,以及搜索引擎查询的算法做大手术,否则,即便有办法解决上述问题,也是不能用的。为什么呢?

如果倒排索引能够知道在加了密的101文档中,每个字节处是什么单词,那么就不难复原,加了密的101文档的原始内容。换句话说,对101文档加密,就变得毫无意义了。

家园 硬伤

周五晚上写完后,睡了一大觉。接近中午的时候醒来。

一醒来LD就说,“太守给你的帖子回复了,逮着你一个硬伤,如果文件加了密,是不能建倒排索引的。”

我哈哈一笑,“正愁没有办企业的创意呢。如果能想个办法给加了密的文件建索引,不愁Google不来收购呢。”


本帖一共被 1 帖 引用 (帖内工具实现)
家园 Google的检索系统

不敢充当Google的发言人,只是从公开的论文猜测Google的检索系统架构大概如下:

- Google的检索系统不是一个大系统,网页搜索有自己的系统,其它verticles(如图片,地图等)有各自的系统。

- 但是这些检索系统是在统一的基础架构之上,猜测为Google的GFS, MapReduce, BigTable等。这些检索系统有同质性,但也有各自特点。

- 如果支持加密,个人认为应该是在基础架构层面。比如,Google在美国某次听证会上说明自己是如何对用户私人信息进行保护(这也是我在回应太守兄“这个云计算,不光是技术问题”一文时最后引用的那个例子):Google当时回答的问题是怎么才能够让自己存储用户信息,使用用户信息,但自己又看不到用户信息(卖个关子,大家开动脑筋想一想?)

此算法应该是在BigTable里面实现。所以,我觉得,加密应该在Google的存储和计算层(即它的基础架构层)实现,所以前文提到“它目前的搜索架构是无法支持加密的”。

邓侃在他的“Google集群系列”里对上述架构有更详细阐述,望指教。

关键词(Tags): #集群#Google
家园 在线服务功能不强

在线服务还是比不上本地的程序。

起码开展多线程比较有难度。

在就是相应速度上也不行。

最后,还有就是java平台的各种不兼容问题。

家园 在基础架构层加密和不加密没什么区别

1、加密的目的是要保密,这必须在信息生成的时候就加密,并且不能在最终用户读取前进行解密,这在原理上决定了,加密和检索是不相容的(也许可有单独的非加密关键字,但是对正文的全文检索肯定不行的)

2、如果在Google的在基础架构层加密和不加密没什么区别。因为从技术上看,只要Google能解密就是不安全的。如果Google不能解密,那么也就不能检索。


本帖一共被 1 帖 引用 (帖内工具实现)
家园 Office 何止是功能过剩

组件其实都过剩

除了 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云计算,图的是个方便。

家园 信心最重要

信心是无价宝

对于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看到的就是一坨又一坨乱码。

所以,找到答案的最好办法是简化问题

家园 泼一下冷水

如果真的这么简单,早就实现了。。。。。

我的想法是,搜索在客户端实现,但也有其他问题。。。。

家园 反应冷淡是因为看傻了,不知回什么话好了

绝对爱看,无深入不浅出!

家园 这个办法的保密性不高

虽然是同一个马甲,但是说话的人却有两个。

对原文加密,对于搜索关键词加密,只要它们用的是同一个密钥,就可以知道原文和搜索词之间的相关度了。在此过程中,原文和搜索词的加密都可以在信息进入Google的系统前进行,密钥可以掌握在企业手里,Google看到的就是一坨又一坨乱码。

我觉得这个办法保密性不高。理由是这样的。

1. 虽然Google看到的是一坨又一坨乱码,但是通过索引,Google知道这坨乱码是怎么分词的。这个信息非常有助于Google解密。

2. 也是通过索引,Google能知道一篇文章中各个词出现的频率。这个信息也非常有助于解密。

所以,的确Google看到的是乱码,但是由于以上两个原因,Google很容易解密。

一旦解密了一篇文章,那么这个企业的密钥就被Google破解了。

这个办法可行,但是保密性不高。

家园 晕哦,注册一个“侃太"就那么麻烦吗?
全看树展主题 · 分页
/ 42
上页 下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河