SQLite的性能基准 – 为什么是：内存：这么慢…只有磁盘的1.5倍速度？
为什么是：内存：在sqlite这么慢？
我一直在试图看看是否有任何使用内存中的sqlite与基于磁盘的sqlite获得的性能改进。 基本上我想交换启动时间和内存来获得非常快速的查询，在应用程序的过程中没有打到磁盘。
但是，下面的基准testing结果只是提高了速度的1.5倍。 在这里，我生成了1M行随机数据，并将其加载到同一个表的磁盘和基于内存的版本中。 然后我在这两个dbs上运行随机查询，返回约300k大小的集合。 我预计基于内存的版本要快得多，但如前所述，我只能获得1.5倍的加速。
我尝试了几个其他大小的数据库和查询集; 内存的好处：似乎随着数据库中行数的增加而增加。 我不确定为什么这个优势太小，尽pipe我有一些假设：
- 所使用的表格不够大（在行中）：内存：一个巨大的赢家
- 更多的连接/表格将使得：内存：优势更加明显
- 在连接或操作系统级别上存在某种caching，从而可以以某种方式访问先前的结果，从而破坏基准
- 有什么隐藏的磁盘访问正在进行，我没有看到（我还没有尝试LSF，但我没有closuresPRAGMA的日记）
我在这里做错了什么？ 任何想法，为什么：内存：不产生几乎即时查找？ 这是基准：
==> sqlite_memory_vs_disk_benchmark.py <== #!/usr/bin/env python """Attempt to see whether :memory: offers significant performance benefits. """ import os import time import sqlite3 import numpy as np def load_mat(conn,mat): c = conn.cursor() #Try to avoid hitting disk, trading safety for speed. #http://stackoverflow.com/questions/304393 c.execute('PRAGMA temp_store=MEMORY;') c.execute('PRAGMA journal_mode=MEMORY;') # Make a demo table c.execute('create table if not exists demo (id1 int, id2 int, val real);') c.execute('create index id1_index on demo (id1);') c.execute('create index id2_index on demo (id2);') for row in mat: c.execute('insert into demo values(?,?,?);', (row[0],row[1],row[2])) conn.commit() def querytime(conn,query): start = time.time() foo = conn.execute(query).fetchall() diff = time.time() - start return diff #1) Build some fake data with 3 columns: int, int, float nn = 1000000 #numrows cmax = 700 #num uniques in 1st col gmax = 5000 #num uniques in 2nd col mat = np.zeros((nn,3),dtype='object') mat[:,0] = np.random.randint(0,cmax,nn) mat[:,1] = np.random.randint(0,gmax,nn) mat[:,2] = np.random.uniform(0,1,nn) #2) Load it into both dbs & build indices try: os.unlink('foo.sqlite') except OSError: pass conn_mem = sqlite3.connect(":memory:") conn_disk = sqlite3.connect('foo.sqlite') load_mat(conn_mem,mat) load_mat(conn_disk,mat) del mat #3) Execute a series of random queries and see how long it takes each of these numqs = 10 numqrows = 300000 #max number of ids of each kind results = np.zeros((numqs,3)) for qq in range(numqs): qsize = np.random.randint(1,numqrows,1) id1a = np.sort(np.random.permutation(np.arange(cmax))[0:qsize]) #ensure uniqueness of ids queried id2a = np.sort(np.random.permutation(np.arange(gmax))[0:qsize]) id1s = ','.join([str(xx) for xx in id1a]) id2s = ','.join([str(xx) for xx in id2a]) query = 'select * from demo where id1 in (%s) AND id2 in (%s);' % (id1s,id2s) results[qq,0] = round(querytime(conn_disk,query),4) results[qq,1] = round(querytime(conn_mem,query),4) results[qq,2] = int(qsize) #4) Now look at the results print " disk | memory | qsize" print "-----------------------" for row in results: print "%.4f | %.4f | %d" % (row[0],row[1],row[2]) 结果如下。 请注意，只要内存空间相当广泛，查询大小就会占用大约1.5倍的磁盘空间。
[ramanujan:~]$python -OO sqlite_memory_vs_disk_clean.py disk | memory | qsize ----------------------- 9.0332 | 6.8100 | 12630 9.0905 | 6.6953 | 5894 9.0078 | 6.8384 | 17798 9.1179 | 6.7673 | 60850 9.0629 | 6.8355 | 94854 8.9688 | 6.8093 | 17940 9.0785 | 6.6993 | 58003 9.0309 | 6.8257 | 85663 9.1423 | 6.7411 | 66047 9.1814 | 6.9794 | 11345
内存不应该几乎相对于磁盘瞬间？ 这里怎么了？
编辑
这里有一些好的build议。
我认为对我来说，主要的关键点是**可能没有办法做到：内存： 绝对更快 ，但有一种方法可以使磁盘访问相对较慢。 **
换句话说，基准testing是充分衡量内存的真实性能，而不是磁盘的真实性能（例如，因为cache_size附注太大或者因为我没有写入）。 当我有机会的时候，我会乱搞这些参数并发表我的发现。
也就是说，如果有人认为我可以从内存数据库中挤出更多的速度（除了将cache_size和default_cache_size，我会这样做）
这与SQLite有一个页面caching的事实有关。 根据文档 ，默认的页面caching是2000个1K页面或大约2Mb。 由于这是大约75％到90％的数据，所以这两个数字非常相似就不足为奇了。 我的猜测是，除了SQLite页面caching之外，其余的数据仍然在OS磁盘caching中。 如果你有SQLite刷新页面caching（和磁盘caching），你会看到一些非常显着的差异。
我对你的问题是，你想要testing什么？
正如已经提到的，SQLite的：memory：DB与基于磁盘的一样，即分页，唯一的区别是页面永远不会被写入磁盘。 所以两者之间的唯一区别是磁盘写入：内存：不需要做（当磁盘页必须从caching中卸载时，也不需要做任何磁盘读操作）。
但是，根据查询，从caching读取/写入可能仅表示查询处理时间的一小部分。 您的查询具有一个where子句，其中包含两个大的ID集合，所选的行必须是成员，这很昂贵。
正如Cary Millsap在他的关于优化Oracle的博客中所展示的（这里是一个代表性的post： http : //carymillsap.blogspot.com/2009/06/profiling-with-my-boy.html ），您需要了解查询的哪些部分处理需要时间。 假设设置的成员资格testing占查询时间的90％，而基于磁盘的IO为10％，则：memory：仅保存这10％。 这是一个不太可能具有代表性的极端例子，但是我希望这可以说明你的特定查询是倾斜的结果。 使用更简单的查询，并且查询处理的IO部分将会增加，从而得到：memory：的好处。
最后，我们尝试了SQLite的虚拟表，在这里你负责实际的存储，并且使用C ++容器，这种types不同于SQLite存储单元值的方式，我们可以看到在处理时间上的重大改进结束：内存：，但这是主题了一点;）–DD
PS：我没有足够的噶评论这个线程最stream行的post，所以我在这里评论:)说，最近的SQLite版本不使用1KB的默认在Windows上： http：// www。 sqlite.org/changes.html#version_3_6_12
你正在做SELECT，你正在使用内存caching。 尝试将SELECT与UPDATE交错。
SQLite中的内存数据库实际上是从不接触磁盘的页面caching。 所以你应该忘记在SQLite中使用内存数据库来调整性能
可以closures日志，closures同步模式，设置大页面caching，并且在大多数操作中您将具有几乎相同的性能，但耐久性将会丢失。
从你的代码中可以清楚地看出，你应该重新使用命令和ONLY BIND参数，因为这占用了超过90％的testing性能。
感谢您的代码。 我已经在2个XEON 2690上testing了192GB内存和4个RAID 5的SCSI 15k硬盘，结果是：
disk | memory | qsize ----------------------- 6.3590 | 2.3280 | 15713 6.6250 | 2.3690 | 8914 6.0040 | 2.3260 | 225168 6.0210 | 2.4080 | 132388 6.1400 | 2.4050 | 264038
内存的速度增加是显着的。
难道是sqlite3实际上是从caching写入你的数据到磁盘？ 这也许可以解释为什么数字是相似的。
由于内存不足，您的操作系统也可能会被分页？
我注意到你正在专注于涉及相对较大的数据集的查询返回。 我想知道用更小的数据集可以看到什么效果？ 多次返回单行可能需要磁盘寻找很多 – 内存的随机访问时间可能会更快。
numpy数组比字典和元组以及其他对象序列要慢，直到你处理一个序列中的500万或更多的对象。 通过遍历它并使用生成器来避免创build和重新创build临时大对象，可以显着提高处理大量数据的速度。
numpy已成为您的限制因素，因为它旨在提供线性性能。 这不是一个小数据量甚至大数据量的明星。 但是随着数据集的增长，numpy的性能不会变成曲线。 它仍然是一条直线。
除了SQLite只是一个非常快的数据库。 比大多数服务器数据库更快。 它引出了一个问题，为什么有人会使用NOSQL数据库，当一个使用SQL的轻量级超快速容错数据库已经出现并经过多年的testing，从浏览器到手机。
