Mongodb的实践二初识

Mongodb 系列教程

1. Mongodb 的实践一：安装
2. Mongodb 的实践二：初识
3. Mongodb 的实践三：
4. Mongodb 的实践四：
5. Mongodb 的实践五：
6. Mongodb 的实践六：
7. Mongodb 的实践七：
8. Mongodb 的实践八：

术语

db-> 数据库
collection-> 集合
document-> 文档
index-> 索引
cluster-> 集群
shard-> 分片

数据类型

MongoDB 文档存储是使用 BSON 类型
类型的官方文档：https://docs.mongodb.com/manu…
BSON 官网:http://bsonspec.org/

常用数据类型

后续实例说明

内建的角色组

https://docs.mongodb.com/manu…

1. Database User Roles 这个是针对非系统数据库和部分系统表的角色组
2. Database Administration Roles 可以操作所有数据库
3. Cluster Administration Roles 管理员族 针对整个系统进行管理
4. Backup and Restoration Roles 备份还原角色组
5. All-Database Roles 角色里面有一些跟超管差不多了级别了，针对所有数据库的
6. Superuser Roles 超级管理员 不用多说了
7. Internal Role 内部系统角色

MongoDB 通过角色基本权限控制授予（用户）数据和命令的使用权，并且提供给内置角色数据系统一般需要的不同层次的权限。另外，你也可以创建用户定义角色。

角色授予对定义的资源执行一组操作的权限。给定的角色应用于定义它的数据库，并且可以授予对粒度集合级别的访问权限

MongoDB 的每个内置角色在数据库级别为角色数据库中的所有非系统集合定义访问权限，在收集级别为所有系统集合定义访问权限
MongoDB 在每个数据库上提供内置的数据库用户和数据库管理角色。MongoDB 仅在管理数据库上提供所有其他内置角色。

本节描述每个内置角色的权限。您还可以随时查看内置角色的权限，方法是发出 rolesinfo 命令，并将 showprivileges 和 showbuiltinroles 字段都设置为 true。

Database User Roles (数据库用户角色)

每个数据库都包含以下客户角色：

read(只读)

提供读取所有非系统集合和以下系统集合上的数据的能力：system.indexes, system.js, and system.namespaces集合

角色通过授予以下操作提供读取访问权限

• changeStream
• collStats
• dbHash
• dbStats
• find
• killCursors
• listIndexes
• listCollections

readWrite(读和写)

提供读取角色的所有特权，以及修改所有非系统集合和 system.js 集合上的数据的能力

该角色对这些集合提供以下操作：：

• collStats
• convertToCapped
• createCollection
• dbHash
• dbStats
• dropCollection
• createIndex
• dropIndex
• find
• insert
• killCursors
• listIndexes
• listCollections
• remove
• renameCollectionSameDB
• update

Database Administration Roles (数据库管理角色)

每个数据库都包含以下管理角色：

dbAdmin (数据库管理员)

提供执行管理任务（如与架构相关的任务、索引和收集统计信息）的能力。此角色不授予用户和角色管理权限。

在数据库的 system.indexes、system.namespaces 和system.profile集合上提供以下操作：

• collStats
• dbHash
• dbStats
• find
• killCursors
• listIndexes
• listCollections
• dropCollection and createCollection on system.profile only

在版本 2.6.4 中进行了更改：dbAdmin为 system.profile 集合添加了 createCollection 操作。以前的版本对 system.profile 集合只有 dropCollection 操作。

对所有非系统集合提供以下操作。此角色不包括对非系统集合的完全读取权限：

• bypassDocumentValidation
• collMod
• collStats
• compact
• convertToCapped
• createCollection
• createIndex
• dbStats
• dropCollection
• dropDatabase
• dropIndex
• enableProfiler
• reIndex
• renameCollectionSameDB
• repairDatabase
• storageDetails
• validate

dbOwner (数据库所有者)

数据库所有者可以对数据库执行任何管理操作。此角色组合了 readWrite、dbAdmin 和userAdmin角色授予的权限。

