SQLite的13个使用场景

SQLite和C/S SQL数据库引擎没有直接的可比性,这些数据库引擎包括MySQL, Oracle, PostgreSQL, 或者 SQL Server,因为SQLite试图解决另外一个问题。

C/S SQL数据库引擎实现企业级数据共享,他们强调数据的可伸缩性,并发性,中心性和控制性;SQLite 为独立应用和设备提供本地化存储,它强调资源节约,高性能,可靠性,独立性和易用性。

SQLite不和C/S数据库引擎竞争,它的竞争对象是fopen() (Linux中打开文件的函数)![http://man.he.net/man3/fopen]

SQLite的完美应用场景

嵌入式设备和物联网

因为SQLite不需要管理,在不需要数据库管理员支持的场景下工作良好,SQLite在下面这些设备中都有很好的应用:移动电话、机顶盒、电视机、游戏控制器、摄像机、智能手表、厨房电器、恒温控制器、汽车、机床、飞机、遥控器、遥控飞机、医疗器械还有机器人。

C/S数据库引擎被设计来放在核心网的数据中心,SQLite也可以这样做,而且在在网络边缘(可以理解为小型应用)的应用SQLite正在壮大。

应用程序文件

(理解为一些应用程序产生的文件里面其实包含了一个SQLite数据库)
SQLite 经常被用来存放一些应用程序产生的文件的数据,例如版本控制系统、金融分析工具、剪辑套件的媒体目录、CAD文件包等等,一般用sqlite3_open()这个函数来打开数据库文件,当应用程序修改内容时会自动更新数据库,因此文件/保存按钮会显得有些多余。

网站(重点关注)

SQLite在小、中型流量的网站(绝大部分网站)上工作良好,SQLite 能够处理多少数据取决于网站有多少流量,通常来说,每天点击量在100K (10万)及以下的网站是没问题的,100K还是一个保守估计,不是一个硬上限,在实验中,SQLite 能够处理超过10倍的点击量(100k*10 = 100W)

SQLite官网!(https://www.sqlite.org/)就是用的SQLite,当然,在此篇文章写下之时(2015),它每天要处理40W到50W的HTTP请求,其中有15~20%是需要连接数据库的(50W * 20% = 10W,刚好和作者上文说的数据相吻合)动态内容,动态内容使用了超过200句的SQL!(https://www.sqlite.org/np1queryprob.html),这个测试跑在和其他23个虚拟机共享一个物理机的环境中,仍然在大多数时间使其负载为0.1(这段话可以这么理解:作者用了一个200句SQL的测试跑在一个虚拟机上,每天10W的点击量,在大多数时候仍然保持较低的负载,说白了作者想用数据强调SQLite非常强大)。

数据分析

人们都知道SQL可以用来分析大量的数据集,SQLite有内置和一系列第三方的SQL命令行工具,数据可以从CSV文件中导入,数据可以被用来切片或切块,可以生成大量的摘要报告;一些复杂的分析可以用编程语言写简单的脚本,这些语言包括Tcl、Python(内置了对SQLite的支持)、R等语言,你可以用SQLite来分析网站访问日志、体育统计分析、实验结果分析。一些生物研究分析也使用的SQLite。

分析这件事情也可以使用C/S数据库,当然,使用SQLite的好处是它只是一个文件,可以随意拷贝,比如拷贝到U盘中,或者email给同事。

企业数据缓存

(理解为将C/S数据库中的数据缓存一部分到SQLite中)
一些应用会从关系型数据库中缓存一部分数据到本地(存储到SQLite中),这样可以减少延迟,因为大部分查询将在本地进行避免网络的双向损耗,这样也可以减少网络的负载,在大多数情况中,意味着在网络切断的情况下应用可以继续工作(因为数据都缓存到本地了嘛~~)

服务器端数据库

(理解为服务端底层用的是SQLite作为数据库引擎,然后提供给客户端数据,类似于C/S架构)
服务器端底层用SQLite作为数据库引擎。

在这种模式下,整个系统仍然是C/S架构:客户机发送请求给服务器,服务器通过网络返回数据,但是请求不是普通的SQL请求,返回的也不是原始的数据,客户端的请求和服务端的回复是一个高层次的,按照客户端需要来进行返回的。服务端将客户端的请求翻译成多条SQL语句进行过滤分析处理,然后构建高层次的结果返回。
(这段感觉和网站后台没有什么区别,就像一个页面有许多统计分析指标,请求发到服务器端,构建复杂查询一样)

数据传送

(SQLite单文件数据的优势)
因为SQLite是单个文件,兼容各个操作系统平台,它经常被用来作为数据传输,从一个系统到另一个系统。发送者只需要将数据导入进一个SQLite文件并将此文件传送给接受者,接受者用SQL提取需要的数据即可。

文件归档/数据容器

(可以理解为将文件打包进SQLite数据,类似于ZIP那种压缩文件一样吗,不过其优点主要是能进行实时更新)
更多参考!(https://www.sqlite.org/sqlar/doc/trunk/README.md)

替换自定义数据文件

很多程序用fopen(),fread(),fwrite()创建自定义格式的数据文件,用SQLite来替换这些文件将会有更好的性能,一般来说,在读写文件时,SQLite比文件系统更快!

内存数据库或临时数据库

(理解为SQLite可作为内存数据库(具有快速,高效和临时性))
内存数据库始终放在内存中,断电就消失,临时数据库会在磁盘产生文件,程序结束时消失,临时数据库也是常驻内存,当数据量大的时候会将一部分数据放到磁盘上,这是和内存数据库的最大区别。

在演示或者测试的时候代理C/S数据库

(说白了,SQLite是单文件,演示的时候方便拷贝...,一般在没网的时候可以这么干)
通常情况下,数据库编程都是面向接口的,底层数据库改变不影响程序逻辑,如JAVA的JDBC编程。将SQLite包含在受支持的数据库中,并静态地将SQLite引擎链接到客户机中,这是很有意义的。这样,客户端程序就可以单独使用SQLite数据文件进行测试或演示。

教育与培训

因为SQLite使用起来很简单,安装也很简单(只需要将 sqlite3 或者 sqlite3.exe可执行文件拷贝到目标机器上),简单易用,学生可以很简单的创建他们喜欢的数据库并且可以方便的email给他们的老师用来评论和评分。也可以作为学习关系型数据库的基础。

实验性SQL语言扩展

(可以理解为SQLite模块化的设计很简单,可以实验性的增加现有SQL语句没有的功能)

C/S关系型数据库引擎更加试用的场景

C/S架构的应用

如果有很多客户端通过网络同时向服务器发送数据库查询请求,这种情况下用C/S数据库而非SQLite,因为网络有延迟,性能达不到最好,而且,许多操作系统(Unix和Windows都包含)的文件锁实现都有bug,如果文件锁错乱,并且此时有两个或者两个以上的客户端同时向数据库写内容,将会导致内容不一致,这是操作系统文件锁决定的,不是SQLite能解决的。

访问量巨大的网站

(大站有用SQLite?不可能的)
通常来说,SQLite可以作为网站服务器的后端,但是,如果是写密集型或者网站访问量很大的情况下,需要多个数据库服务器,那么考虑C/S数据库,而不是SQLite

数据量特别大

理论上来说SQLite支持最大单文件大小为128TB,但是许多文件系统都限制单个文件的大小,如果数据量特别大,还是考虑C/S数据库。

高并发

SQLite不限制并发读,但是每次只能有一次写,写的时候会上文件锁,在一些场景下,这不是个问题,因为吗,每一个写锁持续时间很短,不超过几十毫秒,但是有一些应用需要更好的并发性能,这就要考虑另外的解决方案了。

数据库选择正确与否检查表

  1. 数据是否通过网络与应用程序分离?-->> 如果是,请选C/S数据库
  2. 很多的并发写?-->> 如果是,请选C/S数据库
  3. 数据量超大?-->> 如果是,请选C/S数据库
  4. 其他情况? -->> 请选SQLite
Tags:none
上一篇
打赏
下一篇

添加新评论