2016年应该使用SQLite的5大原因

Posted 2021-04-30 数据库开发

来自：码农网

链接：http://www.codeceo.com/article/5-reasons-use-sqlite.html

英文原文：http://charlesleifer.com/blog/five-reasons-you-should-use-sqlite-in-2016/

[ 转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]

什么？你还不知道SQLite？那么我告诉你，SQLite是一个了不起的数据库，能够在实际生产环境中做真正的工作。在这篇文章中，我将简要说明5个我认为你应该在2016年使用SQLite的原因。

1、管理简单

你以前管理过Postgres数据库吗？为了确保数据库服务器的正确配置（共享缓冲区，有效缓存大小，work mem，维护work mem，wal缓冲区…），你需要理解和学习相当多的东西。升级可以说是一个可怕的过程，并且，你可能需要脱机使用数据库，运行专门的升级程序，然后在心里默默期盼当你备份回来的时候它还能继续工作。此外，你知道你的Postgres数据库究竟存储在哪里吗？你能随便指一个地方，说，“那就是我的数据库”吗？

（众所周知的是，有很多情况下只能使用Postgres（或mysql，Oracle，SQL Server等）才能满足应用程序的需求。但是我在这里这么说的目的，并非如此。我只是想突出说明管理SQLite 数据库和其他典型数据库服务器之间的区别。）

SQLite容易管理——因为它是一个单一文件（或在某些时候是一个文件+事务日志）。文件格式在很多主要的版本上都非常稳定，所以假设我有一个从3.0.0版本（在2004年）开始的SQLite数据库文件，那么我也可以使用最新的SQLite 3.10.0读取它。如果我想将数据库文件放到一个U盘中，那么我只要复制文件，或者更好的做法是将文件保存在dropbox文件夹中。如果我想每天晚上备份，那么我只要同步数据库文件到S3。如果我想分享一些和同事一起做的数据分析，那么完全可以发送一份数据库文件的副本给他们，然后他们就可以使用了。数据库以一种单个文件的形式存在，且具备稳定的格式，是SQLite的特色。

更重要的是，SQLite很容易配置。SQLite的功能可以通过两种方式进行管理：编译标志和PRAGMA 语句（运行时配置）。没有所谓的配置文件，你只需要构建你想要的库，然后在你创建数据库连接时，配置运行时选项。

2、不断提高又坚如磐石的稳定性

SQLite是由一些真正了不起的软件工程师积极开发的。高品质的新功能正以一种惊人的速度被添加进来。就在最近，SQLite通过json1扩展增加了对JSON数据的支持。 SQLite还发布了全文检索扩展的改进版本，其中包括使用BM25算法的结果排名。

除了增加新的功能，SQLite的开发人员也正在努力使库拥有更多的性能。在

3.8.11版本中，发布说明中包含这条小介绍：

SQLite现在的运行速度是3.8.0版本的两倍，3.3.9版本的三倍

尽管出现了这么多的变化和改进，但SQLite很少引入bug。 SQLite的测试套件被广泛认为是行业中最好的测试套件之一，并且关于SQLite如何测试的页面经常出现在HackerNews上，因为开发人员前赴后继地发现了这篇令人印象深刻的文档。

3、可扩展和可控制

举个实际的例子，假设你在一个表中有一个列用于存储URL，你想要确定哪些是最常见的主机名——假设你使用的是不同的数据库，那么你将不得不写一个复杂的正则表达式，结合了字符串操作函数，或要提取数据到app并在代码中进行计算。使用SQLite，你就可以用Python语言定义一个hostname函数，然后用它来创建一个简单的COUNT查询：

from urlparse import urlparse

def hostname(url):

    return urlparse(url).netloc

conn = sqlite3.connect('my-database.db')

conn.create_function('hostname', 1, hostname)  # name, num_params, func

SELECT hostname(mytable.url), COUNT(mytable.id) AS ct

FROM mytable

GROUP BY hostname(mytable.url)

ORDER BY ct DESC;

你还可以创建聚合函数，接受0…n的值，并产生单个的输出值。例如计算标准偏差、通过用某种方式处理值来生成一个字符串、做某种类型的分类，等等。

