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

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

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

适合SQLite的场景

嵌入式设备和物联网

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

客户端/服务器数据库引擎设计用于位于网络核心的精心照管的数据中心内。 SQLite 也可以在那里工作，但 SQLite 也在网络边缘蓬勃发展，在为应用程序提供快速可靠的数据服务的同时，还为自己提供了快速可靠的数据服务，否则这些应用程序的连接性会很差。

应用文件存储

SQLite 通常用作桌面应用程序的磁盘文件格式，例如版本控制系统、财务分析工具、媒体编目和编辑套件、CAD 包、记录保存程序等。传统的 File/Open 操作调用 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 语句。此设置在单个 VM 上运行，该 VM 与其他 23 台共享物理服务器，但在大多数情况下仍将平均负载保持在 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 命令行外壳版本 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（248 字节，256 TB）。即使它可以处理更大的数据库，SQLite 将整个数据库存储在单个磁盘文件中，许多文件系统将文件的最大大小限制为小于此值。因此，如果您正在考虑这种规模的数据库，您最好考虑使用客户端/服务器数据库引擎，将其内容分布在多个磁盘文件中，甚至可能分布在多个卷中。

高并发网站

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

选择正确数据库引擎的清单

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

关系数据库引擎充当减少带宽的数据过滤器。所以最好把数据库引擎和数据放在同一个物理设备上，这样高带宽的引擎到磁盘的链路就不用穿越网络，只有带宽较低的应用到引擎的链路。

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

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

许多并发写？ → 选择客户端/服务器

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

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

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

其他情况 → 选择sqlite

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

翻译自 https://www.sqlite.org/whentouse.html

本文由至简创作，采用知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 2021/08/11 15:42

SQLite适用场景