MongoDB系列--01、MongoDB入门
MongoDB理论基础
介绍
MongoDB官网:https://www.mongodb.com/
MongoDB 是一个基于【分布式文件存储】的数据库,它属于NoSQL数据库。是最像关系型数据库的一个NoSQL数据库
MongoDB存储数据是key-value结构的BSON(二进制json)文档
概念
SQL术语/概念 | MongoDB术语/概念 | 解释/说明 |
---|---|---|
database | database | 数据库 |
table | collection | 数据库表/集合 |
row | document | 数据记录行/文档 |
column | field | 数据字段/域 |
index | index | 索引 |
table joins | 表连接,MongoDB不支持 | |
primary key | primary key | 主键,MongoDB自动将_id字段设置为主键 |
通过下图实例,我们也可以更直观的了解Mongo中的一些概念:
数据库(database)
一个mongodb中可以建立多个数据库。
MongoDB的默认数据库为db
,该数据库存储在data目录中(安装时,可以默认或指定)。
MongoDB的单个实例可以容纳多个独立的数据库,每一个都有自己的集合和权限,不同的数据库也放置在不同的文件中。
数据库命名规范
- 不能是空字符串("")
- 不得含有’ '(空格)、.、$、/、\和\0 (空字符)
- 应全部小写
- 最多64字节
集合(collection)
集合就是 MongoDB 文档组,类似于关系数据库中的表格。
集合存在于数据库中,没有固定的机构;比如我们可以向集合中插入不同数据结构的文档
{"name":"christy"}
{"name":"christy","age":"18"}
{"name":"christy","age":"18","desc":"shuai"}
一旦有文档插入,集合就会被创建
一个collection(集合)中的所有field(域)是collection(集合)中所有document(文档)中包含的field(域)的并集
集合命名规范
-
集合名不能是空字符串""
-
集合名不能含有\0字符(空字符),这个字符表示集合名的结尾
-
集合名不能以"system."开头,这是为系统集合保留的前缀
-
用户创建的集合名字不能含有保留字符。有些驱动程序的确支持在集合名里面包含,这是因为某些系统生成的集合中包含该字符。除非你要访问这种系统创建的集合,否则千万不要在名字里出现$
capped collections
Capped collections就是固定大小的collection。与标准的collection不同,你必须要显式的创建一个capped collection,指定一个 collection 的大小,单位是字节。它的存储空间值是提前分配的。
创建一个capped collection
db.createCollection("mycollection",{capped:true, szie:99999})
- 在 capped collection 中,你能添加新的对象
- 能进行更新,然而,对象不会增加存储空间。如果增加,更新就会失败
- 使用 Capped Collection 不能删除一个文档,但可以使用 drop() 方法删除 collection 所有的行。
删除之后,你必须显式的重新创建这个 collection - 在32bit机器中,capped collection 最大存储为 1e9( 1X10的9次方)个字节。
文档(document)
文档是一组键值(key-value)对(即 BSON)。MongoDB 的文档不需要设置相同的字段,并且相同的字段并不需要相同的数据类型。
对于文档,需要注意
- 文档中的键/值对是有序的
- 文档中的值不仅可以是在双引号里面的字符串,还可以是其他几种数据类型(甚至可以是整个嵌入的文档)。
- MongoDB区分类型和大小写
- MongoDB的文档不能有重复的键
- 文档的键是字符串。除了少数例外情况,键可以使用任意UTF-8字符
文档键命名规范
- 键不能含有\0 (空字符)。这个字符用来表示键的结尾
- .和$有特别的意义,只有在特定环境下才能使用
- 以下划线"_"开头的键是保留的(不是严格要求的)
元数据
MongoDB数据库中名字空间 .system.* 是包含多种系统信息的特殊集合(Collection)
集合命名空间 | 描述 |
---|---|
dbname.system.namespaces | 列出所有名字空间 |
dbname.system.indexes | 列出所有索引 |
dbname.system.profile | 列出数据库概要(profile)信息 |
dbname.system.users | 列出所有可访问数据库的用户 |
dbname.system.sources | 包含复制对端(slave)的服务器信息和状态 |
对于修改系统集合中的对象有如下限制
- 在{{system.indexes}}插入数据,可以创建索引。但除此之外该表信息是不可变的(特殊的drop index命令将自动更新相关信息)
- {{system.users}}是可修改的
- {{system.profile}}是可删除的
数据类型
MongoDB中常用的数据类型
数据类型 | 说明 | 解释 | 举例 |
---|---|---|---|
String | 字符串 | UTF-8编码的字符串才是合法的 | {“name”:“Christy”} |
Integer | 整型数值 | 随服务器不同(32|64位) | {“age”:18} |
Boolean | 布尔值 | 存储布尔值:真|假 | {“falg”:true} |
Double | 浮点数 | 存储浮点值 | {“π”:3.14} |
ObjectId | 对象Id | 生成文档的id | {“_id”:ObjectId(“123456”)} |
Array | 数组 | 将数组|列表|多个值存储到一个键 | {“value”:[“1”,“2”]} |
Timestamp | 时间戳 | 从纪元开始的毫秒数 | |
Object | 内嵌文档 | 可以作为文档中某个key的value | {“doc”:{“name”:“Christy”}} |
Null | 空值 | 表示空值或者未定义的对象 | {“value”:null} |
Date | 日期 | 用Unix日期格式来存储当前日期或时间 | {“date”:new Date()} |
Regular | 正则表达式 | 文档中的正则表达式遵循js语法 | |
Code | 代码 | 可以包含js代码 | {“js”:function(){}} |
File | 文件 | 二进制转码(Base64)后存储(<16M) GridFS(>16M) | GridFS 用两个集合来存储一个文件:fs.files与fs.chunks |
下面说明下几种重要的数据类型。
ObjectId
ObjectId 类似唯一主键,可以很快的去生成和排序,包含 12 bytes,含义是:
- 前 4 个字节表示创建 unix 时间戳,格林尼治时间 UTC 时间,比北京时间晚了 8 个小时
- 接下来的 3 个字节是机器标识码
- 紧接的两个字节由进程 id 组成 PID
- 最后三个字节是随机数
MongoDB 中存储的文档必须有一个 _id 键。这个键的值可以是任何类型的,默认是个 ObjectId 对象
由于 ObjectId 中保存了创建的时间戳,所以你不需要为你的文档保存时间戳字段,你可以通过 getTimestamp 函数来获取文档的创建时间:
> var newObject = ObjectId()
> newObject.getTimestamp()
ISODate("2017-11-25T07:21:10Z")
ObjectId 转为字符串
> newObject.str
5a1919e63df83ce79df8b38f
字符串
BSON 字符串都是 UTF-8 编码。
时间戳
BSON 有一个特殊的时间戳类型用于 MongoDB 内部使用,与普通的 日期 类型不相关。 时间戳值是一个 64 位的值。其中:
- 前32位是一个 time_t 值(与Unix新纪元相差的秒数)
- 后32位是在某秒中操作的一个递增的
序数
在单个 mongod 实例中,时间戳值通常是唯一的。
在复制集中, oplog 有一个 ts 字段。这个字段中的值使用BSON时间戳表示了操作时间。
BSON 时间戳类型主要用于 MongoDB 内部使用。在大多数情况下的应用开发中,你可以使用 BSON 日期类型。
日期
表示当前距离 Unix新纪元(1970年1月1日)的毫秒数。日期类型是有符号的, 负数表示 1970 年之前的日期。
> var mydate1 = new Date() //格林尼治时间
> mydate1
ISODate("2018-03-04T14:58:51.233Z")
> typeof mydate1
object
> var mydate2 = ISODate() //格林尼治时间
> mydate2
ISODate("2018-03-04T15:00:45.479Z")
> typeof mydate2
object
这样创建的时间是日期类型,可以使用 JS 中的 Date 类型的方法。
返回一个时间类型的字符串:
> var mydate1str = mydate1.toString()
> mydate1str
Sun Mar 04 2018 14:58:51 GMT+0000 (UTC)
> typeof mydate1str
string
或者
> Date()
Sun Mar 04 2018 15:02:59 GMT+0000 (UTC)
MongoDB的应用场景
适用场景
更高的写入负载
默认情况下,MongoDB更侧重高数据写入性能,而非事务安全,MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB,除非能从架构设计上保证事务安全
高可用性
MongoDB的副本集(Master-Slave)配置非常简洁方便,此外,MongoDB可以快速响应的处理单节点故障,自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定(如云主机)的环境中,保持高可用性
数据量很大或者未来会变得很大
依赖数据库(MySQL)自身的特性,完成数据的扩展是较困难的事,在MySQL中,当一个单表达到5-10GB时会出现明显的性能降级,此时需要通过数据的水平和垂直拆分、库的拆分完成扩展,使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性,可以很好的适应大数据量的需求
基于位置的数据查询
MongoDB支持二维空间索引,因此可以快速及精确的从指定位置获取数据
表结构不明确,且数据在不断变大
在一些传统关系型数据库中,增加一个字段会锁住整个数据库/表,或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候(当大于1TB时更甚)。 但MongoDB是文档型数据库,为非结构货的文档增加一个新字段是很快速的操作,并且不会影响到已有数据。另外一个好处当业务数据发生变化时,是将不在需要由DBA修改表结构
没有DBA支持
如果没有专职的DBA,并且准备不使用标准的关系型思想(结构化、连接等)来处理数据,那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便,类可以直接序列化成JSON存储到MongoDB中。 但是需要先了解一些最佳实践,避免当数据变大后,由于文档设计问题而造成的性能缺陷
不适用场景
在某些场景下,MongoDB作为一个非关系型数据库有其局限性。MongoDB不支持事务操作,所以需要用到事务的应用建议不用MongoDB,另外MongoDB目前不支持join操作,需要复杂查询的应用也不建议使用MongoDB