【LevelDB 和 Sqlite】

关于 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.特定应用场景：
- 文件系统元数据
- 搜索索引
- 本地媒体库
- 系统备份数据
1. 选择 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
│
└── 扩展相关
├── 扩展数据存储
├── 扩展设置
└── 扩展状态

夜深啦,晚安 😴，🍀