当前位置:首页>开发>正文

mongoDB适用什么场合呢 mongodb应用场景,举例说明。。谢谢高手解答

2023-06-05 19:09:10 互联网 未知 开发

 mongoDB适用什么场合呢 mongodb应用场景,举例说明。。谢谢高手解答

mongoDB适用什么场合呢?

根据官方网站的描述,Mongo适合用于以下场景:
◆网站数据:Mongo非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
◆缓存:由于性能很高,Mongo也适合作为信息基础设施的缓存层。在系统重启之后,由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
◆大尺寸,低价值的数据:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
◆高伸缩性的场景:Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
◆用于对象及JSON数据的存储:Mongo的BSON数据格式非常适合文档化格式的存储及查询。
自然,MongoDB的使用也会有一些限制,例如它不适合:
◆高度事务性的系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
◆传统的商业智能应用:针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用,数据仓库可能是更合适的选择。

mongodb应用场景,举例说明。。谢谢高手解答

MongoDB属于内存型数据库,在需要读性能要求很高的项目中有着比较不错的表现。

可做前段缓存服务器、缓冲数据存储区,同样也可以作为应用系统的存储服务器,例如微博、论坛等应用系统,也可以作为图片存储服务器(分布式);

在数据写方面,Mongo也支持比较高的写速率(当然这取决于硬件设备)。这比一般使用硬盘存储介质的关系数据库的存储效率要高很多。

但是,非关系数据库会造成大量冗余数据,如果前期的系统设计很粗糙,后期的数据维护将会相当困难。

mongodb mysql 分别适合什么场景

MongoDB已经流行了很长一段时间,相对于MySQL,究竟什么场景更需要用MongoDB?下面是一些总结。
更高的写入负载
默认情况下,MongoDB更侧重高数据写入性能,而非事务安全,MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB,除非能从架构设计上保证事务安全。
高可用性
MongoDB的复副集(Master-Slave)配置非常简洁方便,此外,MongoDB可以快速响应的处理单节点故障,自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定(如云主机)的环境中,保持高可用性。
数据量很大或者未来会变得很大
依赖数据库(MySQL)自身的特性,完成数据的扩展是较困难的事,在MySQL中,当一个单达表到5-10GB时会出现明显的性能降级,此时需要通过数据的水平和垂直拆分、库的拆分完成扩展,使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性,可以很好的适应大数据量的需求。
基于位置的数据查询
MongoDB支持二维空间索引,因此可以快速及精确的从指定位置获取数据。
表结构不明确,且数据在不断变大
在一些传统RDBMS中,增加一个字段会锁住整个数据库/表,或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候(当大于1TB时更甚)。 因MongoDB是文档型数据库,为非结构货的文档增加一个新字段是很快速的操作,并且不会影响到已有数据。另外一个好处当业务数据发生变化时,是将不在需要由DBA修改表结构。
没有DBA支持
如果没有专职的DBA,并且准备不使用标准的关系型思想(结构化、连接等)来处理数据,那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便,类可以直接序列化成JSON存储到MongoDB中。 但是需要先了解一些最佳实践,避免当数据变大后,由于文档设计问题而造成的性能缺陷。
BillRun – 基于MongoDB的帐单系统 (来自oc666)
BillRun是由Ofer Cohen推出开源账单系统,采用MongoDB做为数据存储。这套账单系统被以色列一家增速最快的电信运营商采用,每月处理5亿条通信记录,Ofer在Slideshare上说明了具体利到了MongoDB的哪些特性:
弱数据结构的特点,使得BillRun能很快的支持新的CDR(通讯记录)类型。这个特性使文档型数据库很适用于快速发展、业务需求不确定的系统中。
BillRun仅使用了一个Collection,已经管理了数TB的文档数据,并且没有遇到由结构变更、数据爆发式增长的带来的限制和问题。
replicaSet副本集特性使建立更多的数据中心DRP变得更轻松。
内建的Sharding分片特性避免系统在数据增长的过程中遇到性能瓶颈。
每秒钟2000条通信记录的插入,MongoDB在架构设计上很好的支持了高负载的数据写入。并且可以使用findAndModify(相对缓慢)完成基础的事务特性,并且通过应用层面的支持,实现双段式提交。
查询方式相比SQL,更加易读、易懂,开发相对轻松。
基于位置允许更好的分析用户使用情况,从而更好地制定移动电话基础设施的投入点。

mysql mongodb 什么时候使用

弱数据结构模式允许系统快速引入新的CDR类型,BillRun负责托管所有的数据。
  BillRun系统已经管理了TB级的表格,I/O性能受限于新字段的增加及数据体积的增长。
  快速副本集允许更简单地设置多数据中心DRP和HA方案。
  分片允许I/O超预算时的线性横向扩展。
  在CDR插入达到2000个每秒时,MongoDB非常适用于高写入系统。同时,你完全可以使用findAndModify(会影响性能)以及2阶段提交(应用程序级别)来解决事务问题。
  面向开发者的查询允许优雅查询的编写。
  基于位置允许更好的分析用户使用情况,从而更好地制定移动电话基础设施的投入点。
  总结
  MongoDB是个非常不错的工具,但是只有在适合的场景下才能爆发出压倒性优势,BillRun就是一个不错的用例。