SQLite 你用对了吗

发布于: 19 小时前
SQLite你用对了吗

何时选择SQLite?

SQLite没法直接和那些C/S模型的SQL数据库引擎相比,比如MySQL、Oracle、PostgreSQL、 SQL Server等等。因为SQLite在试图解决不同的问题。

C/S模型的数据库致力于实现共享的企业仓库,强调扩展性、并发性、集中化与管理;而SQLite致力于为独立的应用程序和设备提供本地化数据存储,强调经济、高效、可靠、独立和简单。

SQLite与C/S方式使用的数据库并不构成竞争,而关注的是那些使用fopen()的场景和地方。

SQLite可以适用的应用场景

  • 嵌入式设备和物联网

SQLite数据库基本上不需要管理,在没有专家支持的设备上也能跑的很好。很适合用在手机、机顶盒、电视、游戏机、相机、手表、厨房电器、温控器、汽车、机床、飞机、传感器、无人机、医疗器械和机器人等等,以及物联网涵盖的所有设备。

C/S模式的数据库的诞生,是为了建立网络核心地带中重要的数据中心。当然SQLite也可以应用在这里,不过SQLite在网络边缘地带也能工作的非常好,尤其是在为弱联网应用程序提供快速和可靠的数据服务时,表现的更为出色。

  • 应用程序文件格式

“应用程序文件格式”是用于将应用程序状态持久化到磁盘或在程序之间交换信息的文件格式。这篇文章详细介绍了这个概念:点击查看

SQLite在桌面应用程序中,经常被用作一种磁盘存储的文件格式,比如按版本控制系统、金融分析工具、多媒体管理和编辑套件、计算机辅助设计工具包和记录本程序等等。之前那些文件打开的操作,你现在调用sqlite3_open()就能关联到数据库文件上了。这样当程序中的内容变化时就会自动更新到文件里,菜单里边的"文件/保存"这个选项就再没什么用了。菜单里的“文件/另存为”选项可以用backup API来实现。

这种用法有很多好处,提升了操作性能、降低了成本和复杂度、改善了程序的可靠性等等。可以参考这几个技术手册,获得更多详情:"aff_short.html""appfileformat.html""fasterthanfs.html"。这个使用场景和下边要介绍的“数据传输格式”以及“数据容器”两个使用场景密切相关。

  • 网站

SQLite作为数据库引擎,适用于大多数中低流量规模的网站(也就是绝大部分网站),SQLite处理的网络流量,取决于网站访问数据库的业务量。一般来讲,日点击量在10W以下的网站,使用SQLite都没问题。10W日点击率只是一个保守的估计值,并不是严格的上限值。SQLite已经被证明了可以处理10倍这样的流量也没有问题。

