53

为什么 :memory: 在 sqlite 中这么慢?

我一直在尝试查看使用内存中的 sqlite 与基于磁盘的 sqlite 是否有任何性能改进。基本上我想交换启动时间和内存以获得在应用程序过程中不会命中磁盘的非常快速的查询。

然而,下面的基准测试只给了我 1.5 倍的速度提升。在这里,我生成 1M 行随机数据并将其加载到同一个表的基于磁盘和内存的版本中。然后我在两个数据库上运行随机查询,返回大小约为 300k 的集合。我预计基于内存的版本会快得多,但如前所述,我只能获得 1.5 倍的加速。

我尝试了几种其他大小的数据库和查询集;:memory: 的优势似乎随着数据库中行数的增加而增加。我不确定为什么优势如此之小,尽管我有一些假设:

  • 使用的表不够大(按行),无法制作:memory:一个巨大的赢家
  • 更多的连接/表将使 :memory: 优势更加明显
  • 在连接或操作系统级别进行了某种缓存,以便可以以某种方式访问​​先前的结果,从而破坏了基准
  • 有某种我没有看到的隐藏磁盘访问正在进行(我还没有尝试过 lsof,但我确实关闭了 PRAGMAs 进行日志记录)

我在这里做错了吗?关于为什么 :memory: 没有产生几乎即时查找的任何想法?这是基准:

==> 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

相对于磁盘,RAM 不应该几乎是即时的吗?这里出了什么问题?

编辑

这里有一些很好的建议。

我想对我来说主要的要点是**可能没有办法使 :memory:绝对更快,但是有一种方法可以使磁盘访问相对较慢。**

换句话说,基准测试充分测量了内存的实际性能,但没有测量磁盘的实际性能(例如,因为 cache_size pragma 太大或者因为我没有进行写入)。当我有机会时,我会弄乱这些参数并发布我的发现。

也就是说,如果有人认为我可以从内存数据库中挤出一些更快的速度(除了提高 cache_size 和 default_cache_size,我会这样做),我全神贯注......

4

8 回答 8

42

这与 SQLite 具有页面缓存这一事实有关。根据文档,默认页面缓存为 2000 个 1K 页面或大约 2Mb。由于这大约是您数据的 75% 到 90%,因此这两个数字非常相似也就不足为奇了。我的猜测是,除了 SQLite 页面缓存之外,其余数据仍在 OS 磁盘缓存中。如果您让 SQLite 刷新页面缓存(和磁盘缓存),您会看到一些非常显着的差异。

于 2009-04-19T02:57:03.670 回答
22

我对你的问题是,你想以什么为基准?

如前所述,SQLite 的 :memory: DB 与基于磁盘的 DB 相同,即分页,唯一的区别是页面永远不会写入磁盘。因此,两者之间的唯一区别是磁盘写入 :memory: 不需要这样做(当必须从缓存中卸载磁盘页面时,它也不需要进行任何磁盘读取)。

但是从缓存中读取/写入可能只代表查询处理时间的一小部分,具体取决于查询。您的查询有一个 where 子句,其中包含两个大组 id,所选行必须是其中的成员,这很昂贵。

正如 Cary Millsap 在他关于优化 Oracle 的博客中演示的那样(这里有一篇代表性文章:http ://carymillsap.blogspot.com/2009/06/profiling-with-my-boy.html ),您需要了解查询的哪些部分处理需要时间。假设集合成员测试占查询时间的 90%,基于磁盘的 IO 占 10%,转到:memory: 只会节省这 10%。这是一个不太可能具有代表性的极端示例,但我希望它说明您的特定查询使结果倾斜。使用更简单的查询,查询处理的 IO 部分会增加,从而带来 :memory: 的好处。

最后一点,我们已经对 SQLite 的虚拟表进行了实验,您负责实际存储,并且通过使用 C++ 容器(其类型不同于 SQLite 存储单元格值的方式),我们可以看到处理时间的显着改进结束:记忆:,但这有点话题;)--DD

PS:我没有足够的业力来评论这个线程最受欢迎的帖子,所以我在这里评论:) 说最近的 SQLite 版本在 Windows 上默认不使用 1KB 页面:http://www。 sqlite.org/changes.html#version_3_6_12

于 2009-06-29T00:45:03.537 回答
7

您正在执行 SELECT,您正在使用内存缓存。尝试将 SELECT 与 UPDATE 交错。

于 2009-04-19T09:38:08.683 回答
7

SQLite 中的内存数据库实际上是从不接触磁盘的页面缓存。所以你应该忘记在 SQLite 中使用 memory db 来进行性能调整

可以关闭日志、关闭同步模式、设置大页面缓存,您在大多数操作上的性能几乎相同,但会丢失持久性。

从您的代码中可以清楚地看出,您应该重用命令并仅绑定参数,因为这会占用您90% 以上的测试性能。

于 2009-04-26T09:07:26.687 回答
6

谢谢你的代码。我已经在 2 x XEON 2690 和 192GB RAM 和 RAID 5 中的 4 个 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

内存的速度增加是显着的。

于 2012-05-01T20:43:36.887 回答
1

难道是 sqlite3 实际上并没有将数据从缓存写入磁盘?这可以解释为什么这些数字相似。

由于可用内存不足,您的操作系统也可能正在分页?

于 2009-04-19T02:40:29.153 回答
1

我注意到您专注于涉及要返回的相对较大数据集的查询。我想知道使用较小的数据集会产生什么影响?多次返回单行可能需要磁盘进行多次搜索——内存的随机访问时间可能会快得多。

于 2009-04-19T02:40:59.463 回答
1

numpy 数组比 dict 和 tuple 以及其他对象序列慢,直到您处理序列中的 500 万个或更多对象。您可以通过迭代大量数据并使用生成器来避免创建和重新创建临时大对象,从而显着提高处理大量数据的速度。

numpy 已成为您的限制因素,因为它旨在提供线性性能。它不是数据量小甚至大量的明星。但是numpy的性能并没有随着数据集的增长而变成曲线。它仍然是一条直线。

此外 SQLite 只是一个非常快速的数据库。甚至比大多数服务器数据库还要快。这就引出了一个问题,当使用 SQL 的轻量级超快速容错数据库已经出现并在从浏览器到手机的各种应用中进行了多年测试时,为什么会有人使用 NOSQL 数据库。

于 2011-10-21T15:04:28.600 回答