当前位置:Gxlcms > mysql > MongoDB应用实践思考

MongoDB应用实践思考

时间:2021-07-01 10:21:17 帮助过:14人阅读

最近研究MongoDB,利用其可以简单快速地搭建一套灵活的no schema存储系统。本文通过论证和分析需求,利用MongoDB快速搭建了一套具有良好性能及可用性满足上亿规模的存储系统。在关于NoSQL数据库的选型上,需要结合自身 数据模型 、 访问方式 以及 成本 等方面

最近研究MongoDB,利用其可以简单快速地搭建一套灵活的no schema存储系统。 本文通过论证和分析需求,利用MongoDB快速搭建了一套具有良好性能及可用性满足上亿规模的存储系统。 在关于NoSQL数据库的选型上,需要结合自身数据模型访问方式以及成本等方面的考虑作一个权衡(trade off)。
那么经过研究MongoDB(2.6.4版本)有如下特点: 可用性:
1.支持高可用灵活的服务集群配置,有主从、副本集、自动分片模式。
2.基于文档的查询,高性能,简单查询上万的QPS。
3.支持全文检索。

一致性:
1.支持文档内更新模式,效率高。
2.当前最新的2.6版本采用读写锁、写锁优先,锁的粒度为collection级别。

易用性:
1.近似传统关系型数据库的SQL使用。
2.丰富的管理配置工具。
3.支持基于用户角色的权限管理体系。

存储机制:
采用mmap file + 内存索引的方式。内存与缓存管理由操作系统负责,当使用数据集大小超出时,性能下降。 Linux下内存控制可以通过配置用户ulimit -u 实现。
现实需求: 1. 需要存储字段灵活的半结构化数据。 2. 1~2亿条记录的存储规模,平均每条记录20k上限。 3. 读需求远大于写(以8:2计算),写以批量写入的方式,读需支持灵活复杂的查询方式。 4. 写性能:5000qps 读性能:2W qps
由于MongoDB灵活的存储和访问方式,以及良好的查询性能与伸缩性及维护成本,故想到利用MongoDB来存储这约2亿的数据量。 根据需求分析如下: 1. 以2亿规模计算,总存储量约4TB。现在市面上服务器硬盘最大有2TB规格的,部署时可以考虑以LVM方式,先安装1~2TB磁盘,待容量增长时根据需求方便地做扩容。 2. 在已存在1亿数据量的情况下插入1000W条记录,每次写入4条索引,qps能达到8000满足写性能的5000 qps需求。 3. 单线程简单读情况下qps能达到8W qps,换做多线程并发读取总性能也接近8W qps可满足2W qps的查询性能,后续若对读性能有增长需求可考虑从节点开启读权限分摊读压力。在测试中,读延迟 < 1ms。
根据需求论证的结果,利用MongoDB来存储这2亿条记录的方案是可行的。在实际部署当中,MongoDB支持多种方式有主从、副本集、分片。其中副本集相对于主从模式有自动故障迁移的优势,但是其也带来了复杂性和机器成本增加的劣势。 故综合考虑后,选用主从模式进行部署,选用服务器配置为16物理核 + 256G内存 + 2TB硬盘的机器两台搭建主备节点。 其中,从节点开启读权限,一方面应用层在主不可读时可向从节点发起读请求,另一方面前端可根据负载把部分读请求分摊到从节点上。 由于数据的写入求属于离线操作,故只需监控好主从节点的状态,能够及时恢复好服务状态即可。
通过以上实践,即完成了利用MongoDB快速搭建满足上亿级别存储的需求。

人气教程排行