MongoDB: 数据库与集合:MongoDB的命名空间管理
最后更新:2026-08-26
数据库是集合的容器,集合是文档的容器——这是 MongoDB 数据的层级结构。
本课程深入理解数据库/集合的概念、命名规则、创建方式,以及特殊的 capped collection 固定集合。
1. 你将学到
- 数据库与集合的本质区别(命名空间)
- MongoDB 集合的 schema-less 设计哲学
- 数据库/集合的命名规则和限制
- 隐式创建 vs 显式创建的差异
use、show、db.createCollection()的用法- capped collection 固定集合(环形队列)
- 集合元数据查看与数据库管理
2. 一个数据库管理员的真实故事
(1) 痛点:命名混乱导致维护困难
Diana 是 MongoDB 数据库管理员,负责管理公司的电商数据库。她发现:
"我们有 50+ 个数据库、500+ 个集合,命名五花八门:
shopdb.Products、shop-db.Products、shop-db.product_list……查询时不知道用哪个,备份脚本经常出错。"
混乱的现状:
| 问题 | 影响 |
|---|---|
| 命名风格不一致 | 团队成员找不到集合 |
| 大小写混用 | MongoDB 大小写敏感,查询失败 |
| 特殊字符 | $ 开头的集合名是保留字 |
| 无 schema 文档 | 无法区分同名字段类型(price 是 Number 还是 String?) |
(2) MongoDB + 命名规范的解法
制定命名规范 + Schema 验证。
// === 命名规范(驼峰式 + 业务前缀)===
// ❌ 反例
db.Products // 大写无前缀
db["shop-db.product"] // 含 . 和 -
db.$reserved // $ 开头保留字
// ✅ 正例
db.shop_products // 业务前缀 + 业务名(小写下划线)
db.shop_orders
db.shop_users
// === Schema 验证(mongoose 集中管理字段类型)===
const ProductSchema = new mongoose.Schema({
sku: { type: String, required: true }, // 明确 String 类型
price: { type: mongoose.Schema.Types.Decimal128, required: true }, // 明确 Decimal128
createdAt: { type: Date, default: Date.now } // 明确 Date 类型
});
(3) 收益
| 维度 | 混乱命名 | 规范命名 |
|---|---|---|
| 可发现性 | ❌ 难找 | ✅ 一眼定位 |
| 维护成本 | 高 | 低 |
| 团队协作 | 沟通成本高 | 无歧义 |
| 备份/恢复 | 易出错 | 自动化可靠 |
3. 数据库(Database)概念
概念说明:数据库是 MongoDB 中最顶层的命名空间,用于组织相关的集合。每个 MongoDB 实例可以包含多个数据库,每个数据库有独立的文件存储、权限控制和索引空间。数据库之间在物理存储上是隔离的,但不能跨数据库执行 $lookup 关联查询。
工作原理:MongoDB 为每个数据库分配独立的文件空间(WiredTiger 引擎下每个数据库一个文件夹)。数据库不是物理创建的——当你执行 use shopdb 时,MongoDB 只是切换上下文,数据库在第一次写入数据时才真正创建。删除数据库会物理删除对应的文件空间。
graph TB
A[MongoDB Server 实例] --> B[admin 数据库<br/>系统管理]
A --> C[config 数据库<br/>分片集群元数据]
A --> D[local 数据库<br/>副本集状态]
A --> E[shopdb 业务数据库]
A --> F[analyticsdb 分析数据库]
E --> E1[users 集合]
E --> E2[products 集合]
E --> E3[orders 集合]
F --> F1[events 集合]
F --> F2[user_behavior 集合]
style E fill:#d4edda
| 系统数据库 | 用途 | 是否用户可见 | 可写 |
|---|---|---|---|
| admin | 系统管理、用户认证 | ✅ | ⚠️ 仅管理操作 |
| config | 分片集群配置 | ✅(只读) | ❌ |
| local | 副本集状态、本地数据 | ✅(每节点独立) | ⚠️ |
| test | 测试用途(默认创建) | ✅ | ✅ |
(1) 什么是数据库?
数据库是 MongoDB 中顶层命名空间,用于组织相关的集合。
graph TB
A[MongoDB Server 实例] --> B[admin 数据库<br/>系统管理]
A --> C[config 数据库<br/>分片集群元数据]
A --> D[local 数据库<br/>副本集状态]
A --> E[shopdb 业务数据库]
A --> F[analyticsdb 分析数据库]
E --> E1[users 集合]
E --> E2[products 集合]
E --> E3[orders 集合]
F --> F1[events 集合]
F --> F2[user_behavior 集合]
style E fill:#d4edda
(2) 4 个系统数据库
要点解析:
admin是最特殊的数据库——在 admin 中创建的用户拥有全局权限config存储分片集群的元数据(非分片环境几乎为空)local的数据不会复制到副本集的其他节点——适合存储只需本地的数据test是 mongosh 默认连接的数据库,生产环境应避免使用
(3) 数据库命名规则
// === MongoDB 数据库命名规则 ===
// ✅ 合法的数据库名
use shopdb // 字母数字
use shop_db // 下划线
use "shop-db" // 含连字符(需引号)
use "shop.2026" // 含点号(需引号)
// ❌ 非法的数据库名
use "" // 空字符串
use "shop/db" // 含斜杠
use "shop$db" // $ 开头(虽然合法但不推荐)
use "admin" // 系统保留(虽然可用但不推荐)
| 规则 | 说明 |
|---|---|
| 不能为空 | 必须至少 1 个字符 |
| 不能含 | / \ . " $ * < > : | ?(Windows 文件系统限制) |
| 区分大小写 | shopdb ≠ SHOPDB |
| 长度限制 | 64 字符(Linux 文件系统限制) |
| UTF-8 | 支持中文(但不推荐) |
▶ 示例 1:数据库管理命令
// === 列出所有数据库 ===
show dbs
// admin 0.000GB
// config 0.000GB
// local 0.000GB
// shopdb 0.005GB
// test 0.000GB
// === 切换数据库 ===
use shopdb
// switched to db shopdb
// === 显示当前数据库 ===
db
// shopdb
// === 删除数据库(慎用!)===
db.dropDatabase()
// { "dropped" : "shopdb", "ok" : 1 }
// === 查看数据库统计信息 ===
db.stats()
// {
// db: 'shopdb',
// collections: 5,
// views: 0,
// objects: 1250,
// avgObjSize: 245,
// dataSize: 306250,
// storageSize: 286720,
// indexes: 8,
// indexSize: 57344,
// fileSize: 67108864,
// nsSizeMB: 16
// }
输出:
// 执行成功
4. 集合(Collection)概念
概念说明:集合是 MongoDB 中文档的容器,类似于关系型数据库的"表",但有一个根本区别——集合是 schema-less 的,同一个集合中的文档可以有不同的字段组合。这种灵活性是 MongoDB 的核心优势,也是潜在的风险来源(需要应用层或 Schema Validation 保证数据质量)。
工作原理:集合在 MongoDB 的命名空间中标识为 <database>.<collection>。集合本身不存储数据——数据以 BSON 文档形式存储在集合的文件空间中,集合只维护元数据(索引信息、Schema 验证规则、capped 设置等)。集合在第一次插入文档时隐式创建,也可以通过 createCollection() 显式创建。
graph TB
A[shopdb 数据库] --> B[users 集合]
A --> C[products 集合]
A --> D[orders 集合]
B --> B1[文档 1<br/>name: Alice<br/>age: 28]
B --> B2[文档 2<br/>name: Bob<br/>age: 32<br/>role: admin]
B --> B3[文档 3<br/>name: Charlie<br/>email: c@example.com]
style B2 fill:#f8d7da
要点解析:同一个集合可以有不同的字段(schema-less),文档 1 有 age,文档 3 有 email 但没 age。这是 MongoDB 灵活性的体现——但也意味着需要 mongoose Schema 或 Schema Validation 来约束字段。
| 维度 | 关系型表 | MongoDB 集合 |
|---|---|---|
| Schema | 强约束(DDL 定义) | 无约束(schema-less) |
| 字段 | 每行必须相同字段 | 每行可不同字段 |
| 数据类型 | 强类型(DDL 定义) | 弱类型(运行时检查) |
| 关系 | 外键约束 | 应用层引用 |
| JOIN | 原生支持 | $lookup(弱支持) |
| 水平扩展 | 复杂 | 内置 Sharding |
(1) 什么是集合?
集合是 MongoDB 中文档的容器,类似于关系型数据库的"表",但没有 schema 约束。
graph TB
A[shopdb 数据库] --> B[users 集合]
A --> C[products 集合]
A --> D[orders 集合]
B --> B1[文档 1<br/>name: Alice<br/>age: 28]
B --> B2[文档 2<br/>name: Bob<br/>age: 32<br/>role: admin]
B --> B3[文档 3<br/>name: Charlie<br/>email: c@example.com]
style B2 fill:#f8d7da
注意:同一个集合可以有不同的字段(schema-less),文档 1 有 age,文档 3 有 email 但没 age。
(2) 集合 vs 关系型表
| 维度 | 关系型表 | MongoDB 集合 |
|---|---|---|
| Schema | 强约束(DDL 定义) | 无约束(schema-less) |
| 字段 | 每行必须相同字段 | 每行可不同字段 |
| 数据类型 | 强类型(DDL 定义) | 弱类型(运行时检查) |
| 关系 | 外键约束 | 应用层引用 |
| JOIN | 原生支持 | $lookup(弱支持) |
| 水平扩展 | 复杂 | 内置 Sharding |
(3) 集合命名规则
// ✅ 合法的集合名
db.shop_products // 字母数字下划线
db["shop-products"] // 含连字符(需引号)
db.shop2026 // 含数字
db["shop.products"] // 含点号(需引号)
// ❌ 非法的集合名
db[""] // 空字符串
db.$reserved // $ 开头(保留)
db["system.users"] // system. 开头(系统保留)
db["shop\\products"] // 含反斜杠
▶ 示例 2:集合管理命令
// === 列出当前数据库的所有集合 ===
show collections
// users
// products
// orders
// reviews
// === 显式创建集合 ===
db.createCollection("users");
// { ok: 1 }
// === 隐式创建集合(插入文档时自动创建)===
db.users.insertOne({ name: "Alice" });
// 集合不存在时自动创建
// === 创建固定大小集合(capped collection)===
db.createCollection("logs", {
capped: true,
size: 10485760, // 10 MB
max: 10000 // 最多 10000 条文档
});
// { ok: 1 }
// === 删除集合 ===
db.users.drop();
// true
// === 查看集合统计信息 ===
db.users.stats();
// {
// ns: 'shopdb.users',
// size: 1024,
// count: 50,
// avgObjSize: 20,
// storageSize: 8192,
// capped: false,
// max: null,
// ...
// }
输出:
// 执行成功
5. 隐式创建 vs 显式创建
概念说明:MongoDB 支持两种集合创建方式——隐式创建(插入文档时自动创建)和显式创建(通过 createCollection() 手动创建)。两种方式在开发体验和数据安全上有显著差异。开发阶段推荐隐式创建(快速迭代),生产环境推荐显式创建 + Schema 验证(防止脏数据)。
工作原理:隐式创建时,MongoDB 在第一次写入操作时自动创建数据库和集合,使用默认配置(非 capped、无验证规则)。显式创建时,可以预先指定 Schema 验证规则、capped 设置、排序规则等,确保后续写入的数据符合业务约束。
| 维度 | 隐式创建 | 显式创建 |
|---|---|---|
| 语法 | insertOne() 自动创建 |
createCollection() |
| Schema 验证 | ❌ 无 | ✅ 可定义 JSON Schema |
| capped 设置 | ❌ 默认非 capped | ✅ 可指定 |
| 适用场景 | 开发、测试 | 生产、严格数据校验 |
| 拼写错误 | 容易出错 | 需手动指定 |
(1) 隐式创建(推荐开发用)
// 1. 切换数据库(不存在则延迟创建)
use shopdb;
// 2. 直接插入文档
db.users.insertOne({ name: "Alice" });
// 自动创建 users 集合
// 3. 查看自动创建的集合
show collections;
// users
优点:简单快捷,无需手动管理
缺点:可能意外创建拼写错误的集合(如 user vs users)
(2) 显式创建(推荐生产用)
// 1. 创建空集合(用于预定义结构)
db.createCollection("users");
db.createCollection("products");
db.createCollection("orders");
// 2. 创建带验证的集合(Schema Validation)
db.createCollection("users", {
validator: {
$jsonSchema: {
bsonType: "object",
required: ["email", "username"],
properties: {
email: {
bsonType: "string",
pattern: "^.+@.+$"
},
username: {
bsonType: "string",
minLength: 3,
maxLength: 30
},
age: {
bsonType: "int",
minimum: 0,
maximum: 150
}
}
}
},
validationLevel: "strict",
validationAction: "error"
});
(3) 两种方式对比
| 维度 | 隐式创建 | 显式创建 |
|---|---|---|
| 语法 | insertOne() 自动创建 |
createCollection() |
| Schema 验证 | ❌ 无 | ✅ 可定义 JSON Schema |
| capped 设置 | ❌ 默认非 capped | ✅ 可指定 |
| 适用场景 | 开发、测试 | 生产、严格数据校验 |
| 拼写错误 | 容易出错 | 需手动指定 |
▶ 示例 3:capped collection 固定集合
// === 创建 capped collection(环形队列)===
db.createCollection("activity_logs", {
capped: true,
size: 10485760, // 10 MB 上限
max: 100000 // 最多 100,000 条文档
});
// === 插入文档(满了会自动覆盖最旧的)===
for (let i = 0; i < 5; i++) {
db.activity_logs.insertOne({
userId: `user_${i}`,
action: "login",
timestamp: new Date()
});
}
// === 查询 ===
db.activity_logs.find().sort({ timestamp: -1 }).limit(5);
// === 修改 capped collection 的大小 ===
db.runCommand({
collMod: "activity_logs",
cappedSize: 20971520 // 扩大到 20 MB
});
// === 转为普通集合(不可逆!)===
db.runCommand({
collMod: "activity_logs",
cappedSize: -1
});
输出:
// mongoose 操作成功执行
// 数据库查询/更新结果
capped collection 适用场景:
- 日志系统(自动清理旧日志)
- 消息队列(保留最新 N 条消息)
- 实时数据流(股票价格、传感器数据)
不适合场景:
- 需要更新文档(capped 不支持就地更新超过原始大小)
- 需要删除特定文档(capped 不能选择性删除)
6. 集合命名空间
概念说明:命名空间(Namespace)是 MongoDB 内部标识集合的唯一方式,格式为 <database>.<collection>。例如 shopdb.users 表示 shopdb 数据库中的 users 集合。命名空间在 MongoDB 的存储引擎中用于定位数据和索引文件,理解命名空间有助于理解 MongoDB 的内部存储结构。
工作原理:WiredTiger 存储引擎为每个集合创建独立的数据文件和索引文件,文件名中包含命名空间的哈希值。命名空间文件(.ns 文件)存储所有集合的元数据(索引信息、验证规则、capped 设置等)。命名空间文件默认 16 MB,限制了每个数据库能创建的集合数量。
graph TB
A[MongoDB 命名空间] --> B[数据库名.集合名]
B --> C[shopdb.users]
B --> D[shopdb.products]
B --> E[shopdb.orders]
B --> F[analytics.events]
style A fill:#cce5ff
| 项 | 限制 | 说明 |
|---|---|---|
| 命名空间文件大小 | 默认 16 MB | 可通过 --nssize 调整 |
| 集合数量/数据库 | 由命名空间文件大小决定 | 约 24000 个(16MB 时) |
| 命名空间总长度 | ≤ 120 字节 | 数据库名 + "." + 集合名 |
(1) 命名空间结构
graph TB
A[MongoDB 命名空间] --> B[数据库名.集合名]
B --> C[shopdb.users]
B --> D[shopdb.products]
B --> E[shopdb.orders]
B --> F[analytics.events]
style A fill:#cce5ff
命名空间(namespace) = <database>.<collection>,在 MongoDB 内部使用 .ns 文件存储元数据。
(2) 命名空间大小限制
| 项 | 限制 |
|---|---|
| 命名空间文件大小 | 默认 16 MB |
| 集合数量/数据库 | 由命名空间文件大小决定 |
| 命名空间大小调整 | 需重启 mongod |
(3) 查看所有命名空间
// === 查看所有集合的命名空间 ===
db.getCollectionNames();
// [ 'users', 'products', 'orders', 'reviews', 'activity_logs' ]
// === 带前缀的命名空间 ===
db.getCollectionInfos();
// [
// { name: 'users', type: 'collection' },
// { name: 'products', type: 'collection' },
// ...
// ]
// === 查看集合的命名空间(ns) ===
db.users.stats().ns;
// 'shopdb.users'
// === 切换集合(用于长集合名)===
const productsCollection = db.getCollection("products");
productsCollection.findOne();
// 等同于 db.products.findOne();
7. 集合元数据管理
(1) 集合统计信息
// === 单个集合统计 ===
db.users.stats();
// {
// ns: 'shopdb.users', // 命名空间
// size: 10240, // 数据大小(字节)
// count: 250, // 文档数量
// avgObjSize: 40, // 平均文档大小
// storageSize: 12288, // 磁盘占用
// capped: false, // 是否固定集合
// max: null, // 最大文档数(capped)
// maxSize: null, // 最大大小(capped)
// totalIndexSize: 16384, // 索引总大小
// indexSizes: { // 各索引大小
// _id_: 8192,
// email_1: 4096
// }
// }
// === 集合的索引信息 ===
db.users.getIndexes();
// [
// { v: 2, key: { _id: 1 }, name: '_id_' },
// { v: 2, key: { email: 1 }, name: 'email_1', unique: true }
// ]
// === 集合数据大小(不含索引)===
db.users.dataSize();
// 10240
(2) 集合存储信息
// === 查看集合的 WiredTiger 存储信息 ===
db.users.storageSize();
// 12288
// === 查看集合的所有命名空间信息 ===
db.users.totalSize();
// 24576
// === 集合内的索引大小 ===
db.users.totalIndexSize();
// 16384
▶ 示例 4:集合健康检查脚本
// === 集合健康检查 ===
function checkCollectionHealth(collName) {
const stats = db[collName].stats();
const indexes = db[collName].getIndexes();
print(`\n=== ${collName} 健康报告 ===`);
print(`文档数量: ${stats.count}`);
print(`数据大小: ${(stats.size / 1024).toFixed(2)} KB`);
print(`平均文档大小: ${stats.avgObjSize} bytes`);
print(`磁盘占用: ${(stats.storageSize / 1024).toFixed(2)} KB`);
print(`索引数量: ${indexes.length}`);
print(`索引大小: ${(stats.totalIndexSize / 1024).toFixed(2)} KB`);
print(`数据/磁盘比: ${((stats.size / stats.storageSize) * 100).toFixed(1)}%`);
print(`是否 capped: ${stats.capped ? '是' : '否'}`);
if (stats.capped) {
print(`capped size: ${(stats.maxSize / 1024 / 1024).toFixed(2)} MB`);
print(`capped max docs: ${stats.max}`);
}
}
// 检查所有集合
db.getCollectionNames().forEach(checkCollectionHealth);
输出:
// 执行成功
8. 数据库与集合的最佳实践
(1) 数据库设计原则
graph TB
A[数据库划分] --> B[按业务域<br/>shopdb / analyticsdb / logdb]
A --> C[按环境<br/>shopdb_dev / shopdb_staging / shopdb_prod]
A --> D[按租户<br/>shopdb_tenant1 / shopdb_tenant2]
B --> B1[✅ 推荐]
C --> C2[⚠️ 中小型项目]
D --> D3[⚠️ SaaS 多租户]
(2) 集合设计原则
| 原则 | 说明 |
|---|---|
| 小写 + 下划线 | shop_orders 而非 ShopOrders |
| 业务前缀 | shop_、blog_、crm_ 避免冲突 |
| 避免保留字 | 不用 system. 开头,不用 $ |
| 长度限制 | 集合名 ≤ 120 字符(考虑索引名前缀) |
| 单数 vs 复数 | 推荐复数(orders 而非 order) |
(3) 集合数量控制
| 数据库 | 推荐集合数 | 原因 |
|---|---|---|
| 小型项目 | 5-20 | 简单清晰 |
| 中型项目 | 20-100 | 业务扩展 |
| 大型项目 | 100-500 | 注意命名空间限制 |
| 超大型项目 | > 500 | 考虑多数据库拆分 |
▶ 示例 5:电商项目数据库结构
// === shopdb 数据库结构 ===
shopdb/
├── users // 用户信息
├── user_addresses // 收货地址(如需独立)
├── products // 商品
├── product_variants // 商品变体(颜色/尺寸)
├── categories // 商品分类
├── orders // 订单
├── order_items // 订单项(如数据量大)
├── reviews // 商品评价
├── carts // 购物车
├── coupons // 优惠券
├── sessions // 用户会话
└── activity_logs // 用户行为日志(capped collection)
// === analyticsdb 数据库结构(数据分析)===
analyticsdb/
├── user_events // 用户事件
├── page_views // 页面浏览
├── conversion_data // 转化漏斗
└── aggregated_stats // 聚合统计
// === logdb 数据库结构(运维日志)===
logdb/
├── app_logs // 应用日志(capped)
├── error_logs // 错误日志
└── audit_logs // 审计日志
输出:
// 执行成功
9. 综合实战:电商平台数据库初始化
(1) 场景需求
搭建一个电商平台的 MongoDB 数据库,包含:
- 核心业务集合(users/products/orders/reviews)
- 日志集合(capped collection)
- 数据库初始化脚本
(2) 初始化脚本
// === init-shopdb.js ===
// 1. 创建数据库(隐式)
const dbName = 'shopdb';
use(dbName);
// 2. 显式创建核心集合(带 Schema 验证)
db.createCollection('users', {
validator: {
$jsonSchema: {
bsonType: 'object',
required: ['email', 'username'],
properties: {
email: {
bsonType: 'string',
pattern: '^.+@.+$'
},
username: {
bsonType: 'string',
minLength: 3,
maxLength: 30
},
role: {
enum: ['customer', 'admin', 'moderator']
}
}
}
}
});
db.createCollection('products', {
validator: {
$jsonSchema: {
bsonType: 'object',
required: ['sku', 'title', 'price'],
properties: {
sku: {
bsonType: 'string',
pattern: '^[A-Z0-9-]+$'
},
price: {
bsonType: 'decimal'
}
}
}
}
});
// 3. 创建普通集合
db.createCollection('orders');
db.createCollection('reviews');
db.createCollection('carts');
// 4. 创建 capped collection(日志)
db.createCollection('activity_logs', {
capped: true,
size: 10485760, // 10 MB
max: 100000 // 最多 10 万条
});
// 5. 创建索引
db.users.createIndex({ email: 1 }, { unique: true });
db.users.createIndex({ username: 1 }, { unique: true });
db.users.createIndex({ createdAt: -1 });
db.products.createIndex({ sku: 1 }, { unique: true });
db.products.createIndex({ category: 1, price: 1 });
db.products.createIndex({ title: 'text', description: 'text' });
db.orders.createIndex({ userId: 1, createdAt: -1 });
db.orders.createIndex({ status: 1 });
db.reviews.createIndex({ productId: 1, createdAt: -1 });
db.reviews.createIndex({ userId: 1 });
// 6. 验证初始化
print('=== shopdb 初始化完成 ===');
print(`集合数量: ${db.getCollectionNames().length}`);
db.getCollectionNames().forEach(name => {
print(` - ${name}`);
});
// 7. 执行初始化
mongosh "mongodb://localhost:27017" init-shopdb.js
(3) 验证数据库结构
// === 查看数据库结构 ===
db.adminCommand('listCollections', { db: 'shopdb' });
// {
// cursor: {
// firstBatch: [
// { name: 'users', type: 'collection', info: { ... } },
// { name: 'products', type: 'collection', info: { ... } },
// ...
// ]
// }
// }
// === 查看集合统计 ===
db.getCollectionNames().forEach(name => {
const stats = db[name].stats();
print(`${name}: ${stats.count} docs, ${(stats.size / 1024).toFixed(2)} KB`);
});
❓ 常见问题
user vs users 会创建两个集合)。生产环境推荐显式创建 + Schema 验证,避免脏数据。$lookup 仅限同一数据库内的集合。跨数据库 JOIN 需应用层多次查询或使用 Atlas Data Lake。db.collection.findOne() 确认。📖 小节
- 数据库是集合的命名空间,集合是文档的容器
- MongoDB 默认 4 个系统数据库:admin / config / local / test
- 集合是 schema-less,同一集合可有不同字段
- 命名规则:小写字母 + 下划线 + 业务前缀,避免特殊字符
- 隐式创建简单但易拼写错误,显式创建安全但繁琐
- capped collection 是固定大小环形队列,适合日志和消息队列
- 集合统计信息:
db.collection.stats()、getIndexes()、dataSize()
📝 作业
-
基础题(⭐):在 mongosh 中创建 shopdb 数据库,包含 users、products、orders 三个集合,列出所有数据库和集合。
-
基础题(⭐):用
db.users.insertOne({...})隐式创建一个新集合(如 sessions),理解 MongoDB 的隐式创建机制。 -
进阶题(⭐⭐):创建一个 capped collection
activity_logs(size 5MB, max 1000),插入 100 条文档,验证自动覆盖最旧文档的行为。 -
进阶题(⭐⭐):编写 init 脚本
init-shopdb.js,创建 users/products/orders 集合(带 Schema 验证)+ 创建至少 5 个索引 + 创建 capped collection 日志集合。 -
进阶题(⭐⭐):用
db.collection.stats()检查所有集合,编写脚本输出"集合名称、文档数量、数据大小、平均文档大小、索引数量"的表格报告。 -
挑战题(⭐⭐⭐):设计一个 SaaS 多租户数据库结构(按业务域拆分 5 个数据库),编写完整的 init 脚本,创建所有集合 + 索引 + Schema 验证,输出初始化报告。