Mongodb基础-特点
知道node的确不知道mongodb的,估计有点少。有人说mongodb就是为node量身定做的,话应该是假的(时间上不对),但道理还是有的,这两个真的算是珠联璧合了。
个人感觉
为什么使用mongodb?个人理由很简单,就是因为它简单,简单,简单。
有人会说,那是你用的不够深。确实,事实上一个人确实不用深入,需要深入的那是团队的事情。就说简单的使用吧,mongodb就凭不需要定义“表字段”这一点就完爆其他的关系型数据库了。
说说mongo的结构,第一层database,这个不用说都一样。database下面是所谓的collection。有人说它对应着其他数据库的table,其实就我的感觉,这两个真的差距有点大。collection让人的感觉的作用仅仅是“归类”,而且还是“非强制性”的“归类”,简单的说就是东西在我里面,里面是什么我不管,也管不了。所以说一个collection就足够存储所有数据了。而collection下面就是document,因为collection不管理document,所以document之间没有任何实际的关系,连先后顺序都没有。document里面就是field,也就是键值对。这就是mongodb的上下结构,灵活到基本没约束,想怎么来就怎么来。
MongoDB的特点
列表
| MongoDB 特性 | 优势 |
|---|---|
| 事务支持 | MongoDB 目前只支持单文档事务,需要复杂事务支持的场景暂时不适合 |
| 灵活的文档模型 | JSON 格式存储最接近真实对象模型,对开发者友好,方便快速开发迭代 |
| 高可用复制集 | 满足数据高可靠、服务高可用的需求,运维简单,故障自动切换 |
| 可扩展分片集群 | 海量数据存储,服务能力水平扩展 |
| 高性能 | mmapv1、wiredtiger、mongorocks(rocksdb)、in-memory 等多引擎支持满足各种场景需求 |
| 强大的索引支持 | 地理位置索引可用于构建 各种 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过期的需求 |
| Gridfs | 解决文件存储的需求 |
| aggregation & mapreduce | 解决数据分析场景需求,用户可以自己写查询语句或脚本,将请求都分发到 MongoDB 上完成 |
适合场景
从目前阿里云 MongoDB 云数据库上的用户看,MongoDB 的应用已经渗透到各个领域,比如游戏、物流、电商、内容管理、社交、物联网、视频直播等,以下是几个实际的应用案例。
- 游戏场景,使用 MongoDB 存储游戏用户信息,用户的装备、积分等直接以内嵌文档的形式存储,方便查询、更新
- 物流场景,使用 MongoDB 存储订单信息,订单状态在运送过程中会不断更新,以 MongoDB 内嵌数组的形式来存储,一次查询就能将订单所有的变更读取出来。
- 社交场景,使用 MongoDB 存储存储用户信息,以及用户发表的朋友圈信息,通过地理位置索引实现附近的人、地点等功能
- 物联网场景,使用 MongoDB 存储所有接入的智能设备信息,以及设备汇报的日志信息,并对这些信息进行多维度的分析
- 视频直播,使用 MongoDB 存储用户信息、礼物信息等
- ……
如何选择
如果你还在为是否应该使用 MongoDB,不如来做几个选择题来辅助决策(注:以下内容改编自 MongoDB 公司 TJ 同学的某次公开技术分享)。
| 应用特征 | Yes / No |
|---|---|
| 应用不需要事务及复杂 join 支持 | 必须 Yes |
| 新应用,需求会变,数据模型无法确定,想快速迭代开发 | ? |
| 应用需要2000-3000以上的读写QPS(更高也可以) | ? |
| 应用需要TB甚至 PB 级别数据存储 | ? |
| 应用发展迅速,需要能快速水平扩展 | ? |
| 应用要求存储的数据不丢失 | ? |
| 应用需要99.999%高可用 | ? |
| 应用需要大量的地理位置查询、文本查询 | ? |
如果上述有1个 Yes,可以考虑 MongoDB,2个及以上的 Yes,选择MongoDB绝不会后悔。
总结
总的来说,mongodb不适合作为初学者的入门选择,但非常适合个人项目的使用。至于深入使用,主要还是看应用场景。
原文作者: hxkuan