userAdmin (用户管理员)

提供在当前数据库上创建和修改角色和用户的功能。由于 userAdmin 角色允许用户向任何用户（包括用户本身）授予任何权限，因此该角色还间接提供 superuser 对数据库或集群（如果其作用域是管理数据库）的访问。

userAdmin角色显式提供以下操作：

• changeCustomData
• changePassword
• createRole
• createUser
• dropRole
• dropUser
• grantRole
• revokeRole
• setAuthenticationRestriction
• viewRole
• viewUser

理解授予 userAdmin 角色的安全含义是很重要的：对于数据库具有此角色的用户可以为自己分配该数据库上的任何特权。在 admin 数据库上授予 userAdmin 角色有进一步的安全隐患，因为这间接地提供了 superuser 对集群的访问。在 admin 范围内，具有 userAdmin 角色的用户可以授予集群范围内的角色或权限，包括userAdminAnyDatabase。

Cluster Administration Roles

The admin database includes the following roles for administering the whole system rather than just a single database. These roles include but are not limited to replica set and sharded cluster administrative functions.

clusterAdmin

Provides the greatest cluster-management access. This role combines the privileges granted by the clusterManager, clusterMonitor, and hostManager roles. Additionally, the role provides the dropDatabase action.

clusterManager

Changed in version 3.4.

Provides management and monitoring actions on the cluster. A user with this role can access the config and local databases, which are used in sharding and replication, respectively.

Provides the following actions on the cluster as a whole:

addShard
appendOplogNote
applicationMessage
cleanupOrphaned
flushRouterConfig
listSessions (New in version 3.6)
listShards
removeShard
replSetConfigure
replSetGetConfig
replSetGetStatus
replSetStateChange
resync
Provides the following actions on all databases in the cluster:

enableSharding
moveChunk
splitChunk
splitVector
On the config database, provides the following privileges:

Resource Actions
All collections in the config database
collStats
dbHash
dbStats
enableSharding
find
insert
killCursors
listCollections
listIndexes
moveChunk
planCacheRead
remove
splitChunk
splitVector
update
system.indexes,
system.js,
system.namespaces collections
collStats
dbHash
dbStats
find
killCursors
listCollections
listIndexes
planCacheRead
On the local database, provides the following privileges:

Resource Actions
All collections in the local database
enableSharding
insert
moveChunk
remove
splitChunk
splitVector
update
system.replset collection
collStats
dbHash
dbStats
find
killCursors
listCollections
listIndexes
planCacheRead

clusterMonitor

Changed in version 3.4.

Provides read-only access to monitoring tools, such as the MongoDB Cloud Manager and Ops Manager monitoring agent.

Provides the following actions on the cluster as a whole:

checkFreeMonitoringStatus (New in version 4.0)
connPoolStats
getCmdLineOpts
getLog
getParameter
getShardMap
hostInfo
inprog
listDatabases
listSessions (New in version 3.6)
listShards
netstat
replSetGetConfig
replSetGetStatus
serverStatus
setFreeMonitoring (New in version 4.0)
shardingState
top
Provides the following actions on all databases in the cluster:

collStats
dbStats
getShardVersion
indexStats
useUUID (New in version 3.6)
Provides the find action on all system.profile collections in the cluster.

On the config database, provides the following privileges:

Resource Actions
All collections in the config database
collStats
dbHash
dbStats
find
getShardVersion
indexStats
killCursors
listCollections
listIndexes
planCacheRead
system.indexes,
system.js,
system.namespaces collections
collStats
dbHash
dbStats
find
killCursors
listCollections
listIndexes
planCacheRead
On the local database, provides the following privileges:

Resource Actions
All collections in the local database
collStats
dbHash
dbStats
find
getShardVersion
indexStats
killCursors
listCollections
listIndexes
planCacheRead
system.indexes,
system.js,
system.namespaces collections
collStats
dbHash
dbStats
find
killCursors
listCollections
listIndexes
planCacheRead
system.replset,
system.profile,
find

