Files
markbase/docs/DATABASE_EVALUATION.md
Warren 1300a4e223
Some checks failed
Test / test (push) Has been cancelled
Test / build (push) Has been cancelled
MarkBase架构升级:Multi-Volume Virtual Tree + Dual-View Management + Git Remote修正
核心功能:
-  Categories/Series双视图管理(category_view.rs + import_markdown.rs)
-  FUSE Multi-Volume支持(tree_type参数)
-  SSH/SFTP/SCP/rsync协议完整实现(4042行)
-  NFS/SMB Module Phase 1-3完成
-  Archive Module Phase 1-4完成(2916行)
-  Download Center API完整实现
-  S3兼容API实现(560行)

Git配置修正:
-  删除错误origin(gitea.momentry.ddns.net)
-  删除m5max128(指向机器名)
-  设置origin = m5max128gitea.momentry.ddns.net/admin/markbase
-  设置m4minigitea = m4minigitea.momentry.ddns.net/warren/markbase

数据清理:
-  删除38个临时SQLite(保留accusys.sqlite、demo.sqlite)
-  删除.bak、test_*.bin、调试脚本等临时文件
-  删除临时目录(build/、download files/、raid_test/等)
-  更新.gitignore排除临时文件

架构优化:
- 52个文件修改,2434行新增,4739行删除
- Workspace成员整合(16个crate)
- 数据库状态:accusys.sqlite保留(主demo测试)

远程同步:
-  准备推送到m5max128gitea(远程Gitea)
-  准备推送到m4minigitea(本地Gitea)
2026-06-12 12:59:54 +08:00

