MongoDB应用实践思考

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MongoDB应用实践思考，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2479字，纯文字阅读大概需要4分钟。

内容图文

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

内容总结

以上是互联网集市为您收集整理的MongoDB应用实践思考全部内容，希望文章能够帮你解决MongoDB应用实践思考所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---