MongoDB学习记录：入门（一）——五叶草

2017-08-28 3941

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

云原生数据库 PolarDB MySQL 版，Serverless 5000PCU 100GB

云数据库 MongoDB，通用型 2核4GB

简介： 预热看我之前的文章Node学习记录: mongodb 这个系列旨在系统的学习Mongodb 部分图片来自慕课网mongodb入门截图学习目标 MongoDB官网：https://www.mongodb.com/ MongoDB中文社区：http://www.mongoing.com/ mongodb github:https://github.com/mongodb 关系型数据库与非关系型数据库 MongoDB是一个面向文档(document-oriented)的数据库,而不是关系型数据库。

预热看我之前的文章Node学习记录: mongodb

这个系列旨在系统的学习Mongodb

部分图片来自慕课网mongodb入门截图

学习目标

图片描述

MongoDB官网：https://www.mongodb.com/
MongoDB中文社区：http://www.mongoing.com/
mongodb github:https://github.com/mongodb

关系型数据库与非关系型数据库

MongoDB是一个面向文档(document-oriented)的数据库,而不是关系型数据库。不采用关
系模型主要是为了获得更好的扩展性。当然, 还有其他一些好处。

图片描述

与关系型数据库相比,面向文档的数据库不再有行(row)的概念,取而代之的是更为灵活的文档(document)模型。通过在文档中嵌入文档和数组,面向文档的方法能够仅使用一条记录来表现复杂的层次关系,这与使用现代面向对象语言的开发者对数据的看法一致。

另外,不再有预定义模式(predefined schema):文档的键(key)和值(value)不再是固定的类型和大小。由于没有固定的模式,根据需要添加或删除字段变得更容易了。通常,由于开发者能够进行快速迭代,所以开发进程得得以加快。而且,实验更容易进行。开发者能尝试大量的数据模型,从中选择一个最好的。

MongoDB并不具备一些在关系型数据库中很普遍的功能,如连接(join)和复杂的多行事务(multirow transaction)。省略这些功能是出于架构上的考虑(为了得到更好的扩展性),因为在分布式系统中这两个功能难以高效地实现。

基础概念

文档是MongoDB中数据的基本单元，非常类似于关系型数据库管理系统中的行，但更具表现力
集合（collection）可以看作是一个拥有动态模式（dynamic schema）的表
MongoDB的一个实例可以拥有多个互相独立的数据库(database)，每个数据库都拥有自己的集合
每个文档都有一个特殊的键"_id",这个键在文档所属的集合中唯一的。
MongoDB自带一个简单但功能强大的JavaScript shell可用于管理MongDB的实例或数据操作

文档

文档就是键值对的一个有序集

{"x" : 1, "y":2}与{"y": 2, "x": 1}是不同的

通常,字段顺序并不重要,无须让数据库模式依赖特定的字段顺序(MongoDB会对字段重新排序)。

在某些特殊情况下,字段顺序变得非常重要

一些编程语言对文档的默认表示根本就不包含顺序问题(如:Python中的字典、Perl和Ruby
 1.8中的散列)。通常,这些语言的驱动具有某些特殊的机制,可以在必要时指定文档的顺序。

MongoDB不但区分类型,而且区分大小写

下面的两个文档是不同的

{"foo" : 3}
{"foo" : "3"}

下面两个文档也是不同的

{"foo" : 3}
{"Foo" : 3}

MongoDB的文档不能有重复的键

下面的文档是非法的:

{"greeting" : "Hello, world!", "greeting" : "Hello, MongoDB!"}

集合

集合就是一组文档。

如果将MongoDB中的一个文档比喻为关系型数据库中的一行,那么一个集合就相当于一张表。

动态模式

一个集合里面的文档可以是各式各样的，这意味着，下面两个文档可以存储在同一个集合里面:

{"greeting" : "Hello, world!"}
{"foo" : 5}

————> 这里引发一个问题：

因为集合里面可以放置任何文档，还有必要使用多个集合吗?（既然没有必要区分不同类型文档的模式,为什么还要使用多个集合呢）

如果把各种各样的文档不加区分地放在同一个集合里,无论对开发者还是对管理员来
说都将是噩梦。开发者要么确保每次查询只返回特定类型的文档,要么让执行查询的应用程序来处理所有不同类型的文档。如果查询博客文章时还要剔除含有作者数据的文档,这会带来很大困扰。

在一个集合里查询特定类型的文档在速度上也很不划算,分开查询多个集合要快得多。例如,假设集合里面一个名为"type"的字段用于指明文档是skim、whole还是 chunky monkey。那么,如果从一个集合中查询这三种类型的文档,速度会很慢。但如果将这三种不同类型的文档拆分为三个不同的集合,每次只需要查询相应的集合,速度快得多。

把同种类型的文档放在一个集合里,数据会更加集中。从一个只包含博客文章的集合里查询几篇文章,或者从同时含文章数据和作者数据的集合里查出几篇文章,相比之下,前者需要的磁盘寻道操作更少。创建索引时,需要使用文档的附加结构(特别是创建唯一索引时)。索引是按照集合来定义的。在一个集合中只放入一种类型的文档,可以更有效地对集合进行索引。

上面这些重要原因促使我们创建一个模式,把相关类型的文档组织在一起,尽管MongoDB对此并没有强制要求。

数据库

在MongoDB中,多个文档组成集合,而多个集合可以组成数据库。一个MongoDB实例可以承载多个数据库,每个数据库拥有0个或者多个集合。每个数据库都有独立的权限,即便是在磁盘上,不同的数据库也放置在不同的文件中。按照经验,我们将有关一个应用程序的所有数据都存储在同一个数据库中。要想在同一个MongoDB服务器上存放多个应用程序或者用户的数据,就需要使用不同的数据库。

安装

Linux平台安装MongoDB

或者

在 Ubuntu 16.04 上安装 MongoDB 可参考 MongoDB Docs：

$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6
$ echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
$ sudo apt-get update
$ sudo apt-get install -y mongodb-org

在 CentOS 7 上安装 MongoDB 可参考 MongoDB Docs：

$ sudo vi /etc/yum.repos.d/mongodb-org-3.4.repo
[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc
$ sudo yum install -y mongodb-org

图片描述