sqlitememory原理

SQLite创建的数据库有一种模式IN-MEMORY，但是它并不表示SQLite就成了一个内存数据库。IN-MEMORY模式可以简单地理解为，（2020 表述勘误：本来创建的数据库文件是基于磁盘的，现在整个文件使用内存空间来代替磁盘空间，没有了文件作为backingstore，不必在修改数据库后将缓存页提交到文件系统），其它 *** 作保持一致。也就是数据库的设计没有根本改变。

inmemory与tempdb是两种节约模式，节约的对象为（rollback）日志文件以及数据库文件，减少IO。inmemory将日志写在内存，并且去除数据库文件作为backingStore，缓存页不用提交到文件系统。tempdb只会在只会在脏的缓存页超过当前总量的25％才会同步刷写到文件，换句话说在临时数据库模式下，事务提交时并不总同步脏页，因此减少了IO数量，事务日志也受这种机制影响，所以在临时数据库模式下，事务日志是不是MEMORY并不重要。回过头来看，内存模式则是临时模式的一种极致，杜绝所有的IO。这两种模式都只能存在一个sqlite3连接，关闭时销毁。

提到内存，许多人就会简单地理解为，内存比磁盘速度快很多，所以内存模式比磁盘模式的数据库速度也快很多，甚至有人望文生意就把它变成等同于内存数据库。

它并不是为内存数据库应用而设计的，本质还是文件数据库。它的数据库存储文件有将近一半的空间是空置的，这是它的B树存储决定的，（2020 勘误：对于固定长度记录，页面使用率最大化，对于非自增计数键的索引，页面一般会保留20～60％的空间，方便插入）请参看上一篇SQLite存储格式。内存模式只是将数据库存储文件放入内存空间，但并不考虑最有效管理你的内存空间，其它临时文件也要使用内存，事务回滚日志一样要生成，只是使用了内存空间。它的作用应该偏向于临时性的用途。

（2020 补充：下面的测试有局限性，）

我们先来看一下下面的测试结果，分别往memory和disk模式的sqlite数据库进行1w, 10w以及100w条数据的插入，采用一次性提交事务。另外使用commit_hook捕捉事务提交次数。

（注：测试场景为在新建的数据库做插入 *** 作，所以回滚日志是很小的，并且无需要在插入过程中查找而从数据库加载页面，因此测试也并不全面）

内存模式



磁盘模式



在事务提交前的耗时 (事务提交后的总耗时)：

1w 10w 100w

内存模式 004s 035s 360s

磁盘模式 006s (027s) 047s (072s) 395s (462s)

可以看到当 *** 作的数据越少时，内存模式的性能提高得越明显，事务IO的同步时间消耗越显注。

上图还有一组数据比较，就是在单次事务提交中，如果要为每条插入语句准备的话

1w 10w 100w

内存模式 019s 192s 1946s

磁盘模式 021s (035s) 206s (226s) 1988s (2041s)

我们从SQLite的设计来分析，一次插入 *** 作，SQLite到底做了些什么。首先SQLite的数据库 *** 作是以页面大小为单位的。在单条记录插入的事务中，回滚日志文件被创建。在B树中查找目标页面，要读入一些页面，然后将目标页面以及要修改的父级页面写出到回滚日志。 *** 作目标页面的内存映像，插入一条记录，并在页面内重排序（索引排序，无索引做自增计数排序，参看上一篇《SQLite数据库存储格式》）。最后事务提交将修改的页面写出到数据库文件，成功后再删除日志文件。在这过程中显式进行了2次写磁盘（1次写日志文件，1次同步写数据库），还有2次隐式写磁盘（日志文件的创建和删除），这是在 *** 作目录节点。以及为查找加载的页面读 *** 作。更加详细可以参看官方文档的讨论章节《Atomic Commit In SQLite》。

如果假设插入100条记录，每条记录都要提交一次事务就很不划算，所以需要批量 *** 作来减少事务提交次数。假设页面大小为4KB，记录长度在20字节内，每页可放多于200条记录，一次事务提交插入100条记录，假设这100条记录正好能放入到同一页面又没有产生页面分裂，这样就可以在单条记录插入事务的IO开销耗损代价中完成100条记录插入。

当我们的事务中，插入的数据越多，事务的IO代价就会摊得越薄，所以在插入100w条记录的测试结果中，内存模式和磁盘模式的耗时都十分接近。实际应用场合中也很少会需要一次插入100w的数据。有这样的需要就不要考虑SQLite。

（补充说明一下，事务IO指代同步数据库的IO，以及回滚日志的IO，只在本文使用）

除了IO外，还有没有其它地方也影响着性能。那就是语句执行。其实反观一切，都是在对循环进行优化。



for (i = 0; i < repeat; ++i)

{

exec("BEGIN TRANS");

exec("INSERT INTO ");

exec("END TRANS");

}



批量插入：



exec("BEGIN TRANS");

for (i = 0; i < repeat; ++i)

{

exec("INSERT INTO ");

}

exec("END TRANS");



当我们展开插入语句的执行



exec("BEGIN TRANS");

for (i = 0; i < repeat; ++i)

{

// unwind exec("INSERT INTO ");

prepare("INSERT INTO ");

bind();

step();

finalize();

}

exec("END TRANS");



又发现循环内可以移出部分语句



exec("BEGIN TRANS");

// unwind exec("INSERT INTO ");

prepare("INSERT INTO ");

for (i = 0; i < repeat; ++i)

