或者如下这种:
上述两种存储方式无论选哪一种,都不能很直观地呈现两名学生的各科成绩与各学科之间隶属关系,在存储空间上的
利用也不尽如意,并且可扩展性也不够好。当然,为了解决这些问题,我们还可以使用多张表单来存储学生的成绩,
但这样也会使数据库中的内容更加复杂。
1.3 MongoDB的应用场景
在另一方面,对开发者来说,如果是因为业务需求或者是项目初始阶段,而导致数据的具体格式无法明确定义的
话,MongoDB的这一鲜明特性就脱颖而出了。相比传统的关系型数据库,它非常容易被扩展,这也为写代码带来了极
大的方便。
不过MongoDB对数据之间事务关系支持比较弱,如果业务这一方面要求比较高的话,MongoDB还是并不适合此类型
的应用。
另外,MongoDB出现的时机比较晚,还具备一些非常鲜明的特性。比如:
1. 它里面自带了一个名叫GirdFS的分布式文件系统,这就为MongoDB的部署提供了很大便利。而像MySQL这种比较
早的数据库,虽然市面上有很多不同的分表部署的方案,但这种终究不如MongoDB直接官方支持来得便捷实在。
2. 另外,MongoDB内部还自建了对map-reduce运算框架的支持,虽然这种支持从功能上看还算是比较简单的,相当
于MySQL里GroupBy功能的扩展版,不过也为数据的统计带来了方便。
3. MongoDB在启动后会将数据库中的数据以文件映射的方式加载到内存中。如果内存资源相当丰富的话,这将极大地
提高数据库的查询速度,毕竟内存的I/O效率比磁盘高多了。
但是,作为一个新鲜的事务,MongoDB也存在着很多不足。它在为开发人员提供了便利的情况下,却在运维上面临着
不少难题,比如:
1. 比起MySQL,MongoDB没有成熟的运维经验,需要不断地探索。
2. MongoDB中的数据存放具有相当的随意性,不具有MySQL在开始就定义好了。对运维人员来说,他们可能不清楚
数据库内部数据的数据格式,这也会数据库的运维带来了麻烦。
2. 测试目的
MongoDB与MySQL作为两种不同类型的数据库,当其中存放的记录越来越多的时候,其插入效率将会受到怎样的影
响,是本次实验所关注的对象。
在这里,我们将本次实验数据库中数据存储的规模定在1亿条。
3. 测试条件
机器配置: CPU:Intel(R) Xeon(R) CPU E5-2620 @ 2.00GHz
内存:65954040 KB
(关键词:12核CPU,64G内存,给我多好)
操作系统: Linux version 2.6.32_1-8-0-0 (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) )
评论0