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

产品概述

产品介绍

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对外提供分词器的统一接口，无论是空格分词器、英文分词

器，还是中文分词器，甚至更复杂的分词器，都可以为Egg挂载调用。为了更为有效的存储入文件，Egg分词接口要求序列化分词结果，各个分词器应遵循接口规则，实现序列化方法。

相关度评分策略

若检索是索引的反向操作，那么相关度评分则是分词的反向操作。在分词过程中，记录每个被分词器划分出来的关键字的位置信息，关键字之间位置近远和耦合度直接影响到相关度评分。若想获得较为精确的相关度分数，势必要将所有的位置信息一个不差的存储入文件中，这对文件的空间访问压力会很大；相反的，若想节省文件存储空间，相关度分数不能较为准确的反映用户所需要的查询结果。

Egg除了采用可变长整形类型VInt（VInt类型在文件存储上可以比Int类型至少减少3-4倍的空间），还有自己的评分策略。从实际角度出发，通常某篇文章它的重点和概括性的语句都会出现在文章的前部，那么Egg分词器针对这个特点只需要记录中文章前部重要的信息。换而言之，Egg不会记录全部的位置信息数据，但记录的数据肯定是最重要最有价值的。

此外，Egg通过用户查询数据的不断积累，形成了一套用户查询频次较多的关键字列表，在分词过程中针对频次较多的关键字，获得的不单单只是文章前部的信息，甚至是整篇大文章的信息，这样更利于评分的准确度，便于更好的反映查询结果。

索引方式策略

Egg索引采用的是B-Tree结构，并且支持变长关键字符串读写访问。B-Tree相对于其他存储结构的优势在于快速有效检索以及实时数据更新，它并不像HashTable每次数据新增或者更新需要重新建表。索引树上的每个结点都是固定大小（32Bytes），用于存储关键字。若访问的关键字超出了结点大小，此关键字被存放在其他数据块中而不是树结点上，而树结点中存放是此关键字的偏移地址。基于数据采样的特性和实际情况，树结点的固定大小是可以设置变化的。例如：关键字都是单字或者英文单词，那么固定大小可以设置偏小一点。

文件数据块存储策略

Egg在文件中存放数据时，会事先扩展比被存储的数据大小更大的容量。一般来说，Egg会将文件扩大32M-64M。这样做完全是为了能让Mapping映射操作更为快速有效，因为频繁的文件I/O读写是Mapping不利的。一次性扩大大空间也会减缓I/O访问的频繁度。为了便于维护管理，Egg对此扩展空间进行“格式化”，类似于malloc/free内存管理和资源回收。“格式化”中记录已用空间、未使用空间。每次有新数据要录入时，空间会检查剩余空间是否满足新数据的要求，若空间不足则会请求文件扩展磁盘空间。

Egg的分布式文件系统

Egg的分布式文件系统，称为Cooling File System（简称CFS）是一个典型的Master/Slave架构。CFS系统的集群，包含一台主节点（Master Node）与多个子节点（Slave Node）。主节点负责管理整个文件系统中的所有子节点，并提供对客户端提供文件读写的服务。所有的子节点都管理一片独立的存贮空间，实现最终的读写操作。CFS在存贮一个文件时，会将文件分成若干固定大小的块，这些块将被分配到不同的子节点，由子节点来最终保存这些块。主节点记录存贮在文件系统中的文件，并为每一个文件块分配一个唯一的id号做为标识。子节点接受主节点发来的命令，实现对文件块的读、写、复制等操作。

CFS主节点对客户端来说，就象是一个文件系统，并通过类似POSIX IO的API去管理这些数据。支持的操作有：open, close, read, write, pread, pwrite, seek, rename, remove。

CFS是一套独立的软件，使用GNU GCC编译器编译，遵循POSIX规范，能够运行于各类Linux操作系统之上，具备良好的迁移性。

文件系统结构

CFS在Egg中的目的，主要是为了服务于上层的存贮结构，因此CFS 中存贮的文件都会非常巨大，至少是G级别，同时不会有非常复杂的目录层次要求。因此CFS中只有文件，而没有目录的概念，同时也不支持链接。在将来的Roadmap中，这些功能也不会被加入进来。