当然,SQLite的官方网站(https://www.sqlite.org/)也在使用SQLite,在写本文时(2015年),SQLite网站上每日处理大约40W-50W的HTTP请求,其中15%-20%的内容是动态页面。动态页面每个网页使用大约200个SQL语句。这些在一个VM上运行,该VM与其他23个VM共享一台物理机。就这样,大部分时候负载也保持在0.1以下。

  • 数据分析

会用SQL的人们可以使用SQL命令行工具(或者其他第三方SQLite访问工具)来处理分析大量的数据集。原始数据可以从CSV文件导入,然后把数据切片并生成大量的摘要报告。也可以使用基于Tcl或者Python(SQLite原生支持)写的脚本做更复杂的分析工作,也可以基于R语言或者其他方便适配的编程语言。也可以去做其他的事情,比如网站日志分析,体育报告,程序度量指标的汇总,实验报告的分析等等。很多生物信息研究人员都用这种方式使用SQLite。

当然,企业级的C/S数据库也可以做这些事情。但SQLite更容易安装和使用,并且生成的数据库是一个单独的文件,可以U盘拷贝,也可以电子邮件发给同事。

  • 数据缓存

很多应用程序使用SQLite做缓存,暂存企业级关系型数据库中的相关内容。这样如果大部分查询都在本地缓存命中的话,就避免了网络上的往返过程,从而大大减少了延迟,也减少了网络和数据库服务器的负载。并且这就意味着,在很多场景下,即使网络中断了,客户端程序依然可以使用。

  • 服务端数据库

系统设计人员报道了SQLite在服务端程序上做数据存储的成功案例,也就是说,在服务器程序上使用SQLite作为底层存储引擎。

这种场景下,整个系统也是C/S模型:客户端发送请求到服务端,并通过网络接收响应。不过,并不是发送原生的SQL查询然后收到数据库表的原始数据这种模式,请求和响应包是由应用程序指定的更高级的自定义格式。服务端把收到的请求转化成多个SQL查询,并收集查询结果,然后处理、过滤和分析,把要返回的必要信息构造成一个自定义的更高级的响应包。

据开发者反馈,这种使用场景下,SQLite经常比CS模型的数据库表现的更快。数据库请求被服务端程序做了串行化,所以也不会存在并发访问的问题了。可以基于“数据库分片”来做并发,也就是不同的业务使用不同的数据库文件。比如:服务端针对每个用户都使用一个独立的SQLite数据库,这样服务端就能同时处理成千上万个大量的同样的连接,不过这样也有个弊端:每个SQLite数据库只能被一个连接使用。

  • 数据传输格式

SQLite数据库是一个单独的压缩文件,其内容是一种定义良好的跨平台的格式,他经常被用作两个系统之间交换数据的容器,发送方将数据放在SQLite文件里,然后把文件发给对方,接收方在使用SQL提取需要的数据。

SQLite促进了不同系统之间的数据传输,即使两个系统有不一样的字大小或者不同的字节序,也都没有问题。数据可以是二进制块、文本或者数字等等不同类型的组合,数据格式也可以通过新建表或者增加列方便的进行扩展,传输方式不用有任何变化。使用SQL查询语言也就意味着接收方不用一次性解析整个传输内容,而是根据需要查询收到的数据。数据格式是透明的,人们使用各种常见的工具可以很容易的进行解码。

  • 文件存档(数据容器)

SQLite的归档思想展示了如何使用SQLite作为zip和tar的替代品,存在SQLite中的文件归档之比对应的zip格式稍微大一点儿,有时实际会更小一些。并且SQLite归档具备增量和原子性更新的特点,能存储更加丰富的数据类型。

Fossil2.5和更新版本提供SQLite的归档文件作为下载格式,除此之外也支持zip和tar格式。SQLite3.22以上版本使用.archive命令可以创建、列出和解包SQL存档。

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

如果你需要一种向大量客户端广播软件或新内容的分发格式,SQL归档就非常有用。比如传输电视节目指南到机顶盒和发送更新到车辆导航系统。

  • 替代临时文件

许多程序使用fopen()、fread()和fwrite()来创建和管理本地格式的数据文件。SQLite作为这些数据文件的替代品尤其好用。与直觉相反,SQLite可以比文件系统更快地将内容读写到磁盘。

  • 内部或临时数据库

一些程序针对海量数据,存在各式各样的筛选和排序需求,如果使用SQLite数据库,可以方便和快速的把数据加载到内存里,然后使用带join和order by子句的查询按需要的格式和顺序解析出数据,不用再手动的做各种繁琐的操作得到你想要的结果。在内部使用SQLite数据库,可以让你的程序具备更好的灵活性,不用修改你的每个查询,你也可以新增不同列和索引。

  • 在demo或测试阶段,作为企业级数据库的替代品

客户端程序通常使用通用的数据库接口,接口可以连接到各种SQL数据库引擎。将SQLite包含在受支持的数据库中,并静态地将SQLite引擎链接到客户端,这是很有意义的。通过这种方式,客户端程序可以与SQLite数据文件一起单独使用,用于测试或演示。

  • 教育和培训

SQLite的设置和使用都很简单,非常适合于SQL教学(安装很简单:只需把sqlite3或者sqlite3.exe可执行文件复制到目标机器,然后运行它就可以了。)。学生们可以很方便的创建很多他们想用的数据库,并用电子邮件发给讲师进行评分或者征求老师意见。对于有兴趣研究关系型数据库是如何实现的高年级学生来说,SQLite的代码是个不错的参考,代码是结构化设计,注释清晰,文档齐全。

  • SQL语言的实验性扩展

SQLite的简单和模块化设计使其成为一个很好的平台,可以为实验性的数据库语言新特性快速构建原型。

C/S的RDBMS更适合的一些情况

  • C/S模型的程序 如果有大量的客户端程序通过网络同时向一个数据库发送SQL查询,那么请选择C/S的数据库而不是SQLite。SQLite也可以跑在网络文件系统上,但是大多数网络文件系统都存在延迟,性能不会很好。并且,在很多的网络文件系统实现上,文件锁的逻辑一般都有bug,当出现bug时,如果两个以上的客户端同时尝试修改数据中的同一条数据,就可能导致数据损坏。这个问题是由底层文件系统实现中的bug导致的,所以SQLite也无可奈何。 一个最近原则就是避免多端需要直接访问同一个数据库(不需要介入应用程序服务器)的场景下使用SQLite,可以考虑在网络上的每台计算机上同时使用SQLite。

  • 大流量的网站

作为一个网站的后端数据库,SQLite可以表现的很好。但是如果网站是写密集型的,或者负载很高,需要多台服务器,那么可以考虑使用企业级的C/S数据库引擎,而不是SQLite。

  • 非常大的数据集

一个SQLite数据库的容量最多为128TiB, 但即使可以处理这么大的数据量,SQLite把整个数据库放在单个文件里,很多文件系统中单个文件的容量并没有这么多。如果你在考虑使用这样大数据规模的数据库的话,那就不用选SQLite了。最好虑使用C/S数据库引擎,这类引擎可以将数据库内容放到多个磁盘文件,甚至可能跨多个卷。

  • 高并发场景

SQLite虽然不限制读连接的数量,但同一时刻只允许一个连接写数据。在很多场景下,这都没问题,因为写请求可以做排队。每个应用程序都快速地执行SQL查询并继续以后的处理,没有一个锁持续几十毫秒以上。但是有些应用程序需要更多的并发性,SQLite可能就无法满足了。

  • 选择合适数据库的检查清单

  1. 数据需要通过网络与应用程序分离 → 选择C/S数据库

当数据位于独立于应用程序的设备上时,通常最好选择C/S数据库引擎。Nota Bene:在这个规则中,“应用程序”是指发出SQL语句的代码。如果“应用程序”是一个应用程序服务器,并且内容驻留在与应用程序服务器相同的物理机器上,那么SQLite可能仍然是合适的,即使最终用户是另一个网络用户。

  1. 存在大量的并发写 → 选择C/S数据库

如果许多线程或进程需要同时写数据库(不能排队写),那么最好选择C/S数据库引擎。SQLite对于每个数据库文件一次只支持一个写入。但在大多数情况下,写事务只需要几毫秒,所以多个写可以轮流执行,用这种方式SQLite可以处理很多的并发写,虽然很多人都比较怀疑。然而,由于C/S数据库系统有一个长期运行的服务器进程来协调访问,因此它们通常可以处理比SQLite多得多的并发写。

  1. 数据量很大 → 选择C/S数据库

如果您的数据增长到让您感到不舒服或无法放入单个磁盘文件的大小,那么您应该选择SQLite以外的解决方案。SQLite支持最大128IiB的数据库(前提是文件系统支持,磁盘够大)。即便如此,当数据容量可能会达到TB级时,最好考虑使用集中式客户机/服务器数据库。

  1. 其他情况 → 选择SQLite!

如果写并发不多,数据容量少于1tb,SQLite几乎总是一个很好的选择。SQLite是快速和可靠的,它不需要配置或维护。

点击查看E文原文https://www.sqlite.org/whentouse.html

更多互动和内容:加入作者私人小密圈,和作者更多互动,并获取更多成长路上的分享

发布于: 19 小时前 阅读数: 11
用户头像

这小胖猫

关注

可能是有思想的一只 2017.10.25 加入

程序员长工,服侍过两个东家,第一个4年从开发工程师做到主程,第二个4年从开发工程师做到部门研发总监,用谦虚、热情和创业的心态做事儿。常常做些编程、冥想、写东西和打球之类的事情,乐此不疲

评论

发布
暂无评论
SQLite你用对了吗