关于 LevelDB的小总结：
LevelDB 和 SQLite 是两种不同类型的数据库:
1. LevelDB:
- 特点:
- NoSQL 数据库
- 键值(Key-Value)存储
- 由 Google 开发
- 数据按键排序存储
- 支持批量操作
- 简单的 Get/Put/Delete 接口
示例操作:
key1 -> value1
key2 -> value2
2. SQLite:
特点:
- 关系型数据库(SQL)
- 表格结构存储
- 支持 SQL 查询
- 支持事务
- 支持外键和索引
示例表:
CREATE TABLE users (
id INTEGER PRIMARY KEY,
name TEXT,
age INTEGER
);
3. 为什么 Chrome 选择 LevelDB:
性能好
简单高效
适合键值存储
内存占用小
适合浏览器环境
IndexedDB 的实现:Chrome: LevelDBFirefox: SQLiteSafari: SQLite
所以 Chrome 选择 LevelDB 是因为它:
- 更适合存储 Web 数据
- 性能更好
- 资源占用更少
- 更简单的数据模型
Chrome 确实在早期使用的是 SQLite。
这个改变发生在 2011 年左右。
具体历史：
Chrome 数据存储演变
│
├── 2008-2011: SQLite
│ └── 用于所有本地存储(历史记录、书签等)
│
├── 2011: 开始转向 LevelDB
│ ├── Google 发布 LevelDB
│ └── Chrome 逐步采用
│
└── 现在: LevelDB├── IndexedDB 后端存储├── 历史记录└── 其他浏览器数据但注意：
Chrome OS 仍然使用 SQLite 用于某些功能
某些特定功能可能仍在使用 SQLite
这个转换是渐进的过程
Chrome OS 使用 SQLite 的主要场景包括：
1. 系统功能：
- 系统设置数据库
- 用户账户信息
- 系统日志
- 系统更新记录
2.Android 应用支持：
Chrome OS
└── Android 子系统└── SQLite (Android 原生支持)├── 应用数据├── 内容提供者(Content Providers)└── 应用设置3.特定应用场景：
- 文件系统元数据
- 搜索索引
- 本地媒体库
- 系统备份数据4. 选择 SQLite 的原因：
- 需要复杂查询能力
- 需要事务支持
- 需要关系型数据结构
- 与 Android 生态系统兼容而浏览器相关的功能（如 IndexedDB）仍使用 LevelDB：
Chrome OS
├── 系统层 (SQLite)
│ └── 系统功能和设置
│
└── 浏览器层 (LevelDB)└── Web 存储和缓存Chrome/Chrome OS 存储引擎使用情况
│
├── SQLite 使用场景
│ ├── Chrome OS 系统层
│ │ ├── 系统设置
│ │ ├── 用户账户管理
│ │ ├── 系统日志
│ │ └── 系统更新记录
│ │
│ ├── Android 应用支持
│ │ ├── Android 应用数据
│ │ └── Content Providers
│ │
│ └── 其他特定功能
│ ├── 文件系统元数据
│ └── 本地媒体库索引
│
└── LevelDB 使用场景├── 浏览器核心功能│ ├── IndexedDB 存储│ ├── 浏览历史│ ├── Cookie 存储│ └── 书签数据│├── Web 应用数据│ ├── Service Worker 缓存│ ├── Web Storage│ └── Application Cache│└── 扩展相关├── 扩展数据存储├── 扩展设置└── 扩展状态夜深啦,晚安 😴，🍀
