五千年(敝帚自珍)

主题:【原创】闲话Google集群 [6] 同步的苦恼 -- 邓侃

共:💬33 🌺52
分页树展主题 · 全看首页 上页
/ 3
下页 末页
      • 家园 Gmail的邮件标签

        不是非常明白老兄你的问题。Gmail的邮件标签,你是指什么?

        • 家园 Gmail中的每个邮件都可以由用户分配任意多个标签

          这些标签是用户自定义的。比如说,假如我有一个IBM开发者网络的帐号邮件,我可以给它两个标签,一个名为“IBM”,一个名为“帐号”,这样,我不论根据哪一个都可以很轻松地找到这封邮件。

          这是基于属性的数据检索,这些标签其实对应了邮件的不同属性。不过,基于属性的数据检索的实例很少见,GMAIL的这个大概是最著名的一个。我很想了解一下google是怎样实现邮件标签这种属性的存储的,以及如何根据这些属性进行检索。老兄当有以教我,先行谢过。

          • 家园 倒排索引和动态索引

            Gmail标签的实现,说难也不难,说容易也不容易。

            Gmail邮件的检索,是依靠inverted index来实现的。不妨用Lucene来体验一下inverted index(倒排索引)的功能。

            在Lucene里面,每个document,被分为很多fields。譬如email的To,Cc,Bcc,Topic,Body等等,都是fields。把每个document拆分为多个fields,然后把每个fields里的string取出,按terms建立inverted index。

            如果增加一个field,“label”,那么建立inverted index的时候,也相应增加相关索引。

            如果有些email没有label怎么办?如果没有label,那么按照label来检索就找不到。找不到不是坏事,就像有些email没有Cc一样。

            听起来很容易,当然前提是对搜索引擎技术需要比较了解。如果我前面的文字读起来费解,不妨先玩玩Lucene。花一个下午熟悉一下Lucene,再回头看我写的东东,或许就明白了。

            为什么说难?主要是动态建索引的问题。

            建inverted index不是一件轻松的活儿,通常每天只更新一次。但是注意到使用gmail时,你刚刚收到的email,就能被查到,而不是明天才能被查到,这是为什么?这是因为gmail里面有动态索引的技术。

            动态索引如何实现,说起来比较费事。以后再聊。

            • 家园 TAG检索 我猜应该是在客户端实现的

              考虑到用户的实际邮件数量, 和可能的tag数量,感觉上,这个tag的检索应该是在客户端实现的,服务器只是把tag信息持久化。

              另外 不知道大家有没有注意过,每次进入Gmail firefox的内存占用都有突飞猛进的增长~~~~ 很可能都是用来干这些事情了。

              • 家园 很有见地的猜测

                不过,我觉得不太像是在客户端搞得鬼,理由如下。

                如果是在客户端实现label,那么当用户点击一个label的时候,显示出的emails,应当仅限于在客户端cache的emails。

                譬如,在客户端只cache了20封emails,里面属于某一个label的emails只有5个,那么点击这个label时,应当只显示这5封emails。

                但是事实不是这样。不妨做一个实验,

                1. 打开gmail,每隔10封emails,就打个label。第一页的emails处理完后,翻下一页,再每隔10封emails,打个label,再翻下一页。如此这般做下去,会看到gmail在从server下载更多的emails。

                2. 清空browser的cache,关掉browser。重新开一个browser。

                3. 打开gmail,点击刚才订的label,你会发现所有刚才打了label的emails,统统显示出来了。

                结论,label的工作,多半是在server做的。

                不知道我的猜测是否正确?

                • 家园 有道理~~

                  不过应该跟本地cache无关

                  • 家园 我也是在乱猜

                    最可靠的办法,是找个Googler咨询一下。这个问题应该不是Confidential吧。

                    河里有没有Google的虾?

                    • 家园 label是在server实现的

                      确认一下:作为AJAX 最好的应用之一,Gmail都是在server side的干活,若干个月之前推出的Google Gears是本地存储的方案,但仍很不成熟。

            • 家园 花!期待“动态索引的实现”

              真能吊胃口啊

          • 家园 邮件标签

            汗,要不是你说,我还没有注意到Gmail这个功能呢。

            我先试试gmail的这个功能,否则胡言乱语,不负责任。

    • 家园 通俗易懂阿,呵呵,上花。
    • 家园 一看标题可乐了

      平时都跟着几位写家在英雄那边潜水

      今天一看邓兄这个标题就笑了

      GFS的东西之前确有接触 为什么捏 因为几年前遇见个比它更BT的案

      一个横跨亚欧大陆(从东边的日本一直到西边的意大利)四个国家N个点的数据同步问题

      抑郁的问题是涉及到协同工作,即这N个点里可能都在做同样的案子,一个地方更改了同时要反馈到其他的点去.按说如果有一个协同平台的应用级系统可以解决这个问题吧,可惜总的数据量都是TB级别.应用层面来解决的难度不是一般的大.从硬件层面来看(服务器和存储)而各个点之间的设备异构太大,厂商大谔们没一个敢接招的.

      更为关键的是预算又敏感,推倒原有架构重起炉灶的事情BOSS不批,且各点之间的专线带宽因为涉及到多个国家提升也确实存在问题.

      最后的解决方法非常好玩 不是现在热吵的什么硬件级别的灾备分中心拉 什么软件级别的重复数据删除拉 什么系统级的协同平台拉 或者拉一根可以3秒下一部DVD影片的专线拉(当然最终的解决方法肯定会是从技术层面彻底、根本地解决问题,不过那已经不干偶地事情拉)

      靠的是传统间谍最原始也最安全的办法--信使.

      别说后来一实验,效果还不错.因为这个庞大的实体当空中飞人的还真多,而飞之前都要报HR备案(各个国家的补贴、汇率计算方法估计不会比那个铱星"A国人通过B国的卫星在C国给正在D国HIGH的购买电话于E国的居住地在F国的G国人"打过一个电话的费用计算简单)于是一个小小的程序就解决了问题,飞人们带着个SATA硬盘飞来飞去,意想着有多少个TB的数据翱翔在亚欧大陆的3万英尺之上呵,多么地行为艺术——那可是阳春白雪和下里巴人的最最完美结合呢!

      • 家园 花一下,我以前孤陋寡闻的以为

        只有俄们中国人才能想出这种招。,

      • 家园 SneakerNet

        你别说,大教授从来不反对行为艺术。

        记得是Tanenbaum那本Commputer Network经典,或者是其它那本书里,就正儿八经地提过sneakernet的说法。意思是在某些环境下,不必过份迷信技术手段。

        • 家园 SNEAKERNET是最为彪悍的存在

          也就是最早的网络。。

          传说中人们要共享文件就把文件考在软盘上。

          然后再把软盘送到需要的人的手里。

          完成这次共享 由于是走着过去的 所以就叫所以SNEAKERNET叫鞋子网也就是人工网络 ...

分页树展主题 · 全看首页 上页
/ 3
下页 末页


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

Copyright © cchere 西西河