主节点维护整个文件系统，所有的文件操作，以及基本配置信息都位于主节点上。

数据块分割

CFS将客户端发送的文件，分成预先设定大小的块，文件在内部以块序列的逻辑形式存在。该预先设定的块大小，在文件系统建立时便被确定好，不允许被修改。主节点维护所属的文件所包含的信息，这些信息包括对应的每个块的id，位于的子节点列表等。主节点为了效率，会在内存中维护这份列表，并定期写入到存贮中去。

数据块存放与复制策略

从理论上来说，每一个文件块，都可以放在集群中的任意一台子节点上，但实际上由于子节点数量众多，这些子节点往往位于不同的机架上，通过各种网络设备连接在了一起。与主节点在同一机架上的子节点往往会有更好的读写性能。CFS将位于不同机架上的子节点以机架进行分组。主节点将分割后的文件块，复制多份放到了同一机架的子节点，以及不同机架的子节点中，复制的数量由策略决定。复制多份的原因，可以有效提升数据的安全性，即便一个节点，甚至一个机架出了问题，都不会影响到数据的完整性。

数据块选择策略

由于数据块被分布到了不同机架的不同节点上。主节点在读取块的时候，将优先访问同一机架上的数据，如果同一机架上的数据无法访问，再尝试访问其它机架上的节点。

文件系统的安全检测

CFS和大多数文件系统一样，会定期检测数据的完整性。这个操作在文件系统启动了一定的次数后，会在启动时自动运行。除了象普通文件系统一样，检测文件是否正常外，还将检测所有的子节点是否工作，并检索位于不同节点上的文件块的一致性。

通迅协议

主节点与子节点通过基于TCP/IP层的自定义协议来完成。主节点对于客户端来说，是一个Server，每个子节点对于主节点来说，也是一个Server。子节点只被动的响应主节点的请示，并将操作结果返回给主节点。

失效节点检索与块重复制

主节点与子节点通过心跳线，保证所有子节点的正常工作。一旦子节点的心跳线消失，主节点将不会再发送任何请求给子节点。当子节点失效时，这往往可能由于短暂的网络故障引起，因此主节点会持续检测子节点的心跳线。当子节点失效一段时间后，这意味着某些文件块在集群中的数量会低于标准，这时就需要触发一个块的重新复制操作，将失效节点中的文件块，通过其它节点上的备份，再复制到新的可用的子节点中。

数据完整性

数据块的损坏，是一种常见的错误，源于各种原因，如网络因素，子节点文件系统，软件bug等造成。CFS为了应对这些错误，在主节点上记录了每一个文件块的检验和（Checksum），每次都进行检测，如是检测到了错误，则尝试从其它节点上访问相同的文件块，并触发一次块重复制。

Redo日志

为了应对异常情况，如主节点的突然掉电，硬件损坏，保障恢复后能将文件系统恢复到最后一次的正确状态。CFS通过Redo log记录每一次重要的文件操作，当恢复后发觉异常，将通过Redo log，恢复到最后一次正确状态。

文件缓存

主节点在写文件时，并不会马上分块并写入到子节点中。主节点会控制写入的大小，一旦超过了标准文件块的大小，才会将该文件写入子节点中。

产品特点

面向非结构化数据的管理方式

Egg所管理的非结构化数据是指那些没有数据模型描述、或者无法方便的由计算机程序处理的数据。这个定义用以区别那些可以用关系模型（Relation Model）中的准则：Relation（在关系型数据库的实现中称为Table），Tuple（在关系型数据库的实现中称为Record），

