ram*_*jan 48 python database memory sqlite benchmarking
我一直试图看看使用内存中的sqlite和基于磁盘的sqlite是否有任何性能改进.基本上我想交换启动时间和内存来获得非常快速的查询,这些查询在应用程序过程中没有遇到磁盘.
但是,以下基准测试只能提高1.5倍的速度.在这里,我正在生成1M行随机数据并将其加载到同一个表的磁盘和基于内存的版本中.然后我在两个dbs上运行随机查询,返回大小约为300k的集合.我预计基于内存的版本要快得多,但如上所述,我只能获得1.5倍的加速.
我尝试了几种其他大小的dbs和查询集; 内存:优势也似乎上升为行的分贝数增加了.我不确定为什么优势如此之小,尽管我有一些假设:
我在这里做错了吗?关于原因的任何想法:内存:不会产生几乎即时的查找?这是基准:
==> 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])
Run Code Online (Sandbox Code Playgroud)
这是结果.请注意,对于相当广泛的查询大小,磁盘大约需要内存的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
Run Code Online (Sandbox Code Playgroud)
RAM不应该相对于磁盘几乎是即时的吗?这里出了什么问题?
这里有一些好的建议.
我想主要的观点是**可能没有办法:内存:绝对更快,但有一种方法可以使磁盘访问速度相对较慢.**
换句话说,基准测试正在充分测量内存的实际性能,但不能测量磁盘的实际性能(例如,因为cache_size编译指示太大或者因为我没有写入).当我有机会时,我会把这些参数搞得一团糟并发布我的发现.
也就是说,如果有人认为我可以从内存数据库中挤出更多速度(除了通过升级cache_size和default_cache_size,我将会这样做),我全都耳朵......
dde*_*nne 20
我的问题是,你想要做什么标杆?
正如已经提到的,SQLite的:memory:DB与基于磁盘的DB相同,即分页,唯一的区别是页面永远不会写入磁盘.因此,两者之间的唯一区别是磁盘写入:内存:不需要做(当磁盘页面必须从缓存中卸载时,它也不需要进行任何磁盘读取).
但是,从缓存中读取/写入可能只代表查询处理时间的一小部分,具体取决于查询.您的查询有一个where子句,其中包含两组大的id,所选行必须是其成员,这很昂贵.
由于卡里米尔萨普在他的博客中展示了优化的Oracle(这里有一个代表职务:http://carymillsap.blogspot.com/2009/06/profiling-with-my-boy.html),你需要了解哪些查询的部分处理需要时间.假设集合成员资格测试代表查询时间的90%,而基于磁盘的IO代表10%,则:内存:仅保存10%.这是一个不太具有代表性的极端例子,但我希望它说明您的特定查询倾斜结果.使用更简单的查询,并且查询处理的IO部分将增加,从而受益:memory:.
最后一点,我们使用SQLite的虚表,您身在何处负责实际的存储空间,并通过使用C++的容器,这是不同于存储单元格的值的SQLite的方式输入时,我们都可以看到处理时间的显著improment结束:记忆:,但这有点话题;)--DD
PS:我没有足够的业力来评论这个帖子最受欢迎的帖子,所以我在这里评论:)说最近的SQLite版本默认情况下在Windows上不使用1KB页面:http:// www. sqlite.org/changes.html#version_3_6_12
SQLite中的内存数据库实际上是永远不会触及磁盘的页面缓存.所以你应该忘记在SQLite中使用内存db来进行性能调整
可以关闭日志,关闭同步模式,设置大页面缓存,在大多数操作中您将获得几乎相同的性能,但耐用性将会丢失.
从您的代码中可以清楚地看出,您应该重新使用命令和ONLY BIND参数,因为这样可以消除90%以上的测试性能.
谢谢你的代码.我已经在2 x XEON 2690上测试了带有192GB RAM和4个SCSI 15k硬盘的RAID 5,结果如下:
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
Run Code Online (Sandbox Code Playgroud)
内存的速度提升很重要.