998 lines
27 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# MDC 数据库深度评估报告
**评估日期:** 2026-05-29
**评估对象:** SQLite vs RocksDB vs sfsDb
**评估目标:** MarkBase Data Core (MDC) 核心数据库选型
---
## 一、评估背景
### 1.1 MarkBase 当前架构
**现有数据库:** SQLite (rusqlite 0.32)
**数据库文件:**
- `warren.sqlite` - 13MB (12,660 nodes)
- `demo.sqlite` - 64KB (50 nodes)
- `momentry.sqlite` - 64KB
**核心表结构:**
```sql
-- 文件注册表
CREATE TABLE file_registry (
file_uuid TEXT PRIMARY KEY,
sha256 TEXT,
file_size INTEGER,
mime_type TEXT,
registered_at INTEGER
);
-- 文件节点表
CREATE TABLE file_nodes (
node_id TEXT PRIMARY KEY,
label TEXT NOT NULL,
aliases_json TEXT,
file_uuid TEXT,
sha256 TEXT,
parent_id TEXT,
children_json TEXT,
node_type TEXT NOT NULL,
icon TEXT,
color TEXT,
bg_color TEXT,
file_size INTEGER,
registered_at INTEGER,
created_at INTEGER,
updated_at INTEGER,
sort_order INTEGER
);
-- 文件位置表
CREATE TABLE file_locations (
location_id INTEGER PRIMARY KEY AUTOINCREMENT,
file_uuid TEXT NOT NULL,
storage_tier TEXT NOT NULL,
storage_path TEXT NOT NULL,
is_primary INTEGER DEFAULT 0,
created_at INTEGER,
FOREIGN KEY (file_uuid) REFERENCES file_registry(file_uuid)
);
```
**当前使用场景:**
- 文件树管理 (CRUD operations)
- 文件元数据存储
- 位置追踪 (四层存储系统)
- SFTPGo 用户同步
- 认证系统 (auth.sqlite)
### 1.2 MarkBaseFS 架构需求
**Frame Index Table 结构:**
```sql
CREATE TABLE frame_records (
frame_id TEXT PRIMARY KEY,
video_id TEXT NOT NULL,
frame_file TEXT NOT NULL,
frame_size INTEGER,
frame_checksum TEXT,
storage_tier TEXT DEFAULT 'nvme',
storage_path TEXT,
created_at INTEGER,
updated_at INTEGER,
accessed_at INTEGER,
lock_status INTEGER DEFAULT 0,
lock_owner TEXT
);
```
**预期数据规模:**
- **当前:** 12,660 nodes (13MB)
- **短期目标:** 100,000+ nodes (100MB+)
- **长期目标:** 1,000,000+ nodes (1GB+)
**性能要求:**
- **FUSE 读取:** 650+ MB/s (C POC v15 已达成)
- **并发访问:** 10 users × 600 MB/s
- **查询延迟:** < 10ms (metadata lookup)
- **写入吞吐:** > 10,000 nodes/sec (批量导入)
---
## 二、数据库技术深度分析
### 2.1 SQLite
#### 2.1.1 技术特性
**架构设计:**
- **类型:** Embedded Relational Database (RDBMS)
- **存储模型:** B-Tree based row storage
- **事务模型:** ACID compliant, MVCC (Multi-Version Concurrency Control)
- **并发模型:** Multiple readers, single writer (WAL mode)
**存储引擎:**
```
SQLite Internal Structure:
┌─────────────────────────────────┐
│ B-Tree Pages (File Nodes) │
├─────────────────────────────────┤
│ B-Tree Pages (File Registry) │
├─────────────────────────────────┤
│ B-Tree Pages (File Locations) │
├─────────────────────────────────┤
│ WAL (Write-Ahead Log) │
├─────────────────────────────────┤
│ Free Pages │
└─────────────────────────────────┘
```
**Rust 生态支持:**
- `rusqlite` - 0.32 (成熟稳定)
- `diesel` - ORM support
- `sqlx` - Async support
- 文档完善,社区活跃
#### 2.1.2 性能特性
**读取性能:**
```rust
// 索引查询
SELECT * FROM file_nodes WHERE node_id = ?;
// 性能O(log n) B-Tree lookup
// 实测:< 1ms for 12K nodes
```
**写入性能:**
```rust
// 批量插入
INSERT INTO file_nodes (...) VALUES (...);
// 性能:
// - 每秒 ~5,000 rows (single transaction)
// - 每秒 ~50,000 rows (batch transaction)
// 实测14243 nodes/sec (scan.rs)
```
**并发性能:**
```
SQLite WAL Mode Concurrency:
┌─────────────────────────────────────┐
│ Reader 1 ──┐ │
│ Reader 2 ──┤ │
│ Reader 3 ──┼──> Shared Memory (WAL) │
│ Reader 4 ──┤ │
│ Reader N ──┘ │
├─────────────────────────────────────┤
│ Writer ────> Exclusive Lock │
└─────────────────────────────────────┘
限制:同时只能有 1 个 writer
优势:多个 reader 可以并发
```
#### 2.1.3 优缺点分析
**优点:**
**成熟稳定** - 20+ 年历史,广泛应用于生产环境
**零配置** - 无需服务器进程,直接文件操作
**ACID 保证** - 完整的事务支持
**SQL 支持** - 标准 SQL复杂查询支持
**Rust 生态完善** - rusqlite, diesel, sqlx
**调试友好** - SQLite Browser, CLI 工具
**跨平台** - macOS/Linux/Windows 全支持
**体积小** - 编译后 ~500KB
**缺点:**
**单点写入** - 只能有一个 writer (WAL mode)
**扩展性差** - 无法分布式扩展
**大文件性能** - >100GB 后性能下降
**Schema 变更** - ALTER TABLE 代价高
**无内置压缩** - 需要外部压缩
#### 2.1.4 MarkBase 适用性评估
**当前适用性:** ⭐⭐⭐⭐⭐ (5/5)
**适用场景:**
- ✅ 文件树管理 (node_id 查询)
- ✅ 元数据存储 (sha256, file_size)
- ✅ 位置追踪 (storage_tier, storage_path)
- ✅ 用户认证 (auth.sqlite)
- ✅ SFTPGo 同步 (sftpgo_users)
**不适用场景:**
- ❌ 高并发写入 (10 users 同时导入)
- ❌ 大规模数据 (>100GB)
- ❌ 分布式部署 (多服务器)
---
### 2.2 RocksDB
#### 2.2.1 技术特性
**架构设计:**
- **类型:** Embedded Key-Value Store (LSM-Tree)
- **存储模型:** Log-Structured Merge-Tree (LSM-Tree)
- **事务模型:** ACID (optional), Snapshot Isolation
- **并发模型:** Multiple readers and writers
**LSM-Tree 结构:**
```
RocksDB Internal Structure:
┌─────────────────────────────────┐
│ MemTable (In-Memory) │ ← Writes
├─────────────────────────────────┤
│ Immutable MemTables │
├─────────────────────────────────┤
│ Level 0 SST Files (Unsorted) │
├─────────────────────────────────┤
│ Level 1 SST Files (Sorted) │
├─────────────────────────────────┤
│ Level 2 SST Files (Sorted) │
├─────────────────────────────────┤
│ Level N SST Files (Sorted) │
└─────────────────────────────────┘
Compaction (Background)
```
**核心组件:**
- **MemTable:** 内存写入缓冲 (skiplist)
- **SST Files:** 磁盘存储文件 (sorted string tables)
- **WAL:** Write-Ahead Log (crash recovery)
- **Compaction:** 后台压缩合并 (空间回收)
- **Block Cache:** 读取缓存 (LRU)
**Rust 生态支持:**
- `rocksdb` - 0.22 (官方绑定)
- `rust-rocksdb` - 社区维护
- 配置复杂,学习曲线陡峭
#### 2.2.2 性能特性
**写入性能:**
```rust
// RocksDB 写入流程
Write MemTable Immutable MemTable L0 SST L1 SST ... Ln SST
- (append-only)
- (WriteBatch)
- ()
100,000+ writes/sec
```
**读取性能:**
```rust
// RocksDB 读取流程
Read Block Cache MemTable Immutable MemTable L0 L1 ... Ln
- (L0 unsorted)
- Compaction (read amplification)
< 5ms for 1M keys (with cache)
```
**压缩影响:**
```
Compaction Overhead:
┌─────────────────────────────────┐
│ Write Amplification: 10-50x │ ← 写入放大
│ Space Amplification: 1.1-1.5x │ ← 空间放大
│ Read Amplification: 10-100x │ ← 读取放大
└─────────────────────────────────┘
解决方案:
- 配置合理的 compaction 策略
- 使用 SSD (避免 HDD seek)
- 调整 block cache 大小
```
#### 2.2.3 优缺点分析
**优点:**
**高写入吞吐** - 100K+ writes/sec
**并发写入** - 多个 writer 同时工作
**压缩支持** - 内置 Snappy, Zlib, LZ4
**快照隔离** - 一致性读取
**增量备份** - Incremental backup
**Column Families** - 类似表的概念
**生产验证** - Facebook, LinkedIn, Uber
**缺点:**
**配置复杂** - 200+ 配置参数
**学习曲线陡** - LSM-Tree 原理复杂
**Compaction 开销** - CPU/IO 密集
**空间放大** - 1.1-1.5x 额外空间
**读取性能波动** - Compaction 期间下降
**Rust 绑定不稳定** - 版本更新慢
#### 2.2.4 MarkBase 适用性评估
**当前适用性:** ⭐⭐⭐ (3/5)
**适用场景:**
- ✅ 高并发写入 (10 users 同时导入)
- ✅ 大规模数据 (1M+ nodes)
- ✅ 需要压缩 (节省存储空间)
- ✅ 写入密集型应用
**不适用场景:**
- ❌ 简单查询 (SQLite 更易用)
- ❌ 小规模数据 (<10GB, SQLite 足够)
- ❌ 需要复杂 SQL (RocksDB 无 SQL)
- ❌ 团队不熟悉 LSM-Tree
---
### 2.3 sfsDb (假设性评估)
**注意:** sfsDb 在 Rust 生态中不存在成熟实现,以下评估基于类似项目推断。
#### 2.3.1 可能的技术方向
**选项 A: Sans-IO Database**
- **概念:** Network-less database design
- **优势:** 可移植性强,适合 FUSE/FSKit
- **劣势:** 性能可能不如原生实现
**选项 B: Simple File System Database**
- **概念:** 基于文件系统的简单存储
- **优势:** 利用 OS 缓存,简单直接
- **劣势:** 缺乏事务支持
**选项 C: Sled (实际存在的 Rust DB)**
- **类型:** Embedded KV Store (B-Tree)
- **成熟度:** 0.34 (stable)
- **性能:** 读取快,写入中等
#### 2.3.2 实际替代品评估
**Sled (推荐替代品)**
**技术特性:**
- **类型:** Embedded Key-Value Store (B-Tree + MVCC)
- **存储模型:** B-Tree with copy-on-write
- **事务模型:** ACID, MVCC
- **并发模型:** Multiple readers and writers
**性能特性:**
```rust
// Sled 写入
sled::Db::insert() B-Tree node Disk page
- ~50,000 ops/sec
- ~100,000 ops/sec
- ~10,000 tx/sec
```
**优缺点:**
**纯 Rust** - 无 FFI, 内存安全
**简单易用** - API 类似 HashMap
**MVCC** - 无锁读取
**跨平台** - 100% Rust
**性能不如 RocksDB** - 写入吞吐较低
**社区较小** - 维护者少
**文档较少** - 学习资源有限
#### 2.3.3 MarkBase 适用性评估
**当前适用性:** ⭐⭐⭐⭐ (4/5)
**适用场景:**
- ✅ 纯 Rust 项目 (无 FFI)
- ✅ 简单 KV 存储 (node_id → node_data)
- ✅ 需要并发读取 (MVCC)
- ✅ 学习曲线低
**不适用场景:**
- ❌ 需要复杂查询 (无 SQL)
- ❌ 需要压缩 (无内置压缩)
- ❌ 大规模写入密集 (性能不如 RocksDB)
---
## 三、性能基准测试
### 3.1 测试环境
**硬件:**
- CPU: Apple M4 (8 cores)
- RAM: 16GB
- SSD: NVMe 2TB
- OS: macOS 26.4.1
**测试数据:**
- 节点数12,660 nodes
- 数据大小13MB (SQLite)
- 索引node_id (PRIMARY KEY)
### 3.2 测试场景
#### 场景 1: 批量导入 (Write Throughput)
**测试代码:**
```rust
// 插入 12,660 nodes
for node in nodes {
db.insert(node)?;
}
```
**预期结果:**
| 数据库 | 插入速度 | 事务支持 | 备注 |
|--------|----------|----------|------|
| SQLite | 14,243 nodes/sec | ✅ ACID | 批量事务 |
| RocksDB | 50,000+ nodes/sec | ✅ ACID | WriteBatch |
| Sled | 30,000 nodes/sec | ✅ ACID | 单线程 |
#### 场景 2: 单点查询 (Read Latency)
**测试代码:**
```rust
// 查询 10,000 次 node_id
for i in 0..10000 {
let node = db.get(node_id)?;
}
```
**预期结果:**
| 数据库 | 查询延迟 | 缓存命中 | 备注 |
|--------|----------|----------|------|
| SQLite | < 1ms | N/A | B-Tree |
| RocksDB | < 5ms | 90%+ | Block Cache |
| Sled | < 2ms | N/A | B-Tree |
#### 场景 3: 并发读取 (Concurrent Reads)
**测试代码:**
```rust
// 10 个线程同时读取
let handles: Vec<_> = (0..10)
.map(|_| {
thread::spawn(|| {
for _ in 0..1000 {
db.get(node_id)?;
}
})
})
.collect();
```
**预期结果:**
| 数据库 | 并发读取 | CPU 利用率 | 备注 |
|--------|----------|------------|------|
| SQLite | 10,000+ ops/sec | 多核 | WAL mode |
| RocksDB | 50,000+ ops/sec | 多核 | Block Cache |
| Sled | 20,000+ ops/sec | 多核 | MVCC |
#### 场景 4: 并发写入 (Concurrent Writes)
**测试代码:**
```rust
// 10 个线程同时写入
let handles: Vec<_> = (0..10)
.map(|i| {
thread::spawn(move || {
for j in 0..100 {
db.insert(node)?;
}
})
})
.collect();
```
**预期结果:**
| 数据库 | 并发写入 | 冲突处理 | 备注 |
|--------|----------|----------|------|
| SQLite | ❌ 不支持 | 单 writer | WAL mode |
| RocksDB | ✅ 支持 | MVCC | 多 writer |
| Sled | ✅ 支持 | MVCC | 多 writer |
#### 场景 5: 文件大小 (Disk Usage)
**测试数据:**
- 12,660 nodes
- 平均节点大小1KB
**预期结果:**
| 数据库 | 文件大小 | 压缩 | 备注 |
|--------|----------|------|------|
| SQLite | 13MB | ❌ 无 | B-Tree |
| RocksDB | 8-10MB | ✅ Snappy | LSM-Tree |
| Sled | 15MB | ❌ 无 | B-Tree |
---
## 四、MarkBase 需求匹配度分析
### 4.1 功能需求
| 需求 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **文件树管理** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **元数据查询** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **位置追踪** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **用户认证** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **SFTPGo 同步** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
**结论:** SQLite 在功能需求上完全匹配RocksDB/Sled 需要重新设计数据模型。
### 4.2 性能需求
| 需求 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **FUSE 读取** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| **批量导入** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| **并发读取** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **并发写入** | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| **大规模数据** | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
**结论:** SQLite 在读取场景表现优异RocksDB 在写入密集场景有优势。
### 4.3 运维需求
| 需求 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **部署复杂度** | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| **监控工具** | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **备份恢复** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **跨平台** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| **学习曲线** | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
**结论:** SQLite 运维成本最低RocksDB 需要专业知识。
### 4.4 开发效率
| 需求 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **Rust 生态** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| **文档完善** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| **调试工具** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **社区支持** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| **开发速度** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
**结论:** SQLite 开发效率最高RocksDB 需要更多学习时间。
---
## 五、迁移成本评估
### 5.1 SQLite → RocksDB 迁移
**数据模型转换:**
**SQLite (Relational):**
```sql
CREATE TABLE file_nodes (
node_id TEXT PRIMARY KEY,
label TEXT NOT NULL,
parent_id TEXT,
node_type TEXT NOT NULL,
file_size INTEGER,
sha256 TEXT
);
```
**RocksDB (Key-Value):**
```rust
// Column Family: file_nodes
// Key: node_id
// Value: JSON or Protobuf
{
"node_id": "abc123",
"label": "test.mp4",
"parent_id": "parent123",
"node_type": "file",
"file_size": 1024,
"sha256": "..."
}
```
**迁移步骤:**
1. **Schema 设计** (2天)
- 定义 Column Families
- 设计 Key 命名规则
- 确定序列化格式 (JSON/Protobuf)
2. **数据导出** (1天)
```bash
sqlite3 warren.sqlite "SELECT * FROM file_nodes" > export.csv
```
3. **数据导入** (2天)
```rust
// 逐行导入到 RocksDB
let db = RocksDB::open("warren.rocksdb")?;
for row in csv::Reader::from_reader(file) {
db.put_cf(cf_file_nodes, row.node_id, row.to_json())?;
}
```
4. **代码重写** (5天)
- 重写 filetree/mod.rs (553行)
- 重写 server.rs 数据库部分
- 重写 scan.rs 批量导入
5. **测试验证** (3天)
- 功能测试 (7个测试)
- 性能测试 (5个场景)
- 并发测试
**总工作量:** 13天
**风险等级:** ⚠️ 高 (Schema 变更风险)
### 5.2 SQLite → Sled 迁移
**数据模型转换:**
**Sled (Key-Value):**
```rust
// Tree: file_nodes
// Key: node_id
// Value: Vec<u8> (MessagePack)
let tree = db.open_tree("file_nodes")?;
tree.insert(node_id, node_to_bytes(node))?;
```
**迁移步骤:**
1. **Schema 设计** (1天)
- 定义 Tree 名称
- 选择序列化格式 (MessagePack)
2. **数据导出** (1天)
3. **数据导入** (1天)
```rust
let db = sled::open("warren.sled")?;
let tree = db.open_tree("file_nodes")?;
for row in export {
tree.insert(row.node_id.as_bytes(), to_msgpack(row))?;
}
```
4. **代码重写** (3天)
- 重写 filetree/mod.rs
- 调整 API 调用
5. **测试验证** (2天)
**总工作量:** 8天
**风险等级:** ⚠️ 中 (API 变更风险)
### 5.3 保持 SQLite 优化
**优化方向:**
1. **WAL Mode 优化** (1天)
```sql
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA cache_size=10000;
PRAGMA temp_store=MEMORY;
```
2. **索引优化** (1天)
```sql
CREATE INDEX idx_parent_id ON file_nodes(parent_id);
CREATE INDEX idx_sha256 ON file_nodes(sha256);
CREATE INDEX idx_file_uuid ON file_nodes(file_uuid);
```
3. **连接池优化** (1天)
```rust
use r2d2_sqlite::SqliteConnectionManager;
let pool = r2d2::Pool::new(manager)?;
```
4. **批量插入优化** (1天)
```rust
let tx = conn.transaction()?;
let stmt = tx.prepare_cached(INSERT_SQL)?;
for chunk in nodes.chunks(1000) {
for node in chunk {
stmt.execute(params![...])?;
}
}
tx.commit()?;
```
**总工作量:** 4天
**风险等级:** ✅ 低 (兼容现有代码)
---
## 六、综合评分与建议
### 6.1 综合评分
| 维度 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **功能匹配度** | 95/100 | 75/100 | 85/100 |
| **性能匹配度** | 85/100 | 95/100 | 80/100 |
| **运维成本** | 95/100 | 60/100 | 85/100 |
| **开发效率** | 95/100 | 65/100 | 80/100 |
| **迁移成本** | 100/100 | 40/100 | 60/100 |
| **社区支持** | 100/100 | 85/100 | 70/100 |
| **长期维护** | 95/100 | 90/100 | 75/100 |
| **总分** | **665/700** | **510/700** | **535/700** |
### 6.2 决策建议
#### 短期建议 (0-6个月)
**推荐SQLite + 优化** ⭐⭐⭐⭐⭐
**理由:**
1. **功能完全匹配** - 文件树、元数据、位置追踪、认证
2. **性能足够** - 14,243 nodes/sec 导入速度已满足需求
3. **迁移成本最低** - 无需重写代码
4. **运维成本最低** - 无需专业知识
**优化计划:**
- 启用 WAL mode (1天)
- 添加索引 (1天)
- 连接池优化 (1天)
- 批量插入优化 (1天)
#### 中期建议 (6-12个月)
**评估触发条件:**
- 数据规模 > 100GB
- 并发用户 > 10
- 写入吞吐需求 > 50,000 ops/sec
**选项 1: SQLite + Sharding**
```
方案:按用户分库
├── data/users/warren.sqlite
├── data/users/demo.sqlite
├── data/users/momentry.sqlite
└── data/users/userN.sqlite
优势:
- 保持 SQLite 优势
- 横向扩展 (每用户一个库)
- 零学习成本
劣势:
- 跨用户查询复杂
- 需要路由层
```
**选项 2: RocksDB + 数据模型重构**
```
方案Column Family 设计
├── Column Family: file_nodes
├── Column Family: file_registry
├── Column Family: file_locations
└── Column Family: user_auth
优势:
- 高并发写入
- 内置压缩
- 生产验证
劣势:
- 高迁移成本 (13天)
- 运维复杂
```
#### 长期建议 (12+ months)
**方案:混合架构**
```
MarkBase Hybrid Database Architecture:
┌─────────────────────────────────────────────┐
│ Metadata Layer (SQLite) │
│ - file_nodes, file_registry │
│ - user_auth, sync_log │
│ - 需要复杂查询SQL 友好 │
└─────────────────────────────────────────────┘
↓ (pointer)
┌─────────────────────────────────────────────┐
│ Content Layer (RocksDB/Sled) │
│ - file_content_hash → storage_path │
│ - file_metadata_hash → metadata │
│ - 需要高并发读写KV 友好 │
└─────────────────────────────────────────────┘
↓ (pointer)
┌─────────────────────────────────────────────┐
│ Cache Layer (Redis/Sled) │
│ - hot_files_cache │
│ - LRU eviction │
│ - FUSE hot path optimization │
└─────────────────────────────────────────────┘
```
**优势:**
- 各层使用最优数据库
- 保持 SQLite 优势 (metadata)
- 增加 KV 优势 (content)
- 缓存层加速 FUSE
### 6.3 最终建议
**阶段 1 (当前 - 6个月):**
✅ **保持 SQLite + 优化**
- 启用 WAL mode
- 添加索引
- 连接池优化
- 批量插入优化
**阶段 2 (6-12个月):**
🔍 **评估数据规模和并发需求**
- 如果数据 < 100GB 且并发 < 10 users → 继续 SQLite
- 如果数据 > 100GB 或并发 > 10 users → 考虑 SQLite Sharding
**阶段 3 (12+ months):**
🚀 **混合架构**
- Metadata: SQLite (复杂查询)
- Content: RocksDB/Sled (高并发)
- Cache: Redis/Sled (FUSE hot path)
---
## 七、行动计划
### 7.1 立即行动 (本周)
**任务SQLite 优化**
```bash
# 1. 创建优化分支
git checkout -b feature/sqlite-optimization
# 2. 启用 WAL mode
# 修改 filetree/mod.rs: init_user_db()
# 3. 添加索引
# 修改 filetree/mod.rs: init_user_db()
# 4. 连接池优化
# 添加 r2d2 依赖
# 5. 批量插入优化
# 修改 scan.rs: insert_nodes()
# 6. 性能测试
cargo test --release
# 7. 合并主分支
git checkout main
git merge feature/sqlite-optimization
```
### 7.2 短期计划 (1个月)
**任务:监控和告警**
```rust
// 添加性能监控
pub struct DbMetrics {
pub query_latency: Histogram,
pub write_throughput: Counter,
pub db_size: Gauge,
pub connection_count: Gauge,
}
// 添加慢查询日志
if query_time > 100ms {
log::warn!("Slow query: {} took {}ms", sql, query_time);
}
// 添加数据库健康检查
pub fn health_check(conn: &Connection) -> Result<DbHealth> {
let page_count: i64 = conn.query_row("PRAGMA page_count", [], |r| r.get(0))?;
let page_size: i64 = conn.query_row("PRAGMA page_size", [], |r| r.get(0))?;
let db_size = page_count * page_size;
Ok(DbHealth {
db_size,
page_count,
page_size,
integrity_check: conn.execute("PRAGMA integrity_check", [])?,
})
}
```
### 7.3 中期计划 (6个月)
**任务Sharding 评估**
```rust
// 设计用户路由层
pub struct UserDbRouter {
base_path: PathBuf,
}
impl UserDbRouter {
pub fn get_db(&self, user_id: &str) -> Result<Connection> {
let db_path = self.base_path.join(format!("{}.sqlite", user_id));
Connection::open(db_path)
}
pub fn get_db_size(&self, user_id: &str) -> Result<u64> {
let db_path = self.base_path.join(format!("{}.sqlite", user_id));
let metadata = fs::metadata(db_path)?;
Ok(metadata.len())
}
}
// 监控触发条件
if db_size > 100 * 1024 * 1024 * 1024 { // 100GB
log::warn!("Database size exceeds 100GB, consider sharding");
}
if concurrent_users > 10 {
log::warn!("Concurrent users exceeds 10, consider sharding");
}
```
---
## 八、总结
### 8.1 核心结论
1. **SQLite 是当前最优选择**
- 功能匹配度95/100
- 性能匹配度85/100
- 迁移成本:最低 (4天优化 vs 13天迁移)
- 运维成本:最低 (零配置)
2. **RocksDB 适合未来扩展**
- 高并发写入场景 (>10 users 同时写入)
- 大规模数据场景 (>100GB)
- 需要压缩场景 (节省存储)
3. **Sled 是折中选择**
- 纯 Rust 实现 (无 FFI)
- 学习曲线低于 RocksDB
- 性能介于 SQLite 和 RocksDB 之间
### 8.2 关键指标对比
| 指标 | SQLite | RocksDB | Sled |
|------|--------|---------|------|
| **导入速度** | 14,243 nodes/sec | 50,000+ nodes/sec | 30,000 nodes/sec |
| **查询延迟** | < 1ms | < 5ms | < 2ms |
| **并发读取** | 10,000+ ops/sec | 50,000+ ops/sec | 20,000+ ops/sec |
| **并发写入** | ❌ 单 writer | ✅ 多 writer | ✅ 多 writer |
| **文件大小** | 13MB (12K nodes) | 8-10MB (压缩) | 15MB |
| **迁移成本** | 0天 | 13天 | 8天 |
| **学习曲线** | 1天 | 5天 | 2天 |
| **运维复杂度** | 低 | 高 | 中 |
### 8.3 决策矩阵
```
SQLite RocksDB Sled
功能需求匹配度 ✅ ⚠️ ✅
性能需求匹配度 ✅ ✅ ⚠️
运维成本匹配度 ✅ ⚠️ ✅
开发效率匹配度 ✅ ⚠️ ✅
迁移成本可接受度 ✅ ⚠️ ⚠️
长期维护可持续性 ✅ ✅ ⚠️
──────────────────────────────────────────
推荐度 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐
```
---
**评估结论:保持 SQLite + 优化,未来根据规模评估 Sharding 或混合架构。**
**报告完成日期:** 2026-05-29
**下次评估日期:** 2026-11-29 (6个月后)