{

bind();

step();

}

finalize();

exec("END TRANS");



这样就得到了批量插入的最终优化模式。

所以对sql语句的分析，编译和释放是直接在损耗CPU，而同步IO则是在饥饿CPU。

请看下图



分别为内存模式1w和10w两组测试，每组测试包括4项测试

1只编译一条语句，只提交一次事务

2每次插入编译语句，只提交一次事务

3只编译一条语句，但使用自动事务。

4每次插入编译语句，并使用自动事务。

可以看到测试项目4基本上就是测试项目2和测试项目3的结果的和。

测试项目1就是批量插入优化的最终结果。

下面是探讨内存模式的使用：

经过上面的分析，内存模式在批量插入对比磁盘模式提升不是太显注的，请现在开始关注未批量插入的结果。

下面给出的是磁盘模式01w和02w两组测试，每组测试包括4项测试



可以看到在非批量插入情况，sqlite表现很差要100秒来完成1000次单条插入事务，但绝非sqlite很吃力，因为cpu在空载，IO阻塞了程序。

再来看内存模式20w测试



可以看到sqlite在内存模式，即使在20w次的单条插入事务，其耗时也不太逊于磁盘模式100w插入一次事务。

01w 02w 20w

内存模式（非批量插入） 1587s

磁盘模式（非批量插入） 974s 19828s

编译1次插入语句 每次插入编译1次语句

内存模式（20w，20w次事务） 1110s 1587s

磁盘模式（100w，1次事务） 462s 2041s

1 十五年内存数据库的历史,成熟稳定的产品

TimesTen 源于1992年HP试验室，当时主要目的是针对电信网络应用，使用内存数据库技术进行一些深入研究，于1996年，由该团队核心人员成立独立运作公司，并在1996年发布TimesTen第一个商用版本（TimesTen20），2001年，产品中增加Cache Connect组件，以至产品可以和Oracle无缝集成，2005年由Oracle收购，到今天为止，该产品已经有15年历史，有多达11个主要的发布版本产生，全球已经有1500+的企业用户。

2 性能高效--闪电式的反应速度,极高的并行吞吐量

Oracle TimesTen In-Memory Database 通过将应用库嵌入到应用程序内部，从而消除了上下文切换和不必要的网络 *** 作，大大提高了数据访问性能，并通过在内存中管理数据并相应地优化数据结构和访问算法，同传统的基于硬盘的关系数据库相比, 即使把要访问的数据从硬盘全部缓存到关系数据库的内存中(如Oracle SGA的数据缓存Data Buffer), 无论从响应性和吞吐率, timesten都有显著的提升。实时数据管理有两个性能维度 — 响应时间和并行吞吐率。使用 Oracle TimesTen In-Memory Database，读取一条数据库记录的事务将花费不到 9 微秒的时间（1 微秒等于 1 百万分之一秒），而更新或插入一条记录的事务将花费不到 28微秒的时间。因此，即使在拥有很少处理器的系统上，吞吐率也是以每秒上万到上十万事务计的。

3 与oracle无缝集成，无需编码即可实现与Oracle双向同步

Cache Connect to Oracle 是 Oracle TimesTen In- Memory Database 的一个选项，它为位于应用程序层中的 Oracle 数据创建实时、可更新的高速缓存。它免除了后端系统的计算负担，并支持反应灵敏且可伸缩的实时应用程序。Cache Connect to Oracle 能够将 Oracle 数据的子集（可以选择您需要装载的表或者指定表的某些列）加载到 TimesTen 中，无需任何编码就能够实现双向数据同步更新，从而实现和Oracle无缝集成。转载，仅供参考。

支持iSCSI、FC、NFS、CIFS、>

内存数据库从范型上可以分为关系型内存数据库和键值型内存数据库。在实际应用中内存数据库主要是配合oracle或mysql等大型关系数据库使用，关注性能。

作用类似于缓存，并不注重数据完整性和数据一致性。

基于键值型的内存数据库比关系型更加易于使用，性能和可扩展性更好，因此在应用上比关系型的内存数据库使用更多。

比较FastDB、Memcached和Redis主流内存数据库的功能特性。

FastDB的特点包括如下方面：

1、FastDB不支持client-server架构因而所有使用FastDB的应用程序必须运行在同一主机上；

2、fastdb假定整个数据库存在于RAM中，并且依据这个假定优化了查询算法和接口。

3、fastdb没有数据库缓冲管理开销，不需要在数据库文件和缓冲池之间传输数据。

4、整个fastdb的搜索算法和结构是建立在假定所有的数据都存在于内存中的，因此数据换出的效率不会很高。

5、Fastdb支持事务、在线备份以及系统崩溃后的自动恢复。

6、fastdb是一个面向应用的数据库，数据库表通过应用程序的类信息来构造。

FastDB不能支持Java API接口，这使得在本应用下不适合使用FastDB。

Memcached

Memcached是一种基于Key-Value开源缓存服务器系统，主要用做数据库的数据高速缓冲，并不能完全称为数据库。

memcached的API使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以LRU机制替换掉。由于 memcached通常只是当作缓存系统使用，所以使用memcached的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程序更新memcached内的资料。

memcached具有多种语言的客户端开发包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。

Redis

Redis是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客户端。

以上就是关于sqlitememory原理全部的内容，包括:sqlitememory原理、为什么选用Oracle TimesTen In-Memory Database、华为数据库一体机支持哪些存储协议等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！