网上公开课资源收集

五月 31st, 2011 评论关闭
资源收集

在线观看:网易新浪搜狐腾讯奇艺 | 土豆 | 沪江英语

下载: 人人影视 | Open Classes |  VeryCD | 六维空间(IPv6)

公开课推荐

哈佛大学:公正课 [网易][新浪][搜狐][奇艺]

哈佛大学:幸福课 [网易][新浪]

耶鲁大学:博弈论 [网易][新浪][搜狐][奇艺]

耶鲁大学:聆听音乐 [网易][新浪][搜狐][奇艺]

耶鲁大学:欧洲文明 [网易][新浪][搜狐][奇艺]

耶鲁大学:哲学·死亡 [网易][新浪][搜狐][奇艺]

耶鲁大学:心理学导论 [网易][新浪][搜狐][奇艺]

斯坦福大学:经济学 [网易][新浪]

斯坦福大学:健康图书馆 [网易]

普林斯顿:领导能力简介 [网易][新浪][奇艺]

普林斯顿:科技世界的领导能力 [网易][新浪][奇艺]

 

特别推荐:网易【我们爱上公开课】专题

第01期:  人能否幸免一死

第02期:  你真的爱TA吗?

第03期:  很幸福?是假象

第04期:  善意谋杀=道德?

第05期:  同性婚姻=禁忌?

第06期:  心理暗示很强大

第07期:  敢对家暴说NO吗?

第08期:  欲望,该放纵吗?

第09期:  夫妻间的小亲密

第10期:  究竟怎么吃才好

第11期:  爱情也有保质期?

第12期:  昨晚你睡好了吗?

第13期:  完美主义强迫症

第14期:  互补型 or 相似型

第15期:  我们都有个创业梦

第16期:  你是说话高手吗?

第17期:  我们都想拥有它

第18期:  变身幽默达人

 

阅读全文...

几种常见的基于Lucene的开源搜索解决方案对比

十一月 19th, 2010 评论关闭

