Sqlite3插入性能测试

Question

在高度并发的环境中SQLite块表丢失数据。我正在寻找通过高并发性来提高SQLite性能的方法，而不会丢失插入查询的数据。我的目的是知道插入的并发用户的限制，以便网站工作（在这种情况下为请求插入1）具有“高并发性”。为了使这个测试用例更简单，用户将发送数据以保存在数据库中

看看如何提高性能并使用其他用户的建议：

• sqlite.org
• sqlite.org/faq.html#q19
• stackoverflow.com/questions/1711631/how-do-i-improve-the-performance-of-sqlite
• stackoverflow.com/questions/54998/how-scalable-is-sqlite

我决定在一个亚马逊小实例中做一点测试。

平台

• Linux版本2.6.35.14-106.53.amzn1.i686（mockbuild@build-31003.build）（gcc版本4.4.5 20110214（Red Hat 4.4.5-6）（GCC））＃1 SMP Fri 1月6日16 ：20：23 UTC 2012
• Sqlite 3.6.20
• Lighttpd 1.4.29
• Php 5.3.10

test.php with insert sql：

  

PRAGMA synchronous = OFF;开始交易;插入test   （data1，date）VALUES（'“。$ _ POST ['data1']。”'，date（））;   结束交易;

使用Apache HTTP服务器基准测试工具。

数据库是文件系统中不在ram中的文件。

结论： 测试1：ab -n 10000 -c 50 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• 测试时间：63.637秒
• 完成请求：10000
• 请求失败：0
• Sqlite插入行：10050
• 平均值：159.52 insert / sg

测试2：ab -n 10000 -c 100 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• 测试时间：64.221秒
• 完成请求：10000
• 请求失败：0
• Sqlite插入行：10100
• 平均值：157.26 insert / sg

测试3：ab -n 10000 -c 150 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• 测试时间：33.338秒
• 完成请求：10000
• 请求失败：7095
• （连接：0，接收：0，长度：7095，例外：0）
• SQLITE：2905插入行
• 平均值：数据丢失!!

TEST4：ab -n 10000 -c 200 -k xxxx.xxx/test.php?data1=fc82bf71a0d5f8a3c2dc868ebe0d6eaa

• 测试时间：33.705秒
• 完成请求：10000
• 请求失败：7049
• （连接：0，接收：0，长度：7049，例外：0）
• SQLITE：2918插入行
• 平均值：数据丢失!!

在这个特定的环境中，我们可以使用SQLite最多100个并发用户，平均值为157.26 insert / sg。您考虑到此结果仅适用于插入数据。

从我的无知，有可能防止丢失数据？有可能改善这种表现吗？

Answer 1

我认为不应该在你的情况下使用Sqlite3。是的，sqlite3是很好地处理并发的嵌入式数据库之一，但为了提高性能并提高性能，我建议只使用服务器/客户端数据库。

让我们看一下你最后一次测试，你在大约30秒内发出10000个请求。如果它们是平均分配的，则每个事务不允许Sqlite3需要超过3毫秒（请记住，sqlite3一次只允许一个写入进程）。我们来看看sqlite文档。 （http://www.sqlite.org/faq.html）

  

我们知道没有其他支持as的嵌入式SQL数据库引擎   和SQLite一样多并发。 SQLite允许多个进程拥有   数据库文件立即打开，并为多个进程读取   数据库一下子。当任何进程想要写入时，它必须锁定   整个数据库文件的更新期间。但通常情况下   只需几毫秒。

总结：只需锁定数据库需要几毫秒，而不是谈论更新本身。

  

但是，客户端/服务器数据库引擎（例如PostgreSQL，MySQL或   Oracle）通常支持更高级别的并发和允许   多个进程要同时写入同一个数据库   时间。这在客户端/服务器数据库中是可能的，因为存在   始终是一个可以协调的良好控制的服务器进程   访问。如果您的应用程序需要大量并发，那么   您应该考虑使用客户端/服务器数据库。但经验   表明大多数应用程序需要的并发性要比它们少得多   设计师想象。

您有几种可能性：

• 更改应用程序的工作方式。你不太可能需要那么多的并发性。
• 如果您仍然坚持要求并发性和良好的性能，请切换到客户端/服务器数据库。
• 当您的负载达到峰值时，接受某些请求失败。