sqlite的特点

1. ACID事务[1] 2. 零配置 – 无需安装和管理配置 3.储存在单一磁盘文件中的一个完整的数据库 4.数据库文件可以在不同字节顺序的机器间自由的共享 5.支持数据库大小至2TB 6. 足够小,大致13万行C代码,4.43M 7. 比一些流行的数据库在大部分普通数据库操作要快 8. 简单,轻松的API 9. 包含TCL绑定,同时通过Wrapper支持其他语言的绑定 10. 良好注释的源代码,并且有着90%以上的测试覆盖率 11. 独立: 没有额外依赖 12. 源码完全的开源,你可以用于任何用途,包括出售它 13. 支持多种开发语言，C,C++,PHP,Perl,Java,C#,Python,Ruby等 内存数据库：大数据时代数据管理新宠 在 2012中国系统架构师大会上，笔者曾做过一份有关大数据的调查，其中一项“在众多的技术趋势中，您所关注的数据管理的新技术是什么?”的调查结果中， “内存数据库”成为仅次于“分布式存储与计算”的最受关注的新技术。内存数据库之所以受到越来越多的关注，与其性能上的飞跃和性价比的不断提升有着密不可分的关系。 内存数据库，顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时，内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都在内存中重新设计了体系结构，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，所以数据处理速度比传统数据库的数据处理速度要快很多，一般都在10倍以上。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。 内存数据库与传统数据库的异同 内存数据库的目标是通过使用内存实现数据存储来提高吞吐量和降低延迟。这与使用磁盘存储的传统数据库管理系统不同，由于内部优化算法更简单，而且执行的CPU指令较少，所以内存内数据的速度比基于磁盘的数据库快。访问内存数据可以提高响应速度，对于一些响应时间要求较高的应用程序，如交易、电信和国防系统，一般都会使用内存数据库。由于内存数据库的这种特性，这些数据库使用内存要多于磁盘数据库产品。具体差别如下： 1. 传统的数据库系统是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。 2. 对磁盘数据库而言，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大，如果将整个数据库或其主要的“工作”部分放入内存，使每个事务在执行过程中没有I/O，则为系统较准确估算和安排事务的运行时间，使之具有较好的动态可预报性提供了有力的支持，同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。 3. 内存数据库所处理的数据通常是“短暂”的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价，处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。 在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。 ·SQLite SQLite是一款轻型的数据库，它占用资源非常的低，同时能够跟很多程序语言相结合，但是支持的SQL语句不会逊色于其他开源数据库。它的设计目标是嵌入式的，而且目前已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，比如Tcl、PHP、Java 等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款开源世界著名的数据库管理系统来讲，它的处理速度比他们都快。 ·Redis Redis是一款开源的、高性能的键-值存储 (key-value store)。它常被称作是一款数据结构服务器(data structure server)。Redis的键值可以包括字符串(strings)、哈希(hashes)、列表(lists)、集合(sets)和 有序集合(sorted sets)等数据类型。 对于这些数据类型，你可以执行原子操作。例如：对字符串进行附加操作(append);递增哈希中的值;向列表中增加元素;计算集合的交集、并集与差集等。 SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化: •易于管理 •易于使用 •易于嵌入其他大型程序 •易于维护和配置 许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点,使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单,越简单就越不容易出错. 除了上述的简单、小巧和稳定性外,最重要的在于SQLite力争做到简单化. 简单化在一个数据库引擎中可以说是一个优点,但也可能是个缺点,主要决定于你想要做什么. 为了达到简单化,SQLite省略了一些人们认为比较有用的特性,例如高并发性、 严格的存取控制、 丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展,超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性,那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎,也并不打算和Oracle或者PostgreSQL竞争. 仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库,而不是那些企业级数据库提供的不计其数的复杂功能的时候，使用SQLite是一个比较明智的选择. 事实也证明,人们在许多情况下已经清楚的认识到简单就是最好的选择. SQLite最佳试用场合 •网站 作为数据库引擎SQLite适用于中小规模流量的网站(也就是说,99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说,如果一个网站的点击率少于100000次/天的话,SQLite是可以正常运行的. 100000次/天是一个保守的估计,不是一个准确的上限. 事实证明,即使是10倍的上述流量的情况下SQLite依然可以正常运行. •嵌入式设备和应用软件 因为SQLite数据库几乎不需要管理,因此对于那些无人值守运行或无人工技术支持的设备或服务,SQLite是一个很好的选择. SQLite能很好的适用于手机,PDA,机顶盒,以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序. •应用程序文件格式 SQLite作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数，并且标记一个显式本地事务的起始点（BEGIN TRANSACTION）来保证以独占的方式得到文件的内容. 文件保存将执行一个提交（COMMIT）同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的. 数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码. •替代某些特别的文件格式 许多程序使用fopen(),fread(),或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择. •内部的或临时的数据库 对于那些有大量的数据需要用不同的方式筛选分类的程序,相对于编写同样功能的代码,如果你把数据读入一个内存中的SQLite数据库,然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据,通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性,因为添加新的列或索引不用重写任何查询语句. •命令行数据集分析工具 有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV（逗号分隔值文件）文件中导入,然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析,运动统计分析,编辑规划标准,分析试验结果. 当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件,你可以把它存储在软盘或者优盘或者直接通过email发给同事. •在Demo或测试版的时候作为企业级数据库的替代品 如果你正在编写一个使用企业级数据库引擎的客户端程序,使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中，从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证. •数据库教学 因为SQLite的安装和使用非常的简单(安装过程几乎忽略不计,只需要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机,然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库,然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统（RDBMS）的高层次的学生,按照模块化设计且拥有很好的注释和文档的SQLite源代码,将为他们打下良好的基础. 这并不是说SQLite就是如何实现其他数据库引擎的精确模型,但是很适合学生们了解SQLite是如何快速工作的,从而掌握其他数据库系统的设计实现原则. •试验SQL语言的扩展 SQLite简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台. 哪些场合适合使用其他的关系型数据库管理系统（RDBMS） •客户端/服务器程序 如果你有许多的客户端程序要通过网络访问一个共享的数据库,你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以通过网络文件系统工作,但是因为和大多数网络文件系统都存在延时,因此执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 如果文件锁没有正常的工作,就可能出现在同一时间两个或更多的客户端程序更改同一个数据库的同一部分,从而导致数据库出错. 因为这些问题是文件系统执行的时候本质上存在的bug,因此SQLite没有办法避免它们. 好的经验告诉我们,应该避免在许多计算机需要通过一个网络文件系统同时访问同一个数据库的情况下使用SQLite. •高流量网站 SQLite通常情况下用作一个网站的后台数据库可以很好的工作. 但是如果你的网站的访问量大到你开始考虑采取分布式的数据库部署,那么你应当毫不犹豫的考虑用一个企业级的客户端/服务器数据库来替代SQLite. •超大的数据集 当你在SQLite中开始一个事务处理的时候(事务处理会在任何写操作发生之前产生,而不是必须要显示的调用BEGIN...COMMIT),数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它自己管理回滚操作. 每1MB的数据库文件SQLite需要256字节. 对于小型的数据库这些空间不算什么,但是当数据库增长到数十亿字节的时候,缓冲页面的尺寸就会相当的大了. 如果你需要存储或修改几十GB的数据,你应该考虑用其他的数据库引擎. •高并发访问 SQLite对于整个数据库文件进行读取/写入锁定. 这意味着如果任何进程读取了数据库中的某一部分,其他所有进程都不能再对该数据库的任何部分进行写入操作. 同样的,如果任何一个进程在对数据库进行写入操作,其他所有进程都不能再读取该数据库的任何部分. 对于大多数情况这不算是什么问题. 在这些情况下每个程序使用数据库的时间都很短暂,并且不会独占,这样锁定至多会存在十几毫秒. 但是如果有些程序需要高并发,那么这些程序就需要寻找其他的解决方案了.