MongoDB权威指南-第8章

MongoDB权威指南
应用程序设计
8.1-范式化与反范式化
简介
normalization范式化是将数据分散到多个不同的集合,不同集合之间可以互相引用数据
MongoDB没有提供连接(join)工具
denormalization反范式化与范式化相反:如果数据发生了变化,那么所有文档都要进行更新
范式化能够提高数据写入速度,反范式化能够提高数据读取速度
8.1.1-数据表示的例子
一种方式是使用一个students集合和一个classes集合,然后第三个结合studentClasses保存学生和课程之间的关系
如果要找到一个学生所选的课程,需要请求3次查询
如果将课程引用嵌入在学生文档中,只需要2次查询
如果要进一步优化查询速度,可以将数据完全反范式化,将课程信息作为内嵌文档保存到学生文档的”classes”字段中
优点是只需要1次查询就可以得到学生的课程信息,缺点是会增加更多的存储空间
也可以混合使用内嵌数据和引用数据,创建一个子文档数组用于保存常用信息,需要更详细信息时通过引用找到实际的文档
信息读取更频繁还是信息读取更频繁?如果这些数据会定期更新,那么范式化是比较好的选择
如果决定使用内嵌文档,更新文档时,需要设置一个定时任务(cron job),以确保所做的每次更新都成功更新了所有文档
评论列表或活动列表等信息应该保存在单独的集合中,不应该内嵌到其他文档中
8.1.2-基数
一个集合中包含的对其他集合的引用数量叫做基数(cardinality)
8.1.3-好友,粉丝及其他的麻烦事项
由于followers数组的大小会经常发生变化,所以可以在这个集合上启用usePowerOf2Sizes,以保证users集合尽可能小
对于比较有名的用户,可能会导致用于保存用户粉丝列表的文档溢出.对于这种情况的一种解决方案是使用”连续的文档”
8.2-优化数据操作
8.2.1-优化文档增长
对写入操作的优化通常包括减少索引数量和尽可能提高更新效率
更新文档时需要明确更新是否会导致文件体积增长,以及增长程度
检查一下填充因子,如果他大约是1.2或者更大,可以考虑手工填充
如果文档中有个字段需要增长,尽可能将这个字段放在文档的最后位置
8.2.2-删除旧数据
3种常见的方式:使用固定集合,使用TTL集合或者定期删除集合
最后一种方法是使用多个集合,ex:每个月的文档单独使用一个集合.对应用程序比较复杂,需要使用动态的集合名称
8.3-数据库和集合的设计
用户集合是最有价值的;保证用户数据安全是非常重要的.社交活动数据需要放在一个大流量集合中,它不如用户集合重要,但比日志集合重要
8.4-一致性管理
MongoDB支持多种不同的一致性级别
服务器为每个数据库连接维护一个请求队列.客户端每次发来的请求都会被添加到队列末尾
每个队列只对应一个连接.如果在其中一个shell中执行插入操作,接着在另一个shell中执行查询操作,新插入的数据可能不会出现在查询结果中.
为了提高效率,驱动程序会建立多个与服务器之间的连接(也就是一个连接池),但是他们有各自的机制来保证一系列请求会被同一个连接处理.
如果你的副本集比较小,可以使用”w”:setSize执行安全写入,如果getLastError没能成功返回,可将后续的读取请求发送给主数据库.
最简单的一种是将所有读取请求都发送到主数据库,这样就可以每次都得到最新最准备的数据,也可以设置一个脚本自动检测副本集是否落后于主数据库.
8.5-模式迁移
最简单的方式就是在应用程序需要时改进数据库模式,以确保应用程序能够支持所有旧版的模式.
MongoDB允许使用动态模式,以避免执行迁移,因为执行迁移会对系统造成很大的压力.
如果MongoDB在执行迁移中崩溃,最终的结果可能是只有一部分数据更新,还有一部分没有更新
8.6-不适合使用MongoDB的场景
MOngoDB不支持事务,对事务有要求的应用程序不建议使用MongoDB
在多个不同维度上对不同类型的数据进行连接,这是关系数据库擅长的事情.MongoDB不支持这么做,以后也可能不支持.
应用程序设计
8.1-范式化与反范式化
简介
normalization范式化是将数据分散到多个不同的集合,不同集合之间可以互相引用数据
MongoDB没有提供连接(join)工具
denormalization反范式化与范式化相反:如果数据发生了变化,那么所有文档都要进行更新
范式化能够提高数据写入速度,反范式化能够提高数据读取速度
8.1.1-数据表示的例子
一种方式是使用一个students集合和一个classes集合,然后第三个结合studentClasses保存学生和课程之间的关系
如果要找到一个学生所选的课程,需要请求3次查询
如果将课程引用嵌入在学生文档中,只需要2次查询
如果要进一步优化查询速度,可以将数据完全反范式化,将课程信息作为内嵌文档保存到学生文档的”classes”字段中
优点是只需要1次查询就可以得到学生的课程信息,缺点是会增加更多的存储空间
也可以混合使用内嵌数据和引用数据,创建一个子文档数组用于保存常用信息,需要更详细信息时通过引用找到实际的文档
信息读取更频繁还是信息读取更频繁?如果这些数据会定期更新,那么范式化是比较好的选择
如果决定使用内嵌文档,更新文档时,需要设置一个定时任务(cron job),以确保所做的每次更新都成功更新了所有文档
评论列表或活动列表等信息应该保存在单独的集合中,不应该内嵌到其他文档中
8.1.2-基数
一个集合中包含的对其他集合的引用数量叫做基数(cardinality)
8.1.3-好友,粉丝及其他的麻烦事项
由于followers数组的大小会经常发生变化,所以可以在这个集合上启用usePowerOf2Sizes,以保证users集合尽可能小
对于比较有名的用户,可能会导致用于保存用户粉丝列表的文档溢出.对于这种情况的一种解决方案是使用”连续的文档”
8.2-优化数据操作
8.2.1-优化文档增长
对写入操作的优化通常包括减少索引数量和尽可能提高更新效率
更新文档时需要明确更新是否会导致文件体积增长,以及增长程度
检查一下填充因子,如果他大约是1.2或者更大,可以考虑手工填充
如果文档中有个字段需要增长,尽可能将这个字段放在文档的最后位置
8.2.2-删除旧数据
3种常见的方式:使用固定集合,使用TTL集合或者定期删除集合
最后一种方法是使用多个集合,ex:每个月的文档单独使用一个集合.对应用程序比较复杂,需要使用动态的集合名称
8.3-数据库和集合的设计
用户集合是最有价值的;保证用户数据安全是非常重要的.社交活动数据需要放在一个大流量集合中,它不如用户集合重要,但比日志集合重要
8.4-一致性管理
MongoDB支持多种不同的一致性级别
服务器为每个数据库连接维护一个请求队列.客户端每次发来的请求都会被添加到队列末尾
每个队列只对应一个连接.如果在其中一个shell中执行插入操作,接着在另一个shell中执行查询操作,新插入的数据可能不会出现在查询结果中.
为了提高效率,驱动程序会建立多个与服务器之间的连接(也就是一个连接池),但是他们有各自的机制来保证一系列请求会被同一个连接处理.
如果你的副本集比较小,可以使用”w”:setSize执行安全写入,如果getLastError没能成功返回,可将后续的读取请求发送给主数据库.
最简单的一种是将所有读取请求都发送到主数据库,这样就可以每次都得到最新最准备的数据,也可以设置一个脚本自动检测副本集是否落后于主数据库.
8.5-模式迁移
最简单的方式就是在应用程序需要时改进数据库模式,以确保应用程序能够支持所有旧版的模式.
MongoDB允许使用动态模式,以避免执行迁移,因为执行迁移会对系统造成很大的压力.
如果MongoDB在执行迁移中崩溃,最终的结果可能是只有一部分数据更新,还有一部分没有更新
8.6-不适合使用MongoDB的场景
MOngoDB不支持事务,对事务有要求的应用程序不建议使用MongoDB
在多个不同维度上对不同类型的数据进行连接,这是关系数据库擅长的事情.MongoDB不支持这么做,以后也可能不支持.