打造搜寻引擎或大社群网站所应注意的云端扩展性

浏览量227 点赞402 2020-07-11

打造搜寻引擎或大社群网站所应注意的云端扩展性

<图片来自 >

先前,在试做网页搜寻引擎的时候,提出几个应该要具备的 know-how。 其中,关于第六项,DB, server, 网路基于处理大量资料的性能调整, 并能有效处理分散运算,因为没对 Google 或其他搜寻引擎的做法深究,凭着直觉与过去卖给企业 DB 系统的经验,觉得是 採用一些平行运算的资料库丛集解决方案就可以。但显然事情并非如此单纯。

现在的网路及应用程式环境,资料量越处理越大。做个 twitter 红了,数千万 requests 的涌入,马上考验平台的稳定性。如果要设计一个搜寻 引擎或大型社群游戏之类的东西,会员破千万或资料量数百 terabytes,系统的可扩展性显然会是个非常重要应面对的首要任务。

为了达到 Tera 级乃至 Peta 级的资料处理,Google、Facebook、Amazon 以及其他公司怎幺做的?伟大的公司必然採用了伟大的技术,底下列出几个在设计高扩展性的系统应该注意的概念、元件与开源专案:

1. Google – Bigtable

原来 Google 不是用 RDBMS 来储存搜寻资料的。在我先前的试验中,也的确发现了 RDBMS 会有效能的问题,在  扩展上不易,且金额昂贵 。关于 Bigtable,从 http://trac.nchc.org.tw/cloud/wiki/HyperTable 抄了一段描述,看了就可理解:

2. Google – Google File System

分散到很多机器上,为了底层存放资料的稳定性,Page 自己发明了分散式容错的档案系统,用来将资料储存在便宜的 PC 上。

原始论文在  这里 。

3.  Google – MapReduce

MapReduce 是一个 programming 的 model。摘录 http://www.ithome.com.tw/itadm/article.php?c=49410&s=7 部分段落:

透过上面三个主要的元件组成,针对 1T 以上的资料,很快的取出正确所需的资料,而且能随者需求扩增的主要技术问题就解决了大半。

但是,BigTable 跟 Google File System 都是 Google 自家才能使用 。我们可以考虑哪些原件来整合,以达到高效能与高扩展性?尤其针对网页型或社群型的大量资料处理,该注意的元件或项目有哪些?

1.  HyperTable

基于 Google 发布的 paper,由 zvents 所做的开放原码专案,做的是分散式资料库系统。网址在  http://hypertable.org/,背后有 百度 的加持。

2. Cassandra

Facebook 释出的类似 BigTable 的分散式资料库系统,也是开放原始码,网址在 http://incubator.apache.org/cassandra/

3. HyperRecord

用 Ruby On Rails 开发的人不可错过,这是整合了 HyperTable 的 Active Record 版本。网址在 http://code.google.com/p/hypertable/wiki/HyperRecord

4. 其它应注意技术,通常在你的网站中会有需要使用:

4.1 memcached – 广为使用了,自行蒐寻一下。

4.2 Sphinx – 在资料库中用 SQL 搜寻,你不如对资料库做全文检索后,透过 sphinxd 搜寻引擎来搜寻。SQL 语句的搜寻特性是,下的条件越多可能会找的越慢。但 Sphinx 在找资料时,则是条件越多,找的越快。网址在 http://www.sphinxsearch.com/

4.3 扩展过程中,对不需要及时处理的页面或工作,加入非同步处理的元素。这时候,需要考量一些可以帮忙 queue 的东西:

例如:beanstalkd – 简单的使用介面,协助你把工作排入 queue,非同步地处理。网址在 http://kr.github.com/beanstalkd/

又,如果需要企业等级的稳定度,可考虑使用 RabbitMQ,网址在 http://www.rabbitmq.com/

5. Hadoop

Hadoop 不仅在实验室中受重视,也早已走到市场中,成为云端概念中最重要的专案。Yahoo, Google 与 其它数十上百的重量级用户 都在使用。不得错过的重要平台。

相关学习资讯可见 http://www.hadoop.tw/

本文同步发布在 http://stingtao.info