Egg非结构化数据库软件-设计说明书

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

产品概述

产品介绍

Egg是一个高性能、可扩展、并支持分布式存贮的非结构化数据库,同时也具备了部分非关系型数据库具备的结构化查询功能。该类型的数据库被广泛应用于搜索引擎、海量信息检索系统、音频视频管理系统等领域,成为这些领域中必不可少的一个组成部分。Egg是一个完全由C编写的,成熟的软件,并且是埃帕Cooling搜索引擎软件、Cooling云桌面平台软件、Cooling云输入法的重要组成部分,已经运用到了互联网、信息检索、数据挖掘、虚拟化等多个领域中。

行业背景

随着互联网的不断发展,搜索、云计算、WEB 2.0等全新的应用模式不断涌现出来。这些新应用都有着一些非常显著的特点,如:信息量巨大、信息结构化程度低、信息更新频度高、信息增长幅度大,并发访问频繁等。传统的关系型数据库,虽然能够胜任企业级别的信息管理,但在处理互联网级别的应用时,往往无法满足于以上的特点,暴露出了很多问题。

海量数据的高效存贮与访问要求

海量数据应用中最早,最典型的应用是搜索引擎;最有发展的是云计算;最流行的是WEB2.0中的SNS社区。

据CNNIC统计,截止2009年底,仅中国的网页数量就达到了336亿,较之2008年底,增长幅度接近100%。搜索引擎不光要存贮这些网页的基本信息,同时又要解决平均每天几千万网页的增长量。云计算、需要将原先用户端的应用、服务、数据移到服务端,利用服务端的计算、存贮、带宽、管理优势,提供相比传统桌面应用更有竞争力的服务方式。WEB 2.0中最主流的SNS社区,每天都要产生大量的用户动态信息,以Facebook为例,每月用户动态记录就达到2.5亿条;另如一些Web 门户,都已经达到上亿帐户数量。所有的此类应用中的存贮要求,都已经超过了关系型数据库可以容纳的范围。Google是最早采用了廉价硬件

(Commodity Hardware)建立分布式存贮的互联网公司;Amazon则在云计算平台中,采用了Yahoo与apache合作开发的分布式文件系统Hadoop;Facebook则为业界贡献了Cassandra,这一分布式的非关系型数据库。

高可用与可扩展性的要求

关系型数据库具备一定的高可用性与可扩展性,但这是建立在企业级可预测数据的前提之下的。而对互联网应用来说,没有任何人能预测下一年新增的网页数量、云计算平台的使用人数以及社区将拥有的用户数。唯一可以肯定的就是,所有这些数据都会以一个相当快的速度增长。当一种存贮方式,无法满足面对应用的增长而动态扩展,将对互联网业务的发展,产生严重的负面影响。此外,互联网应用要求所有系统都要能够全天侯提供服务,即便系统升级、增加设备、出现故障。而传统关系型数据库的扩展、维护都需要停止数据库实例,而无法实现实时维护,这也导致了传统的存贮方式,无法满足目前互联网发展的需求。

高并发访问的要求

搜索引擎、云计算、WEB 2.0每天都要面对大量的用户访问。2010年,Google与Facebook的访问量,占据了全美访问量的14%。在如此大的并发下,存贮或数据库的负载将非常之高,将达到每秒上万次读写请求。在如此大的读写压力之下,既便使用了Raid之类的技术,硬盘IO也已经无法承受,或是在有限的时间内完成读写操作。

非结构数据存贮的要求

关系型数据库从设计准则上来看,是对具备明确结构信息的数据进行管理。但目前、无论是在互联网应用,或是企业应用中,非结构化数据(网页、Office文档、文本、PDF、甚至音视频)都占据了总信息量的85%以上。这些数据虽然能用关系型数据库进行存贮,但却无法进行有效的检索。因为为些数据种类繁多,且都无法用结构化的方案(Schema)来描述。

在以上四个要求前,关系型数据库显得无能为力,但这并不是说关系型数据库就是一个失败的产品。只能说,关系型数据库不适合不断扩展的海量数据应用。关系型数据库本身具备强大的

事务完整性控制

实时读写能力

结构化查询能力

但是这些功能,在很多应用中并非必要、或者说可以通过其它的方式代替。对于事务完整性,很多互联网应用都是强调用户交互性,操作

往往很简单,或者说在设计之初,就尽可能的避免会造成复杂事务的设计。而实时读写、搜索引擎虽然不断抓取数据,但供用户访问的索引,往往一天才更新一次,但这样的频度对用户来说已经足够。结构化查询能力,最典型的特点是能够支持多表的关联操作,但实际上在设计超大规模系统的时候,即便使用关系型数据库,设计师也知道单表的设计虽然在结构上不优美,但确能提供最高的效率。

目前开始流行的非结构化、非关系型数据库的发展方向,就在于解决前4个需求,同时弱化并非主要的关系型数据的3个特点。

产品方案

总体架构

Egg从结构上可以分布两层,上层为数据存贮层,下层为分布式文件系统。

Client

IndexCache

SearchCache

Index.Map

Id.Map

Pos.Map

Field.Map

Doc.Map

Analysis

Similarity

Master Node

Rack1

Slave Node

Block

Block

Block

Block Slave Node

Block

Block

Block

Block

Rack1 Slave Node

Block

Block

Block

Block

Slave Node

Block

Block

Block

Block

数据存贮层

Egg存储主要分为三层,分别是Cache缓存层,Mapping映射层以及文件存储层。

Cache缓存层

Cache缓存层,是一个基于HashTable访问存储层。每一块缓存数据都由一个关键字符串key标识,并可通过此关键字符串key访问到相对应的缓存数据。它主要有两个特点:

一、在索引过程中,可以减少系统I/O写频次,单元数据也便于集中存储入文件中;此外,对于多进程写数据,可以统一录入,减少文件锁频繁操作;为了避免过多使用系统内存,Cache缓存层可设置内存占用的上限。

二、在反向索引过程中,可以减少系统I/O读频次。SearchCache中有个叫缓存命中的机制,提高检索效率,减缓系统I/O压力。

Mapping映射层

Mapping映射层,是一个基于文件映射的存储层,与磁盘中的文件形成一对一的联系。这一层中包含了:索引区(Index.Map)、文章区(Doc.Map)、字段区(Field.Map)、位信息区(Pos.Map)、ID区(Id.Map),它们分别对应着五个文件。文件映射采取的是块读写,并对文件区域进行“格式化”划分,便于快速映射定位以及校验非法操作。

分词器接口

Egg对外提供分词器的统一接口,无论是空格分词器、英文分词

相关文档
最新文档