MongoDB应用实践思考

最近研究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快速搭建满足上亿级别存储的需求。

MongoDB应用实践思考

上一篇:另类的表单数据"序列化"


下一篇:数据库-编译原理