原创SQLite翻译系列2: 合理使用SQLite
合理使用SQLite
客户端/服务器SQL数据库引擎努力实现企业数据的共享仓库。它们强调可伸缩性、并发性、集中化以及控制。SQLite致力于为单个的应用程序和设备提供本地数据存储。SQLite强调经济、效率、可靠性、独立性、以及简单性。
SQLite不与客户端/服务器数据库竞争，它与fopen()函数竞争。
SQLite能表现出色的地方
- 嵌入式设备和物联网
因为SQLite数据库不需要管理，所以它在不需要专家支持情况下必须能运行的设备上工作得很好。SQLite非常适合用于物联网(包括：电话、机顶盒、电视机、游戏控制器、数码相机、数字手表、厨房电器、恒温器、汽车、机床、飞机、远程传感器、无人飞机、医疗设备，以及机器人)
-
应用程序文件格式
SQLite通常被用作桌面应用程序的磁盘文件格式，如版本控制系统、财务分析工具、媒体编目和编辑套件、CAD软件包、记录保存程序等。传统的File/Open操作调用sqlite3_open()函数以附加到数据库文件。随着应用程序内容的修改，会自动执行更新，因此File/Save菜单选项就变得多余。File/Save_As菜单选项能够使用备份API(backup API)来实现。 这种方法有很多好处，包括改进性能、减少成本和复杂度、以及提高可靠性。更多内容请参见技术说明"aff_short.html" and "appfileformat.html" and "fasterthanfs.html"。这种使用情况与下面的数据传输格式(data transfer format)和数据容器(data container)的使用情况密切相关。
-
网站
SQLite作为中小流量网站(也就是说，大多数网站)的数据库引擎工作得非常好。SQLite能够处理的网页总流量依赖网站使用其数据库的程度。一般来说，任一点击量低于10万每天的站点都可以使用SQLite。10万/天的点击量只是一个保守估计，不是一个硬性上限。SQLite已经被证明可以处理10倍于此的流量。 当然，SQLite网站(https://www.sqlite.org/)本身使用了SQLite，在撰写本文时，它每天处理大约40万到50万的HTTP请求，其中大约有15~20%是访问数据库的动态页面。动态内容每个网页使用了大约200个SQL语句。该机制运行在单个虚拟机上，该虚拟机与其他23个虚拟机共享一个物理服务器，但是大多数时候仍然将平均负载保持在0.1秒以下。
-
数据分析
理解SQL的人可以利用SQLite3命令行外壳程序(the sqlite3 command-line shell)(或者各种第三方SQLite访问程序)来分析大型数据集。可以从CSV文件导入原始数据，然后对数据进行切分，以生成大量汇总报表。可以使用脚本语言编写的简单脚本，完成更加复杂的分析，该脚本语言可以是Tcl和Python(这两者内置在SQLite中随同发布)、R语言、或使用现成适配器的其他脚本语言。可能的用途包括站点日志分析、运动统计分析、编程指标汇编、以及实验结果分析。许多生物信息学研究者以这种方式使用SQLite. 当然，使用企业客户端/服务器数据库也可以完成相同的事情。SQLite的优点是它更容易安装和使用，生成的数据库是一个单独的文件，可以写入到USB记忆棒，或者通过电子邮件发送给同事。
-
用于企业数据的缓存
许多应用程序使用SQLite作为企业关系数据库管理系统(RDBMS)相关内容的缓存。这样减少了时延，因为大多数查询都是针对本地缓存当前进行的，避免了网络往返开销，也减少了网络和中央数据库服务器的负载。在许多情况下，它意味着客户端应用程序在网络中断时可以继续进行操作。
-
服务端数据库
系统设计者们报告成功使用了SQLite，将它作为与运行在数据中心里面的服务器程序有关的数据存储来使用，换句话说，将SQLite当作特定应用程序数据库服务器的底层存储引擎来使用。 在这个模式下，整个系统仍旧是客户端/服务器模型：客户端在网络上发送请求给服务器，并接收回响应。但是，客户端请求和服务器响应不是发送通用SQL语句并返回原始表内容，而是高层级的、与特定应用程序相关的。服务器将请求转换为多个SQL查询，收集查询处理结果，执行后置处理(post-processing)、过滤和分析，然后构造只包含基本信息的高层级响应。 开发者报告说，SQLite在这种场景下经常比客户端/服务器SQL数据库引擎更快。数据库请求由服务器序列化，因此并发性就不是问题。并发性也可以通过“数据库分区”来提高：为不同的子域使用单独的数据库文件。
-
数据传输格式
因为SQLite数据库是一个具有定义良好的跨平台格式(well-defined cross-platform format)的单一紧凑文件，所以它经常被用作将内容从一个系统传输到另一个系统的容器。发送方将内容收集到一个SQLite数据库文件中，将该文件传给接收方，然后接收方根据需要使用SQL语句提取这些内容。 SQLite数据库促进了系统之间的数据传输，即使当终端具有不同的字符大小和/或字节顺序。数据可以是大型二进制的blob、文本、以及小型数值或布尔值的复杂组合。通过添加新表和/或栏目，可以很容易地扩展数据格式，而不会破坏现有的接收方。SQL查询语言意味接收方不需要完全立刻解析整个传输，而是可以根据需要查询已接收的内容。这种数据格式是“透明的”，因为它可以很容易地通过多种来自不同供应商的通用的开源工具进行解码，供人查看。
-
-
文件存档和/或数据容器
SQLite存档(SQLite Archive)理念体现了如何使用SQLite作为ZIP存档或Tarball的替代品。存储在SQLite中的文件存档比起同等的ZIP存档只稍微大一点，在某些情况下实际上还要小。SQLite存档具有增量和原子更新的功能、以及存储更丰富元数据的能力。 除了传统的tarball和ZIP存档文件外，Fossil 2.5及以上版本还提供了SQLite存档文件作为下载格式。SQLite3.exe命令行外壳程序(sqlite3.exe command-line shell)3.22.0及以上版本将使用存档命令(.archive command)来创建、罗列、或解包一个SQL存档。 对于需要将不同内容绑定到的自包含和自描述的包中，以便跨网络传输的情况来说，SQLite是一个很好的解决方案。内容采用定义良好、跨平台、以及稳定的文件格式编码，编码效率高，并且接收方可以提取内容的小部分子集，而不必读取并解析整个文件。SQL存档作为向许多客户端派发软件更新或内容更新的分发格式非常有用。实际应用中，这个理念有不同的变化形式，举例说，发送电视节目指南给机顶盒以及发送空中更新包给车辆导航系统。
-
代替专有临时磁盘文件
许多程序使用fopen()、fread()、以及fwrite()函数以自制格式创建和管理数据文件。作为这些专有临时数据文件的替代品，SQLite工作得特别好。与直觉相反，对面向磁盘读写内容来说，SQLite能够比文件系统更快(faster than the filesystem) 。
-
内部或临时数据库
对于必须以各种方式筛选和排序大量数据的程序，通常更易、更快速的方法是将这些数据加载到内存SQLite数据库中，并使用具有joins和ORDER BY子句的查询以所需要的形式和顺序提取这些数据，而不是去试图手动编写代码实现相同的操作。以这种方式在内部使用SQL数据库还为程序提供了更大的灵活性，因为无须对每个查询重新编码就可以添加新列和索引。
-
演示或测试期间代替企业数据库
客户端应用程序通常使用一个通用数据库接口，该接口允许连接到各种SQL数据库引擎。将SQLite包含在支持的混合数据库中，并将SQLite引擎静态地连接到客户机中，这是很有意义的。那样客户端程序就可以与SQLite数据文件单独使用，用于测试或演示。
-
教育与培训
因为SQLite安装和使用都很简单(安装过程很简单：只要将SQLite3或SQLite3.exe可执行文件拷贝到目标机器上，然后运行它即可)，所以用于教受SQL中，它会成为一个很好的数据库引擎。学生们可以很容易地任意创建大量数据库，并将数据库通过电子邮件发给导师，以便评论和评分。就对学习如何实现RDBMS感兴趣的更高层级的学生而言，模块化的、注释良好的以及文档化的SQLite代码可以作为一个很好的基础。
-
实验性SQL语言扩展
SQLite的简单、模块化设计使其成为一个很好的平台，可以为新的、实验性的数据库功能或概念提供原型。
-
客户端/服务器关系数据库管理系统(RDBMS)可能工作得更好的情况
-
-
客户端/服务器应用程序
如果有许多客户端程序通过网络向同一个数据库发送SQL，那么请使用客户端/服务器数据库引擎而不是SQLite。SQLite可以在网络文件系统上工作，但是由于与大多数网络文件系统相关的迟延，所以性能不会很好。另外，文件锁定逻辑在许多网络文件系统实现中(包括Unix和Windows)都有Bug. 如果文件锁定不能正确工作，两个或多个客户端可能会试图同时去修改同一个数据库的相同部分，从而导致数据库损坏。因为该问题是由于底层文件系统实现中的Bug引起的，所以SQLite无法阻止它。一个好的经验法则就是，在同一数据库会被许多计算机基于网络同时直接(无须通过中间应用服务器)访问的情况下，避免使用SQLite。
-
大容量网站
作为网站的数据库后端，SQLite通常工作得很好。但是如果网站是写入密集型的，或者非常繁忙以至于要求多个服务器，那么就要考虑企业级的客户端/服务器数据库引擎，而不是SQLite。
-
大规模数据集
一个SQLite数据库大小的上限是281TB字节(248 字节, 256 tibibytes)，而且，即使它可以处理更大的数据库，SQLite也将整个数据库存储在单个磁盘文件中，许多文件系统将文件的最大大小限制在小于此值的范围内。因此，假如你正在考虑如此大规模的数据库，那么更好的做法是考虑使用客户端/服务器数据库引擎，它将内容分散在多个磁盘文件，以及可能多个卷中。
-
高并发
SQLite支持不限数量的多个数据阅读者同时读取数据，但是，它在任何时刻都只允许有一个数据写入者写入数据。在许多情况下，这不是问题。写入者排队等候。每个应用程序快速完成数据库工作并继续往下处理，没有一个锁会持续超过几十毫秒。但是，有些应用程序需要更多的并发性，那么这些应用程序可能需要寻求不同的解决方案。
-
选择正确数据库引擎的检查列表
-
是否需要将数据与应用程序通过网络隔离？→请选择客户端/服务器数据库引擎
关系数据库引擎充当减少带宽数据过滤器。因此，最好将数据库引擎和数据保持在相同的物理设备上，这样高带宽的引擎到磁盘的网络连接不必穿过网络，只需要低带宽的应用到引擎的网络连接穿过网络。
但是SQLite是内置在应用程序之中的，因此，假如数据位于与应用程序不同的单独设备上，那么它就要求跨网络更高带宽的引擎到磁盘的网络连接。这是可行的，但是不是最佳的。因此，当数据位于与应用程序不同的单独设备上时，通常最好选择客户端/服务器数据库引擎。
注意：此规则中，“应用程序”是指出现SQL语句的代码。假如“应用程序”是一个应用服务器，并且假如数据内容与应用服务器相同的物理机器上，那么即使终端用户在另一个网络跳点之外，SQLite可能仍旧是很合适的。
-
许多并发写入者？→请选择客户端/服务器数据库引擎
假如许多线程和/或进程需要在同一时刻(并且它们不能排队和轮流)写数据库，那么，最好是选择支持该能力的数据库引擎，这通常也意味着客户端/服务器数据库引擎。
SQLite仅支持单个数据库文件每次只有一个写入者。但是在大多数情况下，一个写入事务仅花费几毫秒，因此多个写入者可以简单地轮流进行。SQLite可以处理比人们想象的要多的写并发。然而，客户端/服务器数据库系统，因为它们手边有一个长时间运行的服务器进程来协调访问，因此，通常能够处理远比SQLite要多得多的写并发。
-
大数据？→请选择客户端/服务器数据库引擎
如果你的数据会增长到不适合或不能装入到单个磁盘文件的大小时，那么你应该选择一个不同于SQLite的解决方案。SQLite支持最大281TB的数据库，前提是你可以找到支持281TB文件的磁盘驱动器和文件系统。即便如此，当内容的大小看起来可能到达TB范围时，最好选择集中式的客户端/服务器数据库。
-
否则→请选择SQLite！
对于具有较低的写入并发性和小于TB内容的本地设备存储，SQLite几乎总是更好的解决方案。SQLite快速可靠，无须配置和维护。它使事情变得简单，SQLite恰到好处。
-
原文地址：https://www.sqlite.org/whentouse.html
浙公网安备 33010602011771号