Attribute（在关系型数据库的实现中称为Field）来描述的数据。常见的非结构化数据有两大类，一类是数据的结构没有被定义过，但仍然可以通过一些方式来发现其结构；第二类是数据结构虽然被明确定义，但该定义并没有对计算机程序处理有任何帮助。第一类的例子有，能够由程序挖掘出结构的、自然语言文本（邮件、办公文档、网页内容、书籍等）、声音、视频等数据。描述这些数据所需要的结构需要通过特定的分析算法，如对于自然语言文本来说，可以通过词法、语法、或其它各类模式识别方法，提取其中的结构化成分。第二类的，指那些包含于已结构化数据中的非结构化内容。最典型的例子有HTML，HTML的标签已经将HTML文本进行了结构化描述，但这个描述仅仅是供浏览器显示时使用，而没有对包含的内容做任何描述。通常来说，第二类数据都能被转化成第一类数据，用统一的方法进行处理。

Egg为了实现非结构化数据的存贮，没有使用关系型数据库模型（RDBM）；与关系型数据模型的区别在于，没有了关系（Relation），取而代之的是集合（Collection）；没有了（Tuple），取而代之的是实体（Entity）；没有了属性（Attribute），取而代之的是（Field）。与以往的某些文档数据库（Document-oriented database）不同的是，Egg并不是架设在关系型数据库之上的表现形式的转换层，Egg自身实现了针对非结构化数据特点的存贮结构。

特征分析、数据挖掘等技术被Egg用来分析与提取所存贮的非结构数据中的特征。由于非结构化数据是一个非常广泛的定义，Egg并没有对它所存贮的非结构化数据做任何限定，也就是说，Egg可以保存任何种类的非结构化数据。但是对非结构化数据进行预先分类，然后对不同类型的数据运用不同的预处理及分析技术，将得到更准确的检索效果。Egg目前提供了针对文本、音频在内的多种预处理器与分析器，并公开

分析器接口，支持对末公开格式分析器的二次开发，以识别更多类型的数据。

对于文字来说，自然语言处理技术（NLP），是目前研究与运用的热点，也是Egg中运用最广泛的技术。文本分析器可以分析汉语、英语的网页、办公文档、纯文本（plain text）等文本。分析的方式包括，特征词，词性，语法树，句子依存关系等。

键值存贮

Egg具备非常完善的键值（Key-Value）存贮机制，同时具备以下特点：

键值对的值可以为任何类型的数据，并且没有长度的限制；

支持对集合类型的持久化，并且这种持久化可以建立在分布

式环境中；

支持Set，List，Ordered Set，B-Tree Set等集合结构；

所有的集合结构都支持保证原子的push、pop、add、remove

操作；

支持对集合的不同排序算法；

支持类似于关系型数据库的列查询；

为了获得更好的读写速度与数据持久化之间的平衡，所有的写操作都在内存中完成，并在一段时间后同步到磁盘上去。

键值存贮可以被广泛的应用到大型网站系统中，例如：电子商务网站中保存着大量的商品信息，这些信息几乎在所有用户访问的页面中都会出现，因此利用键值存贮可以大大提升性能；另外一种常见的领域就是社交网站中的用户信息，如Facebook都大量利用了键值存贮。

动态查询

Egg非结构化数据库的一大特点，就是动态查询。动态查询缘于非结构化数据库，不同于关系型数据库，不具备一个明确的方案（Schema）。非结构化数据，根据文档的内容，可以产生不同的域（Field）。使用者可以使用任何条件（Criteria）获得需要的数据。

Egg支持多种查询对象，查询可以用条件（Criteria）对象表达，也可以使用类SQL语法的表达式（Expression）表达。

Egg的查询条件，包含了对指定域中的特征进行与、或、非的操作，如果域中的特征为数字型，还可以进行比较查询。特征根据数据类

型的不同，而使用不同的分析器，会有不同形态体现出来。最常见的文本特征为，关键词，语法，词性等。

Egg支持对查询的结果集进行限定。这些限定包括：

结果集中包含的域（Field）的限定；

结果集条数的限定；

结果集范围的限定；

结果集排序方式的限定；

实时更新

实时更新，这个功能在关系型数据库中不是一个大的问题。但是，在那些需要分布式文件系统支持的，非结构化与非关系型数据库中，却并非一件易事。原因在于目前相当多的分布式文件系统，为了效率或定位，都不支持对此类文件系统中的文件进行随机写（Random Write）操作，这也直接限制了构建在之上的应用的实时更新能力。