一  直接使用 Lucene  ( http://lucene.apache.org )

  1. 说明:Lucene 是一个 JAVA 搜索类库,它本身并不是一个完整的解决方案,需要额外的开发工作
  2. 优点:成熟的解决方案,有很多的成功案例。apache 顶级项目,正在持续快速的进步。庞大而活跃的开发社区,大量的开发人员。它只是一个类库,有足够的定制和优化空间:经过简单定制,就可以满足绝大部分常见的需求;经过优化,可以支持 10亿+ 量级的搜索。
  3. 缺点:需要额外的开发工作。所有的扩展,分布式,可靠性等都需要自己实现;非实时,从建索引到可以搜索中间有一个时间延迟,而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善

二  Solr  ( http://lucene.apache.org/solr/ )

  1. 说明:基于 Lucene 的企业级搜索的开箱即用的解决方案
  2. 优点:比较成熟的解决方案,也有很多的成功案例。Lucene 子项目,实现了大部分常见的搜索功能需求,包括 facet 搜索(搜索结果分类过滤)等。
  3. 缺点:可定制性比 Lucene 要差,一些不常见的需求,定制的难度比直接在 Lucene 上做要大的多。性能上,由于 Solr 的建索引和搜索是同一个进程,耦合度比较高,对于性能调优有一定的影响。

三 Katta ( http://katta.sourceforge.net/ )

  1. 说明:基于 Lucene 的,支持分布式,可扩展,具有容错功能,准实时的搜索方案。
  2. 优点:开箱即用,可以与 Hadoop 配合实现分布式。具备扩展和容错机制。
  3. 缺点:只是搜索方案,建索引部分还是需要自己实现。在搜索功能上,只实现了最基本的需求。成功案例较少,项目的成熟度稍微差一些。因为需要支持分布式,对于一些复杂的查询需求,定制的难度会比较大。

四 Hadoop contrib/index ( http://svn.apache.org/repos/asf/hadoop/mapreduce/trunk/src/contrib/index/README )

  1. 说明:Map/Reduce 模式的,分布式建索引方案,可以跟 Katta 配合使用。
  2. 优点:分布式建索引,具备可扩展性。
  3. 缺点:只是建索引方案,不包括搜索实现。工作在批处理模式,对实时搜索的支持不佳。

五 LinkedIn 的开源方案 ( http://sna-projects.com/ )

  1. 说明:基于 Lucene 的一系列解决方案,包括 准实时搜索 zoie ,facet 搜索实现 bobo  阅读全文...

转:Cassandra – 一个分散的非结构化存储系统

四月 28th, 2010 评论关闭

本文翻译自Facebook员工在LADIS大会上发布的论文.Cassandra – A Decentralized Structured Storage System
这篇论文中,两位作者详细介绍了Cassandra的系统架构,它的设计初衷,设计应用时使用到的相关技术,以及设计/实现/使用过 程中得到的经验教训.

Cassandra – 一个分散的非结构化存储系统
By Avinash Lakshman Facebook ,Prashant Malik Facebook; Translated By Jametong

概要

Cassandra是一个分布式的存储系统,可用来管理分布在大量廉价服务器上的巨量结构化数据,并同时提供没有单点故障的高 可用服务.Cassandra的设计目的是运行在由几百个节点(可能分布在多个不同的数据中心)组成的基础设施(infrastructure) 上.当节点达到这个规模时,大大小小的组件出现故障就可能经常发生了.Cassandra在管理持久状态时面临这些故障,这 种情况也驱动软件系统的可靠性(reliability)与可伸缩性(scalability)会依赖于Cassandra的服务. 虽然大部分情况,Cassandra看上去像一个数据库系统, 也与数据库系统共享大量的设计与实现手段,但是Cassandra并 不支持完整的关系数据模型;相反,它提供了一个简单数据模型的客户端,支持对数据布局与数据格式的动态控制.我们设计 Cassandra的初衷是,可以运行在廉价硬件上,并能在不牺牲读效率的情况下实现高的写吞吐量.

1. 导论

Facebook维护着世界上最大的社交网络平台,利用分布在世界各地的大量数据中心的成千上万台服务器,为上亿的用户提供服 务.Facebook平台有严格的业务要求,包含性能、可靠性、效率以及高度的可伸缩性以支持平台的持续增长.在一个包含 成千上万的组件的基础设施上处理故障是我们的标准运作模式;在任何时候,随时都可能出现相当数量的服务器或网络组件故障.这样,软 件系统在构建时就需要将故障当作一种常态而不是异常来处理.为了满足上面描述的这些可靠性与可伸缩性,Facebook开发了 Cassandra系统.
为了实现可伸缩性与可靠性,Cassandra组合了多项众所周知的技术.我们设计Cassandra的最初目的是解决收件箱搜索的 存储需要.在Facebook,这意味着这个系统需要能够处理非常大的写吞吐量,每天几十亿的写请求,随着用户数的规模而 增长.由于我们是通过在地理上分布的数据中心对用户进行服务的,因此支持跨越多个数据中心的数据复制对于降低搜索延时就非常关键了. 当我们在2008年6月发布收件箱搜索项目时,我们有1亿的用户,现在我们差不多有2.5亿的用户,Cassandra一直保持了其 对业务的承诺.目前,Facebook内部已经有多个服务部署了Cassandra作为其后端存储系统.
本文的结构如下.第2节讨论相关研究,其中的部分研究对我们的设计有很大影响.第3节介绍详细的数据模型.第4节简要介绍客户端 API.第5节介绍系统设计以及Cassandra中应用到的分布式算法.第6节介绍我们如何使用Cassandra部署 Facebook平台的一个应用.

2. 相关研究

对于为了性能、可用性与数据持久性对数据进行分布,文件系统与数据库社区已经进行了广泛的研究.与仅支持扁平命名空间 (namespace)的点对点(P2P)存储系统相比,分布式文件系统通常支持层次化(hierarchical)的命名空间.与 Ficus[14]与Coda[16]类似的系统都是通过牺牲一致性来复制文件以实现高可用(high availability).通常使用特别的冲突解决(conflict resolution)程序来管理更新冲突(update conflict). Farsite[2]是一个没有使用任何中心服务器的分布式文件系统. Farsite使用复制来实现高可用性与可伸缩性.Google文件系统(GFS)[9]是另一个分布式文件系统,用来存储 Google内部应用的各种状态数据.GFS设计比较简单,用一台主服务器存储所有的元数据(metadata),数据拆分成块 (chunk)存储在多个块服务器(chunk server)上.不过,目前Google已经使用Chubby[3]抽 象层为GFS的主服务器做了容错处理(fault tolerant).Bayou[18]是一个分布式的关系数据库系统,它支持断开操作(个 人理解为网络断开以后的操作)并提供最终的数据一致性(eventual data consistency).在这些系统中,Bayou、Coda 与Ficus允许断开操作,并且在遇到类似与网络断开与停机时能够做到自动复原.这些系统在冲突解决程序上存在差异.例如,Coda 与Ficus执行系统级别的冲突解决,而Bayou允许应用级别的冲突解决.但所有这些都保证最终一致性(eventual consistency).与这些系统类似,即使在网络段开的时候,Dynamo[6]也允许进行读写操作,并使用不同的冲突解决机 制(部分客户端驱动)来解决更新冲突.传统的基于复制的关系数据库系统重点在保证复制数据的强一致性(strong consistency).虽然强一致性为应用写程序提供了一个方便的编程模型,但是,这些系统在伸缩性与可用性方面却受到了限制.因 为这些系统提供强一致性的保证,所以在网络分开时,它们就无法进行处理.
Dynamo[6]是一个Amazon开发的存储系统,Amazon用它来存储检索用户的购物车.Dynamo利用基于Gossip 的会员算法来维护每个节点上所有其他节点的信息.可以认为Dynamo是一个只支持一跳路由请求(one-hop request routing)的结构化覆盖层(structured overlay).Dynamo使用一个向量时钟(vector lock)概要来发现更新冲突,但偏爱客户端的冲突解决机制.为了管理向量时间戳(vector timestamp),Dynamo 中的写操作同时也需要执行一次读操作.在一个需要处理非常大的写吞吐量的系统中,这可能会成为瓶颈. Bigtable[4]既提供了结构化也支持数据的分布式,不过它依赖于一个分布式的文件系统来保证数据的持久化.

3. 数据模型

Cassandra中的表是一个按照主键索引的分布式多维图.它的值是一个高度结构化的对象.表中的记录键是一个没有大小限制 的字符串,虽然它通常都只有16-36个字节的长度.无论需要读写多少列,单一记录键的每个副本的每次操作都是一个原子操作.多 个列可以组合在一起形成一个称为column family的列的集合,这一点与Bigtable[4]系统非常相似.Cassandra提供 两种类型的column family,简单的column family与超级的column family.可以将超级column family想象成column family里面嵌入column family.进一步,应用还可以指定超级column family或者简单column family里面的列的排序顺序.系统允许按时间或者名称对列进行排序.按照时间对列进行排序可 以被类似于收件箱搜索这样的应用使用,因为它们的结果始终需要按照时间顺序进行展示.column family中的每个列都需要通过规范column family : column来进行访问,每个超级column family中的列都通过规范column family : super column : column来进行访问.小节6.1给出了一个 展示超级column family抽象能力的非常好的例子.通常,应用都会使用一个独占的Cassandra集群,并将它们当作服 务的一部分进行管理.虽然,Cassandra系统支持多表的概念,在部署时每个概要中都只能有一个表.

4. API

Cassandra的API由下面三种方法组成.

  • insert(table, key, rowMutation)
  • get(table, key, columnName)
  • delete(table, key, columnName) 列名可以是column family里面的一个特定列,或column family,或超级column family,或超级列里面的一个列

5. 系统架构
一个需要在生产环境运转的存储系统的架构是很复杂的.除了真实的数据持久化组件外,这个系统还需要包含以下特性;可伸缩性与强大负载 均衡解决方案、会员与故障检测、故障恢复、副本同步、超负荷处理、状态转移、并发与任务调度、请求编组、请求路由、系统监控与报警以 及配置管理.详细描述这里的每一个解决方案超出了本论文的范围,我们将集中介绍Cassandra使用的核心的分布式系统技术:分 区、复制、会员、故障处理以及伸缩性.处理读写请求需要所有这些模块的协同处理.通常,一个键的请求可能被路由到Cassandra 集群的任何一个节点去处理.这个节点会确定这个特定的键的副本.对于写操作来讲,系统会将请求路由到副本上,并且等待仲裁 数量的副本以确认写操作完成.对于读操作来讲,基于客户端要求的一致性保证,系统要么将请求路由到最近的副本,要么将请求路由到所有 的副本并等待达到仲裁数量的响应.

Continue reading »

无觅相关文章插件,快速提升流量