SQLite 的适当用途

SQLite 不能直接与客户端/服务器 SQL 数据库引擎（如 MySQL、Oracle、PostgreSQL 或 SQL Server）相比较，因为 SQLite 试图解决不同的问题。

客户端/服务器 SQL 数据库引擎努力实现企业数据的共享存储库。他们强调可扩展性、并发性、集中化和控制。SQLite 致力于为单个应用程序和设备提供本地数据存储。SQLite 强调经济、效率、可靠性、独立性和简单性。

SQLite 不与客户端/服务器数据库竞争。SQLite 与fopen()竞争。

SQLite 运行良好的情况

• 嵌入式设备和物联网

  因为 SQLite 数据库不需要管理，所以它适用于必须在没有专家人工支持的情况下运行的设备。SQLite 非常适合用于手机、机顶盒、电视机、游戏机、相机、手表、厨房电器、恒温器、汽车、机床、飞机、遥感器、无人机、医疗设备和机器人：“互联网”东西的”。

  客户端/服务器数据库引擎被设计为位于网络核心的一个精心维护的数据中心内。SQLite 也在那里工作，但 SQLite 也在网络边缘蓬勃发展，在为应用程序提供快速可靠的数据服务的同时自我保护，否则这些应用程序将具有不可靠的连接。

• 申请文件格式

  SQLite 通常用作桌面应用程序的磁盘文件格式，例如版本控制系统、财务分析工具、媒体编目和编辑套件、CAD 包、记录保存程序等。传统的文件/打开操作调用 sqlite3_open() 附加到数据库文件。更新会随着应用程序内容的修改而自动发生，因此文件/保存菜单选项变得多余。File/Save_As 菜单选项可以使用备份 API实现。

  这种方法有很多好处，包括提高性能、降低成本和复杂性以及提高可靠性。有关详细信息，请参阅技术说明 “aff_short.html”、 “appfileformat.html”和 “fasterthanfs.html”。这个用例与下面的数据传输格式和 数据容器用例 密切相关 。