Egg支持对存贮的数据进行实时更新，原因在于底层分布式文件系统的支持。

分布式文件系统

Egg的应用目标是那些需要对海量无限膨胀的非结构化数据进行存贮的领域，如搜索引擎、信息检索系统等。因此Egg对于整个存贮以及单个实体（Entity）的大小，并没有做出任何大小的限制，这个重要特性正是建立在Egg的分布式文件系统之上。

Egg实现了一个能够运行在通用硬件架构上的分布式文件系统。Egg的分布式文件系统被设计成了可以容错的，并能运行在低成本硬件之上；它能够支持对大文件，非常高的数据吞吐性能。Egg对数据的底层读取控制，由分布式文件系统来负责。

Egg的分布式文件系统具备以下特性：

大数据集支持。保存在Egg中的数据，往往具有很大的数据集。Egg上的一个典型文件大小一般都在G字节至T字节。因此，Egg的分布式文件系统被设计成可以支持大文件存储。提供整体上高的数据传输带宽利用率，并能在一个集群里扩展到数百个节点。一个单一的Egg实例应该能支撑P级别的存贮空间。

流式数据读写。运行在Egg上的应用和普通的应用不同，通常使用流式访问它们的数据集。Egg的分布式文件系统在设计中更多的考虑到

了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。POSIX标准设置的很多硬性约束对Egg应用系统不是必需的。为了提高数据的吞吐量，在一些关键方面对POSIX的语义做了一些修改。

准随机读写（Random Access）支持。这是Egg的分布式文件系统的一个非常重要的特性。之所以在随机读写前加上一个准，是因为Egg的分布式文件系统会将文件进行拆分存贮到不同的数据结点上，而为了保证流式读写，Egg的随机读写是基于文件块来完成，而非严格意义上的随机。但是这种方式仍然非常好的在功能与性能之间寻找到了一个好的平衡点。同时文件系统级准随机写操作的实现，让Egg能够更方便的更新存贮的数据，实现更强大的非结构化数据管理功能。

各类本地文件系统支持。Egg的分布式文件系统，严格意义上来说，它不是一个操作系统级别的文件系统。它的主要职责是将大文件进行拆分、并分别保存到不同的数据结点上去，并合理调度对文件的读写操作。每个数据结点上对文件块的操作，都由其本地文件系统来完成。因此Egg并不限定每个数据结点使用何种文件系统，只要符合POSIX规范即可，这样大大加强了Egg的兼容性。

容灾。硬件错误是常态而不是异常。Egg可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的，而且任一组件都有可能失效，这意味着总是有一部分Egg的组件是不工作的。因此错误检测和快速、自动的恢复是Egg分布式文件系统最核心的架构目标。

商业支持

APE为Egg提供了一整套完整的专业服务，服务领域包括：产品培训、技术支持、产品应用咨询服务等。同时并将建立Egg的社区，供开发者共同交流Egg使用中的经验，共同推动产品的发展。

可行性分析

目标市场

需要提供海量非结构化数据存贮的市场、如社区、云计算平台、舆情分析，信息检索等领域。

市场分析

社区

根据iResearch艾瑞咨询推出的网民连续用户行为研究系统iUserTracker最新数据显示，交友社区网站日均覆盖人数09年1月仅1767.7万人，至09年12月已经增长至3724.2万人，增长率超过100%。对交友社区网站用户行为及用户特征的研究，对深入挖掘社区网站价值和指导广告投放都具有重要意义。

根据艾瑞咨询站长部分的调研数据显示，2009年中国网络社区类型分布前十位中，综合社区（门户社区）的排名依然列于首位，34.6%的社区站长选择经营综合社区，较2008年的16.9%上升了17.7个百分点。艾瑞咨询分析认为，综合社区广泛的题材范围有利于吸引各个类型的更多用户，从而获取更大的流量，因此为众多中小网络社区站长的首选。然而，综合社区对于中小网络社区来说，并非长久之计，与大型社区相比，内容的丰富性和覆盖的广度并非中小网络社区的长处，在长期的竞争过程中，综合类中小社区持续性发展挑战较大。