hostManager

Provides the ability to monitor and manage servers.

Provides the following actions on the cluster as a whole:

applicationMessage
closeAllDatabases
connPoolSync
cpuProfiler
flushRouterConfig
fsync
invalidateUserCache
killAnyCursor (New in version 4.0)
killAnySession (New in version 3.6)
killop
logRotate
resync
setParameter
shutdown
touch
unlock
Provides the following actions on all databases in the cluster:

killCursors
repairDatabase

Backup and Restoration Roles

The admin database includes the following roles for backing up and restoring data:

backup

Changed in version 3.4.

Provides minimal privileges needed for backing up data. This role provides sufficient privileges to use the MongoDB Cloud Manager backup agent, Ops Manager backup agent, or to use mongodump to back up an entire mongod instance.

Provides the insert and update actions on the mms.backup collection in the admin database and on the settings collection in the config database.

On anyResource, provides the

listDatabases action
listCollections action
listIndexes action
On the cluster as a whole, provides the

appendOplogNote
getParameter
listDatabases
Provides the find action on the following:

all non-system collections in the cluster, including those in the config and local databases
The following system collections in the cluster: system.indexes, system.namespaces, system.js, and system.profile
the admin.system.users and admin.system.roles collections
the config.settings collection
legacy system.users collections from versions of MongoDB prior to 2.6
Provides the insert and update actions on the config.settings collection.

Changed in version 3.2.1: The backup role provides additional privileges to back up the system.profile collection that exists when running with database profiling. Previously, users required read access on this collection.

restore

Changed in version 3.6: Provides convertToCapped on non-system collections.

Provides privileges needed to restore data from backups that do not include system.profile collection data. This role is sufficient when restoring data with mongorestore without the –oplogReplay option.

If the backup data includes system.profile collection data and the target database does not contain the system.profile collection, mongorestore attempts to create the collection even though the program does not actually restore system.profile documents. As such, the user requires additional privileges to perform createCollection and convertToCapped actions on the system.profile collection for a database.

The built-in roles dbAdmin and dbAdminAnyDatabase provide the additional privileges.

If running mongorestore with –oplogReplay, the restore role is insufficient to replay the oplog. To replay the oplog, create a user-defined role that has anyAction on anyResource and grant only to users who must run mongorestore with –oplogReplay.

Provides the following action on the cluster as a whole:

getParameter
Provides the following actions on all non-system collections:

bypassDocumentValidation
changeCustomData
changePassword
collMod
convertToCapped
createCollection
createIndex
createRole
createUser
dropCollection
dropRole
dropUser
grantRole
insert
revokeRole
viewRole
viewUser
Provides the following actions on system.js collection:

bypassDocumentValidation
collMod
createCollection
createIndex
dropCollection
insert
Provides the following action on anyResource:

listCollections
Provides the find action on all the system.namespaces collections in the cluster.

Provides the following actions on all non-system collections on the config and the local databases:

bypassDocumentValidation
collMod
createCollection
createIndex
dropCollection
insert
Provides the following actions on admin.system.version

bypassDocumentValidation
collMod
createCollection
createIndex
dropCollection
find
insert
Provides the following action on admin.system.roles

createIndex
Provides the following actions on admin.system.users and legacy system.users collections:

bypassDocumentValidation
collMod
createCollection
createIndex
dropCollection
find
insert
remove
update
Although, restore includes the ability to modify the documents in the admin.system.users collection using normal modification operations, only modify these data using the user management methods.

All-Database Roles (所有数据库角色)

以下角色在管理数据库上可用，并提供适用于除本地和配置之外的所有数据库的权限：

readAnyDatabase (读取任意数据库)

提供与在除本地和配置之外的所有数据库上读取相同的 read 权限。该角色还提供了集群上的 listDatabases 操作。

在 3.4 版本中进行了更改：在 3.4 之前，readAnyDatabase 包括 local 和config数据库。要在 local 数据库上提供 read 权限，请在 admin 数据库中创建一个在 local 数据库中具有 read 角色的用户。