虚拟表，目前唯一由aspw支持，允许你在代码中定义一个表，然后查询它，好像它是一个普通的SQL表，即使备份数据可能完全是动态的。例如，我写了一个简单的虚拟表，可以让你查询Redis就好像它是一个SQL表。

你也可以写同名的函数，它是用于返回0…n行结果的函数。其中一个例子是一个正则表达式检索函数，处理输入和产生匹配令牌的行。我写了一个库，sqlite-vtfunc，它可以使得我们编写这些类型的函数变得非常容易。

实际上，SQLite的每个方面都通过你的应用程序来操作。

4、快如闪电

SQLite的速度弥补了它最大的不足之处之一，那就是数据库文件锁定写入。令人难以置信的快速写数据，只当有大量的并发写提供服务时，数据库锁定才会成为一个问题。

5、WAL模式

SQLite的3.7.0版本中补充了一种利用预写日志的新日志记录方法。虽然其本身真不算是令人振奋的消息，但这对web应用程序开发人员（或任何处理并发的人员）意味着读的服务不会再阻塞写的服务，反之亦然。换言之就是，读和写可以同时地发生。如果没有WAL模式，那么要想写入数据库，写的服务则需要独占访问数据库，并且不能发生读的服务，直到写的服务结束。

下面是说明两者之间区别的一个例子。假设，我们有两个进程，一个写，一个读。写的服务打开了一个独占的事务（表明写的意图）。接下来，读的服务打开一个事务处理。然后读的服务尝试发出SELECT语句：

Journal mode = “delete” (the default):

Writer: BEGIN EXCLUSIVE

Reader: BEGIN

Reader: SELECT * FROM foo; 

Error: database is locked

Journal mode = “wal”:

Writer: BEGIN EXCLUSIVE

Reader: BEGIN

Reader: SELECT * FROM foo; 

Returns table contents

然而，值得一提的是，即使你不启用WAL模式，写的服务通常发生在毫秒间。这个时间是如此是短，以致于只有当你并发很高或写的事务非常长时，才会注意到出现问题。

加分原因：BerkeleyDB

BerkeleyDB的SQLite集成，能够给予应用程序开发人员所需的并发数据库访问甚至更好的性能，因为它不是锁定整个数据库，BerkeleyDB只需要锁定的个别的页面即可。这允许BerkeleyDB能在并发数据库负载下更有效地规模化，提供的事务不会争夺相同页面的数据。 BerkeleyDB也支持多版本并发控制（MVCC），允许读的操作继续发生在数据页面上，通过一个写的事务来处理数据。

BerkeleyDB还有一个好处是提高了效率。换句话说，BerkeleyDB可使用更少的系统资源，执行较少的系统调用。你可以在此白皮书中和这篇简要的技术概述中阅读更多细节。

BerkeleyDB的SQL接口是SQLite的一个插入式替换，并且支持相同的API和功能。 BerkeleyDB提供了一些附加功能，如复制（SQLite有一个备份工具，但我认为它不如BDB的强大）、加密，当然还有BerkeleyDB本身的所有功能。

使用BerkeleyDB的一个主要缺点是，它是配置值非常敏感，而且要想获取正确的页面大小，缓存大小以及其他设置，需要很深厚的知识造诣。另一个缺点是许可证——阅读更多关于BerkeleyDB许可证的内容，查看Oracle的许可页面。

有关编译Python SQLite驱动程序和BerkeleyDB的使用说明，请查看这篇文章。

最后

我希望你能尝试一下SQLite。不要听信那些因循守旧的人说它不适于生产，或不适合在web应用中使用它的一面虚词。

如果您想了解更多，SQLite本身就有一个很好地介绍了何时使用SQLite的文档，其中还包括了让另一个RDBMS更好地工作的一系列情况。我也写过一篇较短的文章《SQLite: Small. Fast. Reliable. Choose any three》，你可能会喜欢。

---

●本文编号38，以后想阅读这篇文章直接输入38即可。

●输入m可以获取到全部文章目录

---