不是所有数据都适合塞进关系型表格。社交网络的人脉关系、IoT 设备的时间流水、AI 搜索的语义向量——不同的数据形态需要不同的建模方式。
数据以 JSON 文档存储，每条记录可以有不同的字段结构，天然适合嵌套、半结构化数据。
{
"_id": "user_1001",
"name": "张三",
"tags": ["VIP", "活跃"],
"address": {
"city": "北京",
"district": "朝阳区"
},
"orders": [
{ "id": "o1", "amount": 299 },
{ "id": "o2", "amount": 599 }
]
}
无需预定义 Schema，字段随时扩展
嵌套数据一次读取，无需 JOIN
跨文档关联查询较弱
典型场景：
用户画像
CMS 内容
商品目录
配置中心
数据由节点和边组成，专门表达实体之间的复杂关系网络。
张三 —关注→ 李四
李四 —关注→ 王五
张三 —购买→ iPhone
王五 —购买→ iPhone
多跳关系查询极快（朋友的朋友）
关系本身可以携带属性
不擅长大规模聚合统计
典型场景：
社交网络
推荐系统
知识图谱
欺诈检测
以时间戳为主轴，针对按时间顺序写入、按时间范围查询的场景深度优化。
{{ row.ts }}
{{ row.device }}
{{ row.cpu }}%
{{ row.mem }}GB
写入吞吐极高（百万点/秒）
内置降采样、自动过期策略
不支持复杂关联查询
典型场景：
服务器监控
IoT 传感器
金融行情
日志分析
将文本、图片等非结构化数据转为高维向量，通过计算向量距离实现语义相似度搜索。
查询："好吃的日料"
→ Embedding →
[0.82, 0.15, 0.91, ...]
{{ (r.score * 100).toFixed(0) }}%
{{ r.text }}
语义搜索，理解"意思"而非关键词
支持多模态（文本、图片、音频）
向量生成依赖 Embedding 模型质量
典型场景：
RAG 检索增强
以图搜图
语义搜索
推荐系统
💡
选型原则：没有万能数据库。关系型（MySQL/PostgreSQL）仍是大多数业务的基石，但当数据形态明确偏向文档、图、时序或向量时，选择专用模型能获得数量级的性能提升。