• 网站

  SQLite 非常适合作为大多数中低流量网站（也就是说，大多数网站）的数据库引擎。SQLite 可以处理的网络流量取决于网站使用其数据库的程度。一般来说，任何每天点击次数少于 100K 的站点都应该可以正常使用 SQLite。每天 10 万次点击的数字是保守估计，并非硬性上限。SQLite 已被证明可以处理 10 倍的流量。

  SQLite 网站 ( https://www.sqlite.org/ ) 当然使用 SQLite 本身，截至撰写本文时（2015 年）它每天处理大约 400K 到 500K 的 HTTP 请求，其中大约 15-20% 是动态的接触数据库的页面。每个网页的动态内容使用大约 200 个 SQL 语句。此设置在与其他 23 台共享物理服务器的单个 VM 上运行，但大多数时间仍将平均负载保持在 0.1 以下。

• 数据分析

  了解 SQL 的人可以使用 sqlite3 命令行 shell（或各种第三方 SQLite 访问程序）来分析大型数据集。可以从 CSV 文件导入原始数据，然后可以对数据进行切片和切块以生成无数的摘要报告。更复杂的分析可以使用 Tcl 或 Python（两者都内置了 SQLite）或 R 或​​其他语言使用现成的适配器编写的简单脚本来完成。可能的用途包括网站日志分析、体育统计分析、编程指标汇编和实验结果分析。许多生物信息学研究人员就是这样使用 SQLite 的。

  当然，企业客户端/服务器数据库也可以做同样的事情。SQLite 的优势在于它更易于安装和使用，并且生成的数据库是单个文件，可以写入 USB 记忆棒或通过电子邮件发送给同事。

• 企业数据缓存

  许多应用程序使用 SQLite 作为企业 RDBMS 相关内容的缓存。这减少了延迟，因为现在大多数查询都是针对本地缓存发生的，并且避免了网络往返。它还减少了网络和中央数据库服务器上的负载。在许多情况下，这意味着客户端应用程序可以在网络中断期间继续运行。

• 服务器端数据库

  系统设计人员报告成功使用 SQLite 作为在数据中心运行的服务器应用程序的数据存储，或者换句话说，使用 SQLite 作为特定于应用程序的数据库服务器的底层存储引擎。

  使用这种模式，整个系统仍然是客户端/服务器：客户端向服务器发送请求并通过网络获得回复。但是，客户端请求和服务器响应不是发送通用 SQL 并取回原始表内容，而是高级的和特定于应用程序的。服务器将请求转换为多个 SQL 查询，收集结果，进行后处理、过滤和分析，然后构建仅包含基本信息的高级回复。

  开发人员报告说，在这种情况下，SQLite 通常比客户端/服务器 SQL 数据库引擎更快。数据库请求由服务器序列化，因此并发不是问题。“数据库分片”也提高了并发性：为不同的子域使用单独的数据库文件。例如，服务器可能为每个用户提供一个单独的 SQLite 数据库，以便服务器可以处理成百上千个并发连接，但每个 SQLite 数据库仅供一个连接使用。

• 数据传输格式

  由于 SQLite 数据库是一个具有 明确定义的跨平台格式的紧凑文件，因此它通常用作将内容从一个系统传输到另一个系统的容器。发送方将内容收集到一个 SQLite 数据库文件中，将该文件传输给接收方，然后接收方根据需要使用 SQL 提取内容。

  SQLite 数据库有助于系统之间的数据传输，即使端点具有不同的字大小和/或字节顺序。数据可以是大型二进制 blob、文本和小型数字或布尔值的复杂组合。可以通过添加新表和/或列轻松扩展数据格式，而不会破坏传统接收器。SQL 查询语言意味着接收方不需要一次解析整个传输，而是可以根据需要查询接收到的内容。数据格式是“透明的”，因为它可以使用来自多个供应商的各种普遍可用的开源工具轻松解码以供人类查看。

• 文件存档和/或数据容器

  SQLite Archive 的想法展示了如何使用 SQLite 作为 ZIP 存档或 Tarball 的替代品。存储在 SQLite 中的文件存档仅比等效的 ZIP 存档稍大，在某些情况下实际上更小。SQLite 存档具有增量和原子更新以及存储更丰富的元数据的能力。

  除了传统的 tarball 和 ZIP 存档之外，Fossil 2.5 版及更高版本还提供 SQLite 存档文件作为下载格式。sqlite3.exe 命令行 shell版本 3.22.0 及更高版本将使用.archive 命令创建、列出或解压缩 SQL 归档 。

  SQLite 是一个很好的解决方案，适用于任何需要将各种内容捆绑到一个自包含和自描述包中以通过网络传输的情况。内容以 定义明确、跨平台且稳定的文件格式进行编码。编码效率高，接收者可以提取内容的小子集，而无需读取和解析整个文件。

  SQL 存档可用作向许多客户端广播的软件或内容更新的分发格式。这个想法的变体被用于，例如，将电视节目指南传输到机顶盒，并通过无线方式向车辆导航系统发送更新。

• 临时磁盘文件的替换

  许多程序使用 fopen()、 fread()和 fwrite()来创建和管理本地格式的数据文件。SQLite 可以很好地替代这些临时数据文件。与直觉相反，SQLite 可以比文件系统更快地 读取和写入磁盘内容。

• 内部或临时数据库

  对于有大量数据必须以不同方式筛选和排序的程序，将数据加载到内存中的 SQLite 数据库并使用带有连接和 ORDER BY 子句的查询来提取数据通常更容易和更快需要的形式和顺序，而不是尝试手动编写相同的操作代码。以这种方式在内部使用 SQL 数据库还为程序提供了更大的灵活性，因为可以添加新的列和索引而无需重新编码每个查询。

• 在演示或测试期间替代企业数据库

  客户端应用程序通常使用允许连接到各种 SQL 数据库引擎的通用数据库接口。将 SQLite 包含在支持的数据库组合中并将 SQLite 引擎静态链接到客户端是很有意义的。这样，客户端程序可以与 SQLite 数据文件一起独立使用以进行测试或演示。

• 教育和培训

  因为它易于设置和使用（安装很简单：只需将sqlite3或sqlite3.exe可执行文件复制到目标机器并运行它）SQLite 是一个很好的用于教授 SQL 的数据库引擎。学生可以轻松地创建任意数量的数据库，并可以将数据库通过电子邮件发送给教师进行评论或评分。对于有兴趣研究 RDBMS 的实现方式的更高级的学生，模块化、注释良好且文档化的 SQLite 代码可以作为良好的基础。

• 实验性 SQL 语言扩展

  SQLite 的简单、模块化设计使其成为对新的、实验性数据库语言功能或想法进行原型设计的良好平台。

客户端/服务器 RDBMS 可能工作得更好的情况

• 客户端/服务器应用程序

  如果有许多客户端程序通过网络向同一个数据库发送 SQL，则使用客户端/服务器数据库引擎而不是 SQLite。SQLite 将在网络文件系统上工作，但由于与大多数网络文件系统相关的延迟，性能不会很好。此外，文件锁定逻辑在许多网络文件系统实现（在 Unix 和 Windows 上）中存在错误。如果文件锁定无法正常工作，两个或多个客户端可能会同时尝试修改同一数据库的同一部分，从而导致损坏。因为这个问题是由底层文件系统实现中的错误引起的，所以 SQLite 无法阻止它。

  一个好的经验法则是避免在直接访问同一个数据库（没有中间应用程序服务器）并且同时从网络上的多台计算机访问的情况下使用 SQLite。

• 高流量网站

  SQLite 通常可以很好地作为网站的数据库后端。但是如果网站是写入密集型的或者非常繁忙以至于需要多台服务器，那么可以考虑使用企业级客户端/服务器数据库引擎而不是 SQLite。

• 非常大的数据集

  SQLite 数据库的大小限制为 281 TB（2 ⁴⁸字节，256 tibibytes）。即使它可以处理更大的数据库，SQLite 也会将整个数据库存储在一个磁盘文件中，并且许多文件系统将文件的最大大小限制为小于此值。因此，如果您正在考虑这种规模的数据库，最好考虑使用客户端/服务器数据库引擎，该引擎将其内容分布在多个磁盘文件中，甚至可能分布在多个卷中。

• 高并发

  SQLite 支持无限数量的并发读者，但它在任何时刻都只允许一个写者。对于许多情况，这不是问题。作家排队。每个应用程序快速处理其数据库并继续运行，并且没有锁持续超过几十毫秒。但是有些应用程序需要更多的并发性，这些应用程序可能需要寻求不同的解决方案。

选择合适的数据库引擎的清单

1. 数据是否通过网络与应用程序分离？→ 选择客户端/服务器

   关系数据库引擎充当减少带宽的数据过滤器。因此最好将数据库引擎和数据保持在同一个物理设备上，这样高带宽的引擎到磁盘的链接就不必遍历网络，只需要低带宽的应用程序到引擎的链接。

   但是 SQLite 是内置在应用程序中的。因此，如果数据位于与应用程序不同的设备上，则需要更高带宽的引擎到磁盘链接跨网络。这可行，但不是最理想的。因此，当数据位于与应用程序不同的设备上时，通常最好选择客户端/服务器数据库引擎。

   注意事项： 在此规则中，“应用程序”是指发出 SQL 语句的代码。如果“应用程序”是一个应用程序服务器，并且如果内容与应用程序服务器驻留在同一台物理机器上，那么 SQLite 可能仍然适用，即使最终用户在另一个网络跃点之外。

2. 许多并发作家？→ 选择客户端/服务器

   如果许多线程和/或进程需要同时写入数据库（并且它们不能排队轮流），那么最好选择支持该功能的数据库引擎，这始终意味着客户端/服务器数据库引擎。

   SQLite 一次只支持每个数据库文件一个编写器。但在大多数情况下，写入事务只需要几毫秒，因此多个写入者可以简单地轮流进行。SQLite 将处理比许多人怀疑的更多的写入并发。尽管如此，客户端/服务器数据库系统，因为它们手头有一个长期运行的服务器进程来协调访问，通常可以处理比 SQLite 以往任何时候都多得多的写入并发。

3. 大数据？→ 选择客户端/服务器

   如果您的数据增长到您感到不舒服或无法放入单个磁盘文件的大小，那么您应该选择 SQLite 以外的解决方案。SQLite 支持大小高达 281 TB 的数据库，假设您可以找到支持 281 TB 文件的磁盘驱动器和文件系统。即便如此，当内容的大小看起来可能会达到 TB 范围时，最好考虑使用集中式客户端/服务器数据库。

4. 否则 → 选择 SQLite！

   对于具有低写入并发性和小于 1 TB 内容的设备本地存储，SQLite 几乎总是更好的解决方案。SQLite 快速可靠，无需配置或维护。它使事情变得简单。SQLite“正常工作”。