另请参阅 clusterManager 和clusterMonitor角色以访问配置和本地数据库。

readWriteAnyDatabase (读写任意数据库)

在除 local 和config之外的所有数据库上提供与 readWrite 相同的读写权限。该角色还提供了集群上的 listDatabases 操作。

在 3.4 版本中进行了更改：在 3.4 之前，readWriteAnyDatabase包括 local 和config数据库。要在 local 数据库上提供 readWrite 权限，请在 admin 数据库中创建一个在 local 数据库中具有 readWrite 角色的用户。

另请参阅 clusterManager 和clusterMonitor角色以访问 local 和config数据库

userAdminAnyDatabase (用户管理数据库)

在除 local 和config之外的所有数据库上，提供与 userAdmin 相同的用户管理操作访问权限。

UserAdminAnyDatabase还提供群集上的以下权限操作:

• authSchemaUpgrade
• invalidateUserCache
• listDatabases

该角色还提供以下权限操作：admin数据库上的 system.users 和system.roles集合，以及 2.6 之前版本的 mongodb 中的 legacy system.users集合：

• collStats
• dbHash
• dbStats
• find
• killCursors
• planCacheRead

在版本 2.6.4 中进行了更改：userAdminAnyDatabase在 admin.system.users 和admin.system.roles集合中添加了以下权限操作：

• createIndex
• dropIndex

userAdminAnyDatabase角色不限制用户可以授予的权限。因此，userAdminAnyDatabase用户可以授予自己超过当前权限的权限，甚至可以授予自己所有权限，即使角色没有明确授权超出用户管理范围的权限。此角色实际上是 MongoDB 系统superuser。

在版本 3.4 中更改：UserAdminAnyDatabase不再适用于 local 和config数据库。

另请参阅 clusterManager 和clusterMonitor角色以访问 local 和config数据库。

dbAdminAnyDatabase

在除 local 和config之外的所有数据库上提供与 dbAdmin 相同的权限。该角色还提供了集群上的 listDatabases 操作。

在 3.4 版中进行了更改：在 3.4 版之前，dbAdminAnyDatabase 包括 local 和config数据库。要在 local 数据库上提供 dbAdmin 特权，请在 local 数据库中创建具有 dbAdmin 角色的 admin 数据库中的用户。

另请参阅 clusterManager 和clusterMonitor角色以访问 local 和config数据库。

Superuser Roles (超级用户角色)

多个角色提供间接或直接的系统范围超级用户访问。

以下角色提供了在任何数据库上为任何用户分配任何权限的能力，这意味着具有这些角色之一的用户可以在任何数据库上为自己分配任何权限：

以下角色对所有资源提供完全权限：
dbowner 角色，当作用域为管理数据库时
当作用域为 admin 数据库时，userAdmin角色
userAdminAnyDatabase 角色

以下角色对所有资源提供完全权限：

root

提供对 readwriteanydatabase、dbadminnanydatabase、useradminanydatabase、clusteradmin、restore 和backup的操作和所有资源的访问。

在版本 3.4 中更改：root角色包括来自 backup 角色的权限。

在版本 3.0.7 中更改：root在 system 上具有 validate 权限操作。收藏。以前，root不包括对以系统开始的集合的任何访问。前缀不是 system.indexes 和system.namespaces。

根角色包括还原角色的权限。的操作和所有资源的访问。

Internal Role (内部角色)

__system

MongoDB 将此角色分配给表示集群成员的用户对象，例如复制集成员和 mongos 实例。该角色使其持有者有权对数据库中的任何对象采取任何操作。

除特殊情况外，不要将此角色分配给表示应用程序或人员管理员的用户对象。

如果需要访问所有资源上的所有操作，例如运行 applyops 命令，请不要分配此角色。相反，创建一个用户定义的角色，授予对任何资源的任何操作，并确保只有需要访问这些操作的用户才具有此访问权。