关于 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: LevelDB
	Firefox: SQLite
	Safari: 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
    │
    └── 扩展相关
        ├── 扩展数据存储
        ├── 扩展设置
        └── 扩展状态

夜深啦,晚安 😴，🍀