什么是MongoDB 8.0：核心概念与BSON优势解析
当产品经理提出“我们需要快速上线一个支持用户自定义字段的电商后台”时，传统关系型数据库的表结构变更往往成为开发进度的瓶颈。修改表结构需要执行 ALTER TABLE，在海量数据下这会导致锁表甚至服务中断。MongoDB 8.0 作为 2024年10月 正式发布的最新稳定版本，正是为了解决这种业务敏捷性与数据刚性之间的矛盾而设计的。它不再强制要求预先定义统一的表结构，而是允许数据以文档的形式自然生长。
MongoDB 的核心在于其文档模型。与传统的关系型数据库不同，MongoDB 使用 BSON（Binary JSON） 格式存储数据。BSON 是 JSON 的二进制表示形式，但它不仅仅是 JSON 的替代品。如果你曾尝试在 JSON 中存储日期或者长整型数字，你会发现它们通常会被转换为字符串，这既浪费空间又增加了反序列化的复杂度。BSON 原生支持 Date、ObjectId、Binary Data 等丰富的数据类型。例如，一个用户文档在 BSON 中可以这样直观地存在：
{
"_id": ObjectId("507f1f77bcf86cd799439011"),
"username": "tech_blogger",
"created_at": ISODate("2024-10-01T12:00:00Z"),
"profile_views": Long("1500"),
"tags": ["mongodb", "nodejs", "ai"]
}
这种结构让开发者可以直接映射应用程序中的对象，无需进行复杂的 ORM（对象关系映射）转换。
除了灵活的数据结构，MongoDB 8.0 在核心架构上也进行了显著升级。在 高可用 方面，它通过 Replica Set（复制集） 机制，利用 Raft 协议的变种进行自动选举和故障转移。这意味着当主节点发生故障时，集群能在秒级内推选新的主节点，保证服务不中断。对于需要存储 海量数据 的场景，MongoDB 提供了原生的 Sharding（分片） 机制，将数据水平分散存储在多个服务器上，突破了单机硬件的限制。
值得注意的是，MongoDB 8.0 正在向 AI 原生数据库 演进。传统的数据库需要配合外部向量库（如 Pinecone 或 Milvus）才能实现 AI 应用的向量检索，但 MongoDB 8.0 内置了 Atlas Vector Search 能力。开发者可以直接在同一个数据库中存储原始文档数据和其对应的向量嵌入（Embeddings），利用近似最近邻算法（ANN）进行检索。这使得构建 RAG（检索增强生成）应用变得极其简单，无需维护两套不同的存储系统。
此外，MongoDB 8.0 引入了 存算分离架构 的优化，这在云原生环境下极大地降低了成本并提升了弹性伸缩能力。配合 ACID 事务 支持，它现在已经能够处理跨文档、跨集合的复杂业务逻辑，弥补了早期版本在强一致性方面的短板。对于开发者而言，这意味着你既拥有 NoSQL 的灵活性，又不必牺牲关系型数据库的事务安全性。
快速上手：MongoDB Atlas云数据库与本地环境搭建
在评估技术选型时，开发效率往往是第一考量。对于全栈工程师来说，环境搭建不应成为阻碍。MongoDB 提供了两种主要的部署方式：全托管的云服务 MongoDB Atlas 和本地自部署。考虑到 2024 年云原生已成为主流趋势，且 Atlas 提供了 Serverless 按量计费模式，对于个人开发者或快速验证阶段的初创项目，Atlas 是更优的选择。
MongoDB Atlas 云数据库配置
MongoDB Atlas 是官方提供的 DBaaS（数据库即服务）解决方案。它消除了安装、补丁和备份的运维负担。以下是快速构建一个免费集群的步骤：
- 访问 MongoDB 官网注册账号并进入 Atlas 控制台。
- 选择 Create a Cluster，在 Provider 中选择 AWS、Azure 或 GCP。
- 在 Cluster Tier 中选择 M0 Sandbox（免费层），这对于学习和小型应用完全足够。
- 在 Additional Settings 中，确保版本选择为 MongoDB 8.0。
- 点击创建，等待约 3 分钟集群初始化完成。
集群创建完成后，你需要配置 Network Access。在云环境中，安全性至关重要。点击 "Network Access"，添加你的当前 IP 地址，或者为了开发方便（不推荐生产环境），暂时允许从任何地方访问（0.0.0.0/0）。
接下来配置 Database Access，创建一个数据库用户，设置用户名和密码。记下这个密码，后续连接字符串会用到。
本地环境搭建
如果你更倾向于本地开发环境，或者需要进行离线调试，可以使用 Docker 快速启动一个 MongoDB 8.0 实例。Docker 容器化确保了环境与生产环境的一致性。
执行以下命令拉取并运行 MongoDB 8.0 镜像：
docker run --name mongodb-8 -p 27017:27017 -e MONGO_INITDB_ROOT_USERNAME=admin -e MONGO_INITDB_ROOT_PASSWORD=password123 -d mongo:8.0
上述命令启动了一个名为 mongodb-8 的容器，映射了默认的 27017 端口，并设置了管理员账号。
连接数据库
无论使用 Atlas 还是本地 Docker，我们都需要一个连接字符串（Connection String）。在 Atlas 控制台点击 "Connect"，选择 "Drivers"，你会看到如下格式的字符串：
mongodb+srv://<username>:<password>@cluster0.mongodb.net/?retryWrites=true&w=majority
为了验证连接，我们可以使用 MongoDB Shell (mongosh)。如果你本地没有安装，可以通过 npm 全局安装：
npm install -g mongosh
使用以下命令连接（如果是 Atlas，请替换
mongosh "<connection_string>"
连接成功后，你会看到 MongoDB 8.0 的欢迎界面。此时可以创建一个用于测试的数据库：
use ecommerce_db
db.products.insertOne({ name: "Test Product", price: 99.9 })
db.products.find()
可视化工具推荐
虽然 mongosh 功能强大，但图形化界面对于查看数据结构更为直观。推荐使用 MongoDB Compass。它支持最新的 8.0 特性，包括查看向量索引和聚合管道的可视化编辑。下载安装后，只需粘贴连接字符串即可直接管理你的数据和索引。
CRUD实战：使用Node.js进行文档的增删改查操作
在现代 Web 开发中，Node.js 因其非阻塞 I/O 特性，常与 MongoDB 搭配用于构建高性能的后端服务。我们将基于 MongoDB Node.js Driver 来实现标准的 CRUD（创建、读取、更新、删除）操作。这比使用 ORM 框架更能让你理解底层的运作机制。
项目初始化与依赖安装
首先，创建一个新的 Node.js 项目并安装官方驱动：
mkdir mongodb-crud-demo
cd mongodb-crud-demo
npm init -y
npm install mongodb dotenv
在项目根目录创建 .env 文件，填入你的数据库连接字符串（如果是本地，通常是 mongodb://admin:password123@localhost:27017）：
MONGODB_URI=mongodb+srv://<user>:<password>@cluster0.mongodb.net/ecommerce_db?retryWrites=true&w=majority
建立数据库连接
创建一个 db.js 文件，封装连接逻辑。良好的连接管理可以避免重复建立连接带来的性能损耗。
// db.js
const { MongoClient } = require('mongodb');
require('dotenv').config();
const uri = process.env.MONGODB_URI;
const client = new MongoClient(uri);
async function connectDB() {
try {
await client.connect();
console.log("Successfully connected to MongoDB 8.0");
return client.db(); // 返回默认的数据库实例
} catch (error) {
console.error("Failed to connect to database", error);
process.exit(1);
}
}
module.exports = { connectDB, client };
实现 CRUD 操作
接下来，我们创建一个 app.js 文件，演示如何操作一个“商品”集合（Collection）。MongoDB 8.0 的驱动在异步处理上非常成熟，我们全程使用 async/await。
// app.js
const { connectDB, client } = require('./db');
async function runCRUDOperations() {
const db = await connectDB();
const productsCollection = db.collection('products');
try {
// 1. Create (插入文档)
// MongoDB 的灵活性体现在这里：我们可以插入结构完全不同的文档
const newProduct = {
name: "Wireless Mouse",
price: 29.99,
category: "Electronics",
stock: 150,
attributes: { color: "Black", wireless: true }, // 嵌入式文档
createdAt: new Date() // BSON Date 类型
};
const insertResult = await productsCollection.insertOne(newProduct);
console.log(`Inserted document with _id: ${insertResult.insertedId}`);
// 2. Read (查询文档)
// 根据特定条件查询
const findProduct = await productsCollection.findOne({ name: "Wireless Mouse" });
console.log("Found product:", findProduct);
// 3. Update (更新文档)
// 使用 $inc 操作符增加库存，这是原子操作
const updateResult = await productsCollection.updateOne(
{ _id: insertResult.insertedId },
{
$inc: { stock: 50 },
$set: { lastUpdated: new Date() }
}
);
console.log(`Matched ${updateResult.matchedCount} and modified ${updateResult.modifiedCount} document(s)`);
// 4. Delete (删除文档)
// 清理测试数据
const deleteResult = await productsCollection.deleteOne({ _id: insertResult.insertedId });
console.log(`Deleted ${deleteResult.deletedCount} document(s)`);
// 演示批量插入和复杂查询
await productsCollection.insertMany([
{ name: "Keyboard", price: 75, tags: ["mechanical", "rgb"] },
{ name: "Monitor", price: 300, tags: ["4k", "gaming"] }
]);
// 使用聚合框架进行数据分析
const aggResult = await productsCollection.aggregate([
{ $match: { price: { $gt: 50 } } },
{ $group: { _id: null, totalValue: { $sum: "$price" } } }
]).toArray();
console.log("Aggregation Result (Total value of items > $50):", aggResult);
} finally {
// 确保连接关闭
await client.close();
}
}
runCRUDOperations().catch(console.error);
场景分析：嵌入式与引用式设计
在上述代码中，attributes 字段是一个内嵌的文档。这引出了一个经典的设计问题：何时该嵌入，何时该引用？
如果你的数据具有 强一致性 且 经常一起查询（如商品的规格参数），嵌入式设计（Embedding）是最好的选择，因为它避免了昂贵的 Join 操作，读取性能极高。MongoDB 8.0 虽然没有传统 SQL 的 Join，但通过 $lookup 支持左外连接。
如果你遇到 一对多 的关系，且子文档会无限增长（如用户发表的评论），则应采用 引用式设计（Referencing）。例如，在订单集合中存储 userId 而不是把用户的所有信息都塞进订单里。
运行上述代码，你将看到数据从插入到删除的完整生命周期。这种直接操作对象的方式，极大地缩短了从需求到上线的路径，这正是 MongoDB 在敏捷开发场景中备受青睐的原因。
进阶技巧：聚合管道Aggregation与多文档ACID事务
如果你刚上手 MongoDB，可能觉得 find() 和 insert() 就够用了。但一旦业务稍微复杂点，比如要做个周报统计，或者要同时扣款并生成订单，简单的 CRUD 就力不从心了。这时候就得请出 MongoDB 的两个大杀器：聚合管道（Aggregation Pipeline） 和 多文档 ACID 事务。MongoDB 8.0 在这两块的表现非常稳，尤其是事务性能，经过几个版本的迭代，已经完全能扛起金融级业务的重担。
先聊聊聚合管道。你可以把它想象成流水线上的工人，数据从一头进去，经过一道道工序（Stage），最后从另一头出来变成了你想要的样子。这和 SQL 里的 GROUP BY、JOIN 思路类似，但更灵活，因为它是基于文档操作的。
假设我们在做一个电商后台，有一个 orders 集合，里面存着订单数据。数据结构大概是这样的：
{
"_id": ObjectId("..."),
"userId": "user_001",
"status": "completed",
"totalAmount": 299.00,
"items": [
{ "name": "Keyboard", "price": 100, "quantity": 1 },
{ "name": "Mouse", "price": 199, "quantity": 1 }
],
"createdAt": ISODate("2024-10-25T10:00:00Z")
}
现在老板要看一下 2024 年 10 月份，每个用户的消费总额和订单数量，并按消费额从高到低排个序。用聚合管道写起来非常直观：
db.orders.aggregate([
// 1. 过滤数据，只拿10月已完成的订单
{
$match: {
status: "completed",
createdAt: {
$gte: ISODate("2024-10-01T00:00:00Z"),
$lt: ISODate("2024-11-01T00:00:00Z")
}
}
},
// 2. 按用户ID分组，计算总金额和订单数
{
$group: {
_id: "$userId",
totalSpent: { $sum: "$totalAmount" },
orderCount: { $sum: 1 }
}
},
// 3. 重塑字段，让输出好看点
{
$project: {
_id: 0,
userId: "$_id",
totalSpent: 1,
orderCount: 1
}
},
// 4. 排序
{
$sort: { totalSpent: -1 }
}
])
这一连串的操作符 $match、$group、$sort 就是管道的阶段。MongoDB 8.0 的聚合引擎在处理大数据集时，会尝试把 $match 和 $sort 下推到查询层，尽量减少内存占用。
再说说多文档事务。以前大家总拿 MongoDB 不支持事务说事，那是老黄历了。现在的 MongoDB 早就支持 ACID 了。在 8.0 版本里，事务的写入吞吐量甚至有了显著提升，实测数据表明在某些场景下性能翻倍。
什么场景下必须用事务？比如你要给 A 用户转账给 B 用户。这在 MongoDB 里通常意味着要更新两个文档（A 扣钱，B 加钱）。如果 A 扣完钱，数据库崩了，B 没收到钱，这就乱套了。
在 Node.js 驱动里，代码大概长这样：
const { MongoClient } = require('mongodb');
// 假设 client 已经连接
async function transferFunds(client, fromId, toId, amount) {
const session = client.startSession();
try {
await session.withTransaction(async () => {
const accounts = client.db('bank').collection('accounts');
// 1. 检查余额并扣款
const debitResult = await accounts.updateOne(
{ accountId: fromId, balance: { $gte: amount } },
{ $inc: { balance: -amount } },
{ session }
);
if (debitResult.modifiedCount === 0) {
throw new Error('余额不足或者账户不存在');
}
// 2. 收款
await accounts.updateOne(
{ accountId: toId },
{ $inc: { balance: amount } },
{ session }
);
console.log('转账成功');
}, {
readConcern: { level: 'local' },
writeConcern: { w: 'majority' }
});
} catch (error) {
console.error(`转账失败: ${error}`);
} finally {
await session.endSession();
}
}
注意这个 session 对象，它是事务的核心。所有操作都必须带着这个 session，这样它们才属于同一个原子操作。一旦 withTransaction 里的回调抛出错误，整个事务都会回滚，数据恢复到操作前的状态。
聚合里的数组玩法
除了上面的统计，聚合管道对数组的处理也很暴力。比如我们想分析订单里哪个商品卖得最好。由于商品信息是在 items 数组里的，我们得先用 $unwind 把数组拆开。
db.orders.aggregate([
{ $unwind: "$items" },
{
$group: {
_id: "$items.name",
totalSold: { $sum: "$items.quantity" },
revenue: { $sum: { $multiply: ["$items.price", "$items.quantity"] } }
}
},
{ $sort: { revenue: -1 } }
])
$unwind 会把一条包含多个商品的订单，拆成多条文档，每条只包含一个商品。这在处理复杂嵌套结构时非常有用。不过要注意，如果数组很大，$unwind 会产生大量文档，记得配合索引使用。
MongoDB 8.0 还优化了在执行聚合时的内存管理，虽然默认还是 100MB 的限制，但在处理复杂 Pipeline 时更稳定了。如果你确定数据量很大，记得加上 allowDiskUse: true 选项，让 MongoDB 把临时数据写到磁盘，别把它憋坏了。
AI应用与架构：向量搜索Vector Search及Schema设计
现在的开发圈子里，不聊点 AI 或者大模型，感觉都跟不上时代。MongoDB 8.0 发布的时候，我就特别关注它在 AI 原生数据库 这块的动作。以前我们要做向量搜索（Vector Search），还得专门搭一个 Pinecone 或者 Milvus，数据在不同数据库之间倒腾，同步麻烦不说，一致性也是个头疼事。现在 MongoDB 直接在核心引擎里集成了向量搜索，这就是 Atlas Vector Search（如果你用 Atlas 云服务的话，社区版也有相应的向量索引支持），这对于我们全栈工程师来说简直是福音。
向量搜索实战
向量搜索的核心是把文本、图片转成数字数组（Embeddings），然后存进 MongoDB。当你查询时，数据库会计算你查询向量的距离，找到最相似的那些文档。
假设我们在做一个 RAG（检索增强生成）应用。我们需要把一堆文档切片，转换成向量，然后存进去。
首先，我们得在集合上创建一个向量索引（这通常在 Atlas 控制台操作，或者使用 API，这里演示数据结构）：
{
"mappings": {
"dynamic": true,
"fields": {
"embedding": {
"type": "knnVector",
"dimensions": 1536,
"similarity": "cosine"
}
}
}
}
这里我们定义了一个 embedding 字段，维度是 1536（对应 OpenAI 的 text-embedding-ada-002 模型），相似度算法用余弦距离。
接下来，我们往数据库里塞数据：
const { MongoClient, ObjectId } = require('mongodb');
const OpenAI = require('openai'); // 假设我们用OpenAI生成向量
async function storeDocument(client, textContent) {
const openai = new OpenAI({ apiKey: 'your-api-key' });
const db = client.db('rag_db');
const collection = db.collection('knowledge_base');
// 1. 把文本变成向量
const embeddingResponse = await openai.embeddings.create({
model: "text-embedding-ada-002",
input: textContent,
});
const vector = embeddingResponse.data[0].embedding;
// 2. 存进MongoDB
const doc = {
content: textContent,
embedding: vector,
source: 'internal_wiki',
createdAt: new Date()
};
await collection.insertOne(doc);
console.log('文档已存储并向量化');
}
现在，当用户提问时，我们也把问题转成向量，然后去 MongoDB 里找最相关的文档：
async function searchSimilarDocs(client, queryText) {
const openai = new OpenAI({ apiKey: 'your-api-key' });
const db = client.db('rag_db');
const collection = db.collection('knowledge_base');
// 1. 把查询问题转成向量
const queryEmbedding = await openai.embeddings.create({
model: "text-embedding-ada-002",
input: queryText,
});
const queryVector = queryEmbedding.data[0].embedding;
// 2. 执行向量搜索
const results = await collection.aggregate([
{
$vectorSearch: {
index: "vector_index", // 就是上面创建的索引名
path: "embedding",
queryVector: queryVector,
numCandidates: 100, // 扫描的候选数
limit: 5 // 返回前5个结果
}
},
{
$project: {
content: 1,
score: { $meta: "vectorSearchScore" } // 把相似度分数带出来
}
}
]).toArray();
return results;
}
看到没，不需要额外的向量数据库，直接用 MongoDB 就搞定了。这在构建 AI 应用记忆单元时非常高效，尤其是 MongoDB 8.0 强调的存算分离架构，让这种计算密集型的查询在云上成本更低。
Schema 设计：嵌入式还是引用式？
聊完 AI，我们再扯回最经典的 Schema 设计问题。MongoDB 是文档型数据库，没有固定的表结构，但这不代表你可以乱存。社区里关于嵌入式（Embedding）和引用式（Referencing）的争论就没停过。
简单来说：
- 嵌入式：把相关数据塞进一个文档里。就像订单里直接包含
items 数组。
- 引用式：就像关系型数据库，存个
userId 去关联另一个集合。
怎么选？看你的读写模式。
如果你的数据总是一起被读取，且是一对少的关系，就嵌入式。比如电商的购物车，用户信息和购物车商品放一个文档里，读取一次就够了。
// 嵌入式例子
{
"_id": "cart_123",
"userId": "user_001",
"items": [
{ "productId": "p1", "name": "Book", "qty": 1 },
{ "productId": "p2", "name": "Pen", "qty": 2 }
],
"updatedAt": ISODate("...")
}
如果你是一对多，或者多对多，而且关联数据可能单独变化，就引用式。比如博客文章和评论。一篇文章可能有几千条评论，如果把评论都嵌进去，那个文档会变得巨大无比，更新效率极低。
// 文章集合
{ "_id": "post_1", "title": "MongoDB 8.0 新特性", "authorId": "user_001" }
// 评论集合
{ "_id": "comment_1", "postId": "post_1", "content": "写得好", "userId": "user_002" }
在 MongoDB 8.0 里，虽然没有强制约束，但我们可以利用 Schema Validation 来强制数据结构，避免后期数据烂尾。
db.createCollection("users", {
validator: {
$jsonSchema: {
bsonType: "object",
required: ["name", "email", "createdAt"],
properties: {
name: {
bsonType: "string",
description: "name must be a string and is required"
},
email: {
bsonType: "string",
pattern: "^.+@.+$",
description: "email must be valid"
},
age: {
bsonType: "int",
minimum: 0,
maximum: 120
}
}
}
},
validationLevel: "strict"
})
这样，当你插入不符合规范的数据时，MongoDB 就会报错，强迫你写出规范的代码。
常见问题：复制集原理、索引优化与面试题解析
做后端开发，面试或者实际运维时，总会遇到一些绕不开的问题。比如数据库挂了怎么办？查询怎么变快？MongoDB 和 MySQL 到底选哪个？这些其实都是 MongoDB 核心机制的体现。
复制集（Replica Set）到底是怎么玩的？
很多新手以为复制集就是主从复制（Master-Slave），其实不是。MongoDB 的复制集是一个自动故障转移的集群。它通常由一个 Primary（主节点）和多个 Secondary（从节点）组成。
它的原理基于 Raft 协议的变种。所有的写操作都必须进 Primary，Primary 会把操作记录到一个叫 oplog（操作日志） 的特殊集合里。Secondary 节点会不断地去轮询 Primary，拉取 oplog，然后在自己身上重放这些操作，以此来保持数据和主节点一致。
如果 Primary 突然挂了（比如机房断电），剩下的 Secondary 节点会立刻通过心跳检测发现这个情况，然后它们会选举出一个新的 Primary。这个选举过程非常快，通常在几秒内就能完成，对应用层基本无感。
在实际配置中，如果你在本地测试，可以这样启动一个复制集（假设有三个实例）：
# 启动三个mongod实例，指定不同的端口和路径
mongod --port 27017 --dbpath /data/rs1 --replSet rs0 --fork --logpath /data/rs1/log.txt
mongod --port 27018 --dbpath /data/rs2 --replSet rs0 --fork --logpath /data/rs2/log.txt
mongod --port 27019 --dbpath /data/rs3 --replSet rs0 --fork --logpath /data/rs3/log.txt
然后在 mongo shell 里初始化：
rs.initiate({
_id: "rs0",
members: [
{ _id: 0, host: "localhost:27017" },
{ _id: 1, host: "localhost:27018" },
{ _id: 2, host: "localhost:27019" }
]
})
配置好后，你可以用 rs.status() 查看状态。记住，复制集不仅是为了高可用，还能用来做读写分离。你可以把那些对实时性要求不高的查询（比如生成报表）指向 Secondary 节点，减轻 Primary 的压力。
索引优化：别让你的查询全表扫描
索引是提升查询性能的捷径。MongoDB 默认会在 _id 上建索引，但如果你经常根据 email 或者 createdAt 查数据，就得自己动手了。
最常见的就是复合索引。比如你的查询经常是 db.users.find({ status: "active", age: { $gt: 21 } })。
你该怎么建索引？原则是ESR（Equality, Sort, Range）。
- 先放精确匹配的字段（Equality）：
status
- 再放排序字段（Sort）：如果有的话
- 最后放范围查询字段（Range）：
age
所以索引应该是 db.users.createIndex({ status: 1, age: 1 })。
建完索引，一定要用 explain() 看看效果：
db.users.find({ status: "active", age: { $gt: 21 } }).explain("executionStats")
如果输出里的 winningPlan.stage 是 COLLSCAN，说明你在全表扫描，赶紧回去检查索引。如果是 IXSCAN，恭喜你，走索引了。
MongoDB 8.0 在索引优化上没啥特别大的架构变动，但内核层面的优化一直在进行，使得索引的维护成本更低。
面试高频题：MongoDB 和关系型数据库怎么选？
面试官特别喜欢问这个。你不能只说“MongoDB 是文档型，MySQL 是关系型”。得从实际场景出发。
- Schema 灵活性：如果你做的是快速迭代的创业项目，需求三天两头变，数据结构经常加字段，MongoDB 简直是神器。不用写
ALTER TABLE 去改表结构，直接存就行。关系型数据库虽然也有 JSON 字段，但查询性能和索引支持通常不如原生的 MongoDB。
- 扩展性：MongoDB 是原生分片（Sharding）。如果你预计数据会增长到 TB 级别，甚至 PB 级别，MongoDB 的分片机制可以让你通过增加机器来水平扩展。MySQL 的分片通常得靠中间件（如 MyCat）或者业务层自己实现，比较痛苦。
- 事务需求：如果你做的是强一致性的金融系统，需要复杂的多表 Join 和严格的事务，那 PostgreSQL 或 MySQL 依然是首选。虽然 MongoDB 8.0 支持多文档 ACID 事务，但在处理极其复杂的跨表关联查询时，关系型数据库的 SQL 表达能力和优化器还是更成熟。
还有个常考的点：什么是 BSON？
别只说它是二进制 JSON。得提一句 BSON 是 Binary JSON 的缩写。它比 JSON 强的地方在于支持更多的数据类型，比如 Date、ObjectId、Binary Data（存图片字节流）。而且 BSON 是二进制的，解析起来比文本 JSON 快得多，虽然在存储空间上可能比纯 JSON 稍微大一点点，但为了性能，这点空间开销完全值得。
比如你在代码里看到的 ObjectId("507f1f77bcf86cd799439011")，这就是 BSON 特有的类型，它包含了时间戳、机器标识、进程ID和计数器，保证了分布式环境下的唯一性。
总结一下，MongoDB 8.0 作为最新的稳定版，在 2024 年 10 月发布，它的存算分离架构和向量搜索能力，让它不仅仅是个数据库，更像是一个现代化的数据平台。无论是做传统的 Web 后端，还是前沿的 AI 应用，它都能很好地适应。