文档数据库适应新媒体业务的应用研究
龚 昊
（新华通讯社通信技术局）
摘 要：在新媒体技术和应用蓬勃发展的当下，基于关系型数据库的应用系统在表结构的设计上消耗大量资源，同时必要的数据管理也降低了处理海量数据的性能。本文以文档型数据库MongoDB为基础，讨论了它的数据存储方式，以及与关系型数据库的相似性和差异性。以实际的新闻采编业务的数据为例，进行数据的存储和管理，并与关系型数据库MySQL进行读写性能比较。分析了由于数据库选型对整个业务上线的时效性和可靠性的影响。结合云计算技术和分布式数据库应用，描述了MongoDB的应用场景和性能初步分析。
关键词：MongoDB；文档数据库；敏捷开发；新媒体
1引言
在当前互联网和移动互联技术和应用快速发展的推动下，传统的新闻产品逐渐被新媒体所取代。尤其是年轻受众，他们更多地选择新媒体方式获取新闻信息。这些变化给新闻工作者带来了新的机遇和挑战，各传媒机构也使出浑身解数，研发新媒体产品，争取终端用户。新媒体发展与传统媒体最大的区别在于，不仅需要在内容及内容的组织上创新，还需要新技术支持新媒体新闻内容的快速发布。在一定程度上，信息技术的发展带动了内容的重新组织和发布。 在大数据时代，新媒体新闻信息的组织和数据存储管理成为一项极为重要的基础工作。关系型数据库自20世纪70年代发展至今，已经形成了一套完备的理论和技术体系。关系模型有严格的数学基础和逻辑抽象，简单清晰，便于理解和使用。这些特性使得关系型数据库成为现代数据库产品的主流，为信息数据应用提供了基础平台。不过，正是由于关系型数据库理想化的数据模型，也给数据类型的拓展带来一些困难。在效率方面，关系型数据库在进行大数据量处理和检索时，需要借助其他检索工具。最让应用开发者头疼的是，关系型数据库是基于数据表结构操作的，而在需求分析之初很难建立定义完整的表结构，后期的需求变更必将导致表结构的修改，迫使应用对已有数据进行一致性、完整性校验，导致难以采用敏捷开发方式快速响应新媒体应用的发展。针对上述问题，NoSQL孕育而生，有针对性地去满足大数量，快速检索等实际应用的需求。 文档型数据库MongoDB，是NoSQL家族中的一员，采用C++语言编写，能够为Web应用提供高性能的数据存储和管理服务。MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的。MongoDB最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引
2数据结构
MongoDB采用面向集合的存储方式。所谓面向集合，即一组类似的文档放在一块，形成一个集合，若干个集合便是MongoDB中的一个库。这里的集合类似于关系型数据库中的一个表，集合中的文档类似于一条记录。两者最大的区别在于，关系型数据库中的表需要先定义模式（Schema），即表结构，这是基于关系型数据库应用非常重要的一个步骤，而MongoDB中存储的文档结构不需要预先在集合中定义。集合中的文档，被存储为键值对的形式。键在文档中具有路径唯一性，为字符串类型，而值则可以是各种复杂的文件类型。我们称这种存储形式为BSON（Binary JSON）。这是一种类似于JSON，支持二进制序列号编码的文档组织结构。
2.1 基于BSON的文档数据 BSON在文档组织上与JSON相同，支持文档和数组的递归嵌套。BSON所支持的数据类型在JSON的基础上进行了较大的扩展，例如日期时间、二进制数据这样的数据类型。若将BSON类比二进制数据交换格式，它在语法和结构定义上更加自由，扩展性更好。略有不足便是数据传输过程中包含字段名称，使空间利用率降低。 因此，BSON在数据表达上非常灵活，且可读性很好。
2.2 数据操作 关系型数据库的数据操作基于SQL语言，SQL为我们提供了丰富的结构化数据操作功能，对于种类繁多的非关系型数据库，SQL语言已经无法支持在这样的数据集合中进行数据操作了。MongoDB也不例外，故而，MongoDB提供了十分丰富的基于文档的查询方法，这些方法足以满足应用对数据CRUD操作。例如：通过skip和limit方法简单地实现翻页。尽管这些方法不及SQL进行数据操作的一致性和可移植性强，不过针对特定场景的应用，特殊性也是必不可少的。 除了数据的基本操作，MongoDB支持对集合文档中的任意属性进行索引，包括文档中的嵌套字段，并支持多个字段的联合索引，这项功能可与关系型数据库媲美。在实际应用中，我们会发现一个与关系型数据库不同的现象，集合中并非所有文档都具备建立了索引的这项属性。换句话说，如果通过某个字段建立索引，并非所有的文档都能通过此项索引检索到，这是由于MongoDB灵活的文档组织形式决定的。 3与MySQL的写入效率对比 3.1 BLOB与GridFS 对于普通的字符串、数字、日期时间类型的存储，MongoDB都在集合中对应简单的对象进行支持，或是用字符串也能达到同样的效果。对于较大二进制文件，MongoDB使用GridFS，而关系型数据库一般采用大对象，即BLOB类型的字段进行存储。 基于MongoDB的文件存储，我们在数据库中会看到两个集合，一个是存储文件信息的fs.files，另一个是实际存放文件片段的fs.chunks。集合fs.files的文档中，系统默认的字段如表1所示：
表1 集合fs.files默认字段定义表
| 字段名 | 字段含义 |
| _id | 系统默认为文档生成的唯一对象ID。 |
| filename | 存储文件时，由应用提交的文件名称 |
| uploadDate | 文件存储的日期时间，ISODate类型。 |
| length | 文件大小，以字节表示，NumberInt类型。 |
| chunkSize | 块大小，实体文件存储时分块的大小，以字节表示，NumberInt类型。 |
| md5 | 文件的MD5校验码，字符串表示。 |
集合fs.chunks的文档中，对应存储了fs.files定义的实际文件，描述如表2所示：
表2 集合fs.chunks默认字段定义表
| 字段名 | 字段含义 |
| _id | 系统默认为文档生成的唯一对象ID。 |
| files_id | 存储内容对应fs.files中文档的对象ID。 |
| n | 本块对应为文件的第几分块，NumberInt类型。 |
| data | Mongo类型的二进制数据。 |
GridFS基于分片的的二进制对象存储机制也是为了更好地适应分布式数据存储的需求。 可以看出，BLOB仅存储文件的二进制数据而已，而GridFS存储了相关的文件属性，满足一般文件系统所提供的基本功能，更易贴近应用需求。 3.2 性能比较 任选新华社五天的文字成品稿，共计4124篇，提取十项主要信息，包括标题、作者、内容、关键字、稿号等。实验包含两个场景，一个是仅存储数据项；由于业务需求，要对原始的XML文件进行存档，因而另一个场景是同时存储数据项和原始文件。即在MySQL的记录中以大对象存储文件，在MongoDB的GridFS中存储二进制文件，其他数据项在文档中以元数据的形式表达。 测试的硬件环境为：Dell Optiplex 755台式机。软件环境为：操作系统Ubuntu Server 12.10，PHP 5.4.8，MySQL 5.5.27，MongoDB 2.2.0，mongo-php-driver-1.3.0beta2。编程语言为PHP，其中对CNML解析和相关文件操作采用同一组函数。因此，除去XML文件解析的消耗相同的时间外，对比的主要效率指标为数据库建立连接，写入数据和数据库连接释放的时间。
表3 MySQL与MongoDB的数据存储对比表
| 数据库类型 | 写入时长 （仅数据项） | 存储空间 （仅数据项） | 写入时长 （含文件） | 存储空间 （含文件） | 成功写入 记录数 |
| MySQL | 3.278s | 10.1MB | 7.529s | 45.6MB | 4208 |
| MongoDB | 1.884s | 10.8MB | 9.177s | 72.6MB | 4214 |
SQL语言具有完备的语法体系，通过mysql_query方法执行SQL语句进行数据写入，由于稿件数据中存在与关键字冲突的字符，导致异常失败。MongoDB提供有限的数据库操作功能，支持的字符串没有语法的限制，在写入数据时保证了成功率。从写入数据的结果可以看出，对于一般数据应用，MongoDB的写入效率略高于MySQL，占用的存储空间相仿。写入二进制文件时，效率略低，且占用存储空间较大。 文件效率略低主要原因是由于MongoDB在存储文件前会先对文件进行分片，然后再以二进制方式存储，相比一次性的对象存储耗时。存储空间上产生更多消耗的原因，一方面是由于分片技术存储更多的关联信息，占用空间；另一方面，MongoDB不仅存储了二进制数据，还包括文件大小等其他相关的信息。 数据读出包括两个实验，一个仅读出数据项，加载到应用程序的变量中，对比数据库连接及查询时长；另一项则不仅将数据项读出，还将二进制文件写入文件系统。针对两种数据库的此项操作，写入文件系统的时间是一致的，目的在于对比文件读出，并聚合写入的时间长度。
表4 MySQL与MongoDB的数据读取效率对比表
| 数据库类型 | 读出时长 （仅数据项） | 读出时长 （含文件落盘） |
| MySQL | 0.070s | 1.670s |
| MongoDB | 0.063s | 3.726s |
从表3、表4的实验结果可以看出，基于JSON风格表达的数据存取性能略优于传统关系型数据库，而对于大文件的存取，由于涉及分布式设计的考虑，数据库内部组织相对大对象略微复杂，分片等技术消耗时间和资源较多，效率下降。 4开发效率 基于关系型数据库的应用开发，在整理好业务需求后，需要再花上大量的时间设计数据表，除了表结构和表间关系外，最繁琐的是表中每个字段的类型定义和业务含义。这样加长了需求分析到系统上线的时间。利用MongoDB，可以让开发人员的主要精力集中到业务流程和应用开发上来，减轻对数据存储和完善数据结构的设计时间。这样做，可以适应新媒体业务发展要求，提高软件应用的更新效率， 在文件存储和管理方面，基于关系型数据库的解决方案一般两种。一种是采用LOB方式，存取较为复杂；一种是在数据库中存储文件路径，实际的文件放在文件系统中，这样在处理文件时相对方便。而新媒体应用中，大数据中涉及的大量文件，受到操作系统的限制，以及为方便应用逻辑实现，会按照树形目录结构去拆分，造成在查找文件及文件系统维护时相对麻烦。使用MongoDB进行小文件存储，应用程序直接面对文件，既能获取文件属性，又减少了路径至文件的转义，使应用开发更加便捷。 5数据库移植 为了使现有应用系统使用到MongoDB带来的优良特性，需要将现有的基于关系型数据的数据和应用移植到MongoDB上来。 关系型数据库在设计之初追求的便是表结构定义的完备，要求字段含义明确，减少歧义。因此，完整地将数据表移植为MongoDB中的文档数据，使文档具备完整的字段定义，这是一件相对容易的事情。业界已经开始做相应的尝试[1]。 在代码层面，需要重新组织已有的SQL语句，通过MongoDB驱动中所提供的方法去实现数据库操作。当然，若是复杂的SQL无法使用MongoDB提供的方法等价实现，那么就需要依托应用去实现这些SQL操作。 6结束语 MongoDB在具体的应用系统场景能够为业务提供比较优良的数据管理功能和性能，除此之外，MongoDB天生就是为分布式存储设计的数据库，能够非常方便地建立数据分片。有效地对集合进行分片（Shard）是MongoDB管理的一个重要课题。利用数据库的分片，可以使数据能够比较均衡地存储在不同的物理空间上，根据应用需求，既能够将同质的数据在逻辑上进行集中管理，又能根据实际的地域和应用需求将数据分布在不同的块（Chunk）上。数据库分布式存储，可以提高数据的写操作效率和数据维护的可靠性，同时也需要数据库管理员增加数据分布的设计意识，优化数据的读取查询效率。 一把钥匙只能开一把锁，MongoDB在云技术和应用的时代势必发挥承上启下的作用，适应蓬勃发展的新媒体时代对数据需求和管理提出的挑战。移动互联和大数据应用快速发展，产品更新淘汰频率加快，包括数据库架构设计等技术路线需要适应敏捷开发的需要，大量的应用数据呈现出数据零散，单个数据信息量小，预定义困难等特点。MongoDB在此正好可以发挥它的优势。结合云平台及相关应用，构建分布式数据环境，为应用提供海量的数据服务。 参考文献 1、Zhu Wei-ping, Li Ming-xin. Using MongoDB to Implement Textbook Management System instead of MySQL. Proceedings of 2011 IEEE 3rd International Conference on Communication Software and Networks(ICCSN 2011) VOL02 2、胡亦清. 舆情系统中倾向性分析与实现. 北京邮电大学 3、袁建军. 电子商务海量数据的获取、存储以及检索. 北京化工大学 4、http://bsonspec.org/#/specification
评论 点击评论