这类社区都非常强调用户个性化信息，由于信息量大，更新速度快，大量的非结构化数据，需要实时生成动态页面和提供动态信息，所以基本上无法使用传统门户上使用的动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO 就已经无法承受了。目前主流的社区，如Facebook都已经使用了自主开发的非结构化或非关系型数据库以满足此类需求，但目前国内的社区普遍缺乏此类技术，因此很难构建出与国外相同的模式，整个行业都迫切的需要一个可供商用的产品。

云计算

云计算的重要性超过互联网其实很好理解，近几年来云计算市场发展迅猛。调查显示，在2000年已经使用，或准备使用云计算服务的企业不到10%.而到2010年五月，这个数字已经突破了60%.有报告称，未来

几年，基于移动设备和远程存储的云计算服务将被越来越多地应用。随着云应用范围的扩大，其在企业中的地位会不断攀升，对整个IT服务产业的影响也将不断增强。

云计算的实施，存贮是最低层的一个环节，也是非常重要的一个环节。目前不少国外厂商在原有的企业级应用上进行了扩展，提出了各类解决方案。但这些方案都有一个特点，就是都是以企业级应用的模式进行设计，并没有从一开始就针对互联网级别的数据类型、数据量与增长速度，同时伴随而来的是高昂的成本。云计算，本质上还是互联网的一个应用，整个行业也迫切的需要一个能够满足云计算特性的产品。

互联网舆情分析

据2009年6月的统计，中国网民总人数已经达到4亿，仅次于美国，这为网络舆论的形成提供了庞大的参与者。报告指出，与发达国家的网民相比，中国的网民更年轻，25岁以下网民占到51%，30岁以下的网民占到70%左右，年轻人成为网民的主力军，他们更乐于对社会、文化、经济方面的话题发表自己的看法。在这些年轻网民中，拥有大专及大专以上学历的占到40%，较高的学历决定了他们参与网络话题的热情较高，发言的质量也较高。

报告认为，中国互联网的舆论平台已经十分发达。几乎每个门户网站都设有BBS论坛，中国目前约拥有130万个BBS论坛，数量为全球第一。在“百度”网站，网民可以随时为某一话题设立专门的论坛，任何对此事件感兴趣的网民都可以到论坛发表言论和图片，平均每天发布新帖200多万条。几乎每条受网民关注的话题后面都有跟帖，热门新闻的跟帖达到几十万条。

对这些舆论信息进行分析，对决策提供导向支持，成为近年来非常热门的一个主题。但技术上面临的问题是，信息是充足的，分析模型是有的，报告是可以出的，但是这些的前提是，要保存所有的这些原始评论与信息需要大量的空间。整个行业也迫切的需要一个产品能够满足这个前提。

同类产品分析

新一代数据库的发展已经呈现一个上升的趋势，近几年诞生了多项开创性的产品。以下列举了Lucene、MongoDB、Redis、Cassandra共4种新型数据库进行对比。

Lucene是一个用Java编写的强大的搜索库，能够非常容易的被嵌入到各类应用程序中去。近几年，Lucene异常的流行，目前已经是应用最广泛的信息采集库，它的流行大大加强了普通Web应用的搜索能力。

Redis是一个高性能的键值（Key-Value）数据库，具备极高的并发读写性能，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作。

MongoDB (名称来自"humongous") 是一个可扩展的,高性能,开源,模式自由,面向文档的数据库.使用C++编写。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

Cassandra项目是Facebook在2008年开源出来的满足高可扩展性和可用性的面向分布式计算的数据库，Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。

下表对比了以上几个产品与Egg之间的对比：

Egg Lucene MongoDB Redis Cassandra 键值存贮具备不具备具备具备不具备具备具备具备不具备不具备非结构存

贮

动态查询具备具备具备不具备不具备

不具备部分具备不具备具备SQL支持部分具

备

动态存贮

具备不具备具备不具备具备

扩展

实时更新具备不具备具备具备具备