小巧、快速、可靠。
请选择其中的三个。
请选择其中的三个。
SQLite 与客户端/服务器 SQL 数据库引擎（如 MySQL、Oracle、PostgreSQL 或 SQL Server）之间无法直接比较，因为 SQLite 试图解决的是一个不同的问题。
客户端/服务器 SQL 数据库引擎致力于实现企业数据的共享存储库。它们强调可扩展性、并发性、集中性和控制。SQLite 致力于为单个应用程序和设备提供本地数据存储。SQLite 强调经济性、效率、可靠性、独立性和简单性。
SQLite 不会与客户端/服务器数据库竞争。SQLite 与 fopen() 竞争。
由于 SQLite 数据库无需管理，因此非常适合在无需专业人员支持的情况下运行的设备中使用。SQLite 非常适合在手机、机顶盒、电视、游戏机、相机、手表、厨房用具、恒温器、汽车、机床、飞机、远程传感器、无人机、医疗设备和机器人等“物联网”设备中使用。
客户端/服务器数据库引擎设计用于位于网络核心的精心维护的数据中心内。SQLite 也可以在那里运行，但它也能在网络边缘蓬勃发展，独立运行，同时为原本连接不稳定的应用程序提供快速可靠的数据服务。
应用程序文件格式
SQLite 通常用作桌面应用程序的磁盘文件格式，例如版本控制系统、财务分析工具、媒体编目和编辑套件、CAD 软件包、记录保存程序等等。传统的“文件/打开”操作调用 sqlite3_open() 连接到数据库文件。更新会在应用程序内容被修改时自动发生，因此“文件/保存”菜单选项就变得多余了。可以使用 备份 API 实现“文件/另存为”菜单选项。
这种方法有很多好处，包括提高性能、降低成本和复杂性，以及提高可靠性。有关更多信息，请参阅技术说明 "aff_short.html"、"appfileformat.html" 和 "fasterthanfs.html"。此用例与下面介绍的 数据传输格式 和 数据容器 用例密切相关。
网站
SQLite 非常适合用作大多数低至中等流量网站的数据库引擎（也就是说，大多数网站）。SQLite 可以处理的 Web 流量数量取决于网站对数据库的使用程度。一般来说，任何每天访问量低于 10 万次的网站都应该可以使用 SQLite。10 万次的访问量只是一个保守的估计，而不是硬性的上限。SQLite 已被证明可以处理 10 倍于此的流量。
SQLite 网站 (https://www.sqlite.org/) 自然使用的是 SQLite 本身，截至本文撰写之时（2015 年），它每天处理大约 40 万到 50 万个 HTTP 请求，其中约 15% 到 20% 是访问数据库的动态页面。动态内容使用 每个网页约 200 个 SQL 语句。此设置运行在一台与其他 23 台物理服务器共享的虚拟机上，即使这样，负载平均值也能在大多数时间内保持在 0.1 以下。
数据分析
了解 SQL 的用户可以使用 sqlite3 命令行外壳（或各种第三方 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 归档 的理念展示了如何将 SQLite 用作 ZIP 归档或 Tarball 的替代品。存储在 SQLite 中的文件归档只比等效的 ZIP 归档略大，在某些情况下甚至更小。此外，SQLite 归档还具有增量和原子更新功能，以及存储更丰富元数据的能力。
Fossil 2.5 及更高版本提供了 SQLite 归档文件 作为下载格式，除了传统的 tarball 和 ZIP 归档之外。 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 可执行文件复制到目标计算机并运行即可），因此它非常适合用作教学 SQL 的数据库引擎。学生可以轻松地创建任意数量的数据库，并且可以将数据库通过电子邮件发送给教师以获取评论或评分。对于希望学习 RDBMS 实现方式的更高级学生，模块化且注释齐全且有文档的 SQLite 代码可以作为良好的基础。
实验性的 SQL 语言扩展
SQLite 的简单模块化设计使其成为原型化新的、实验性的数据库语言功能或理念的良好平台。
客户端/服务器应用程序
如果有多个客户端程序通过网络向同一个数据库发送 SQL，则使用客户端/服务器数据库引擎而不是 SQLite。SQLite 可以通过网络文件系统运行，但由于大多数网络文件系统都存在延迟问题，因此性能不会很好。此外，许多网络文件系统实现（在 Unix 和 Windows 上都是如此）中的文件锁定逻辑都有错误。如果文件锁定无法正常工作，两个或多个客户端可能会尝试同时修改同一个数据库的同一部分，从而导致损坏。由于此问题是由底层文件系统实现中的错误造成的，因此 SQLite 无能为力来防止它。
一般来说，在同一个数据库将被直接访问（没有中间应用程序服务器）并且同时从多个网络计算机访问的情况下，应避免使用 SQLite。
高流量网站
SQLite 通常可以很好地用作网站的数据库后端。但如果网站是写入密集型的，或者忙到需要多个服务器，则应考虑使用企业级客户端/服务器数据库引擎，而不是 SQLite。
非常大的数据集
SQLite 数据库的大小限制为 281 TB（248 字节，256 TiB）。即使它可以处理更大的数据库，SQLite 也会将整个数据库存储在一个磁盘文件中，并且许多文件系统将文件的最大大小限制为小于此值。因此，如果您正在考虑这种规模的数据库，最好考虑使用一个客户端/服务器数据库引擎，它将内容分散到多个磁盘文件，甚至可能分散到多个卷中。
高并发
SQLite 支持无限数量的并发读取器，但它一次只允许一个写入器。对于许多情况来说，这不是问题。写入者会排队。每个应用程序快速完成其数据库工作并继续，并且没有锁会持续超过几十毫秒。但有些应用程序需要更高的并发，这些应用程序可能需要寻求不同的解决方案。
数据是否通过网络与应用程序分离？ → 选择客户端/服务器
关系数据库引擎充当带宽减少的数据过滤器。因此，最好将数据库引擎和数据保留在同一物理设备上，这样高带宽的引擎到磁盘链接就不必遍历网络，只需低带宽的应用程序到引擎链接即可。
但是 SQLite 已内置到应用程序中。因此，如果数据位于与应用程序不同的设备上，则需要更高的带宽引擎到磁盘链接跨越网络。这可行，但不是最优的。因此，当数据位于与应用程序不同的设备上时，通常最好选择客户端/服务器数据库引擎。
注意： 在此规则中，“应用程序”指的是发出 SQL 语句的代码。如果“应用程序”是 应用程序服务器，并且内容驻留在与应用程序服务器相同的物理机器上，那么即使最终用户是另一个网络跳跃，SQLite 也可能仍然适用。
许多并发写入者？ → 选择客户端/服务器
如果许多线程和/或进程需要同时写入数据库（并且它们不能排队轮流写入），那么最好选择一个支持该功能的数据库引擎，这总是意味着客户端/服务器数据库引擎。
SQLite 每个数据库文件一次只支持一个写入者。但在大多数情况下，写入事务只需要几毫秒，因此多个写入者只需轮流写入即可。SQLite 处理的写入并发量比许多人想象的要多。尽管如此，客户端/服务器数据库系统由于拥有一个正在运行的服务器进程来协调访问，因此通常比 SQLite 处理更多的写入并发量。
大数据？ → 选择客户端/服务器
如果您的数据将增长到您无法容忍或无法容纳在一个磁盘文件中的大小，那么您应该选择除 SQLite 之外的解决方案。SQLite 支持高达 281 TB 的数据库，假设您可以找到支持 281 TB 文件的磁盘驱动器和文件系统。即使如此，当内容的大小看起来可能超过 TB 范围时，最好考虑一个集中式的客户端/服务器数据库。
否则 → 选择 SQLite！
对于具有低写入并发量且内容少于 1 TB 的设备本地存储，SQLite 几乎总是更好的解决方案。SQLite 快速可靠，不需要配置或维护。它使事情变得简单。SQLite “开箱即用”。
此页面最后修改于 2024-04-03 17:48:26 UTC