Question

为什么：内存：在sqlite中这么慢？

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

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

我尝试了几种其他大小的dbs和查询集;优点：内存：似乎随着db中行数的增加而上升。我不确定为什么优势如此之小，尽管我有一些假设：

使用的表格不够大（在行中）：内存：一个巨大的赢家
更多联接/表将使：内存：优势更明显
在连接或操作系统级别进行某种缓存，以便以某种方式访问以前的结果，从而破坏基准
有一些隐藏的磁盘访问正在进行中，我没有看到（我还没有尝试过lsof，但我确实关闭了PRAGMAs以进行日记）

我在这里做错了吗？关于原因的任何想法：内存：不会产生几乎即时的查找？这是基准：

==> 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不应该相对于磁盘几乎是即时的吗？这里出了什么问题？

修改

这里有一些好的建议。

我认为对我而言主要的观点是**可能无法做出：内存：绝对更快，但有一种方法可以使磁盘访问相对较慢。< / em> **

换句话说，基准测试正在充分测量内存的实际性能，但不能测量磁盘的实际性能（例如，因为cache_size编译指示太大或者因为我没有写入）。当我有机会时，我会把这些参数搞得一团糟并发布我的发现。

那就是说，如果有人认为我可以从内存数据库中挤出更多的速度（除了通过升级cache_size和default_cache_size，我将会这样做），我全都耳朵......

Answer 1

这与SQLite有页面缓存这一事实有关。根据{{3}}，默认页面缓存是2000个1K页面或大约2Mb。由于这大约是您数据的75％到90％，因此这两个数字非常相似并不奇怪。我的猜测是，除了SQLite页面缓存之外，其余数据仍然在OS磁盘缓存中。如果你有SQLite来刷新页面缓存（和磁盘缓存），你会发现一些非常重要的差异。

Answer 2

我的问题是，你打算做什么标杆？

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

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

正如Cary Millsap在他的博客中演示优化Oracle（这里是一篇代表性帖子：http://carymillsap.blogspot.com/2009/06/profiling-with-my-boy.html），您需要了解查询处理的哪些部分需要时间。假设集合成员资格测试占查询时间的90％，而基于磁盘的IO占10％，则：内存：仅保存10％。这是一个不太具有代表性的极端例子，但我希望它说明您的特定查询倾斜结果。使用更简单的查询，查询处理的IO部分将增加，从而获益：memory：。

作为最后一点，我们已经尝试了SQLite的虚拟表，您负责实际存储，并且使用C ++容器，这些容器的类型与SQLite存储单元格值的方式不同，我们可以看到显着的改进在处理时间：内存：，但这是主题的一点点;）--DD

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

Answer 3

你正在做SELECT，你正在使用内存缓存。尝试将SELECT与UPDATE交错。

Answer 4

SQLite中的内存数据库实际上是永远不会触及磁盘的页面缓存。因此，您应该忘记在SQLite中使用内存数据库进行性能调整

可以关闭日志，关闭同步模式，设置大页面缓存，大多数操作都会有相同的性能，但耐用性会丢失。

从您的代码中可以清楚地看出，应该重新使用命令和仅限BIND参数，因为这会使超过90％的测试性能消失。

Answer 5

感谢您的代码。我已经在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

记忆速度的提升非常显着。

Answer 6

是不是sqlite3实际上没有从缓存中将数据写入磁盘？这可能解释了为什么数字相似。

由于内存不足，您的操作系统也可能正在进行寻呼？

Answer 7

我注意到您正在关注涉及相对较大的数据集的查询。我想知道你会用较小的数据集看到什么效果？要多次返回单行可能需要磁盘寻求很多 - 内存的随机访问时间可能要快得多。

Answer 8

现在是 2021 年，与磁盘文件相比，我看到内存数据库的性能提高了 100 倍。见https://stackoverflow.com/a/67162316/317797

Answer 9

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

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

除了SQLite之外，它只是一个非常快速的数据库。甚至比大多数服务器数据库更快。它引出了一个问题，即为什么有人会使用NOSQL数据库时，使用SQL的轻量级超快速容错数据库已经存在并且在从浏览器到移动电话的所有内容中进行了多年的测试。

SQLite性能基准 - 为什么：内存：这么慢......只有磁盘的1.5倍速度？

为什么：内存：在sqlite中这么慢？

修改

9 个答案: