我做了一个简单的整数更新性能测试。 SQLite每秒只做15次更新，而PostgreSQL每秒只做1500次更新。
SQLite案例的数字似乎是normal。
SQLite网站中的FAQ解释说它好像是旋转磁盘的基本限制。
实际上，SQLite将轻松地执行50,000或更多INSERT语句 在普通台式电脑上排名第二。但它只会做几打 每秒交易量。交易速度受到限制 磁盘驱动器的转速。交易通常需要 磁盘盘片的两个完整旋转，在7200RPM磁盘上 驱动器限制您每秒约60个事务。交易 速度受磁盘驱动器速度的限制，因为（默认情况下）SQLite 实际上等待直到数据真正安全地存储在磁盘上 交易完成前的表面。那样，如果你突然 失去电力或者如果您的操作系统崩溃，您的数据仍然是安全的。对于 详细信息，请阅读SQLite中的原子提交..
默认情况下，每个INSERT语句都是自己的事务。但如果你 用BEGIN ... COMMIT包围多个INSERT语句然后全部 插入被分组到单个事务中。需要的时间 提交事务在所有随附的插入中摊销 语句，因此每个插入语句的时间大大减少。
另一种选择是运行PRAGMA synchronous = OFF。这个命令会 导致SQLite不等待数据到达磁盘表面，这将是 使写操作看起来更快。但如果你失去了力量 在事务中，您的数据库文件可能已损坏。
这个描述是真的吗？那么，PostgreSQL如何比SQLite更快地执行？
（我在PostgreSQL中将fsync和synchronous_commit选项都设置为on
更新：
这是用Clojure编写的完整测试代码：
(defproject foo "0.1.0-SNAPSHOT"
:repositories {"sonatype-oss-public" "https://oss.sonatype.org/content/groups/public/"}
:dependencies [[org.clojure/clojure "1.5.1"]
[org.clojure/java.jdbc "0.3.0-SNAPSHOT"]
[com.mchange/c3p0 "0.9.2.1"]
[org.xerial/sqlite-jdbc "3.7.2"]
[postgresql "9.1-901.jdbc4"]])
(ns foo.core
(:require [clojure.java.jdbc :as jdbc]
[clojure.java.jdbc.ddl :as ddl])
(:import [com.mchange.v2.c3p0 ComboPooledDataSource]))
(def sqlite
(let [spec {:classname "org.sqlite.JDBC"
:subprotocol "sqlite"
:subname "test.db"}]
{:datasource (doto (ComboPooledDataSource.)
(.setDriverClass (:classname spec))
(.setJdbcUrl (str "jdbc:" (:subprotocol spec) ":" (:subname spec)))
(.setMaxIdleTimeExcessConnections (* 30 60))
(.setMaxIdleTime (* 3 60 60)))}))
(def postgres
(let [spec {:classname "org.postgresql.Driver"
:subprotocol "postgresql"
:subname "//localhost:5432/testdb"
:user "postgres"
:password "uiop"}]
{:datasource (doto (ComboPooledDataSource.)
(.setDriverClass (:classname spec))
(.setJdbcUrl (str "jdbc:" (:subprotocol spec) ":" (:subname spec)))
(.setUser (:user spec))
(.setPassword (:password spec))
(.setMaxIdleTimeExcessConnections (* 30 60))
(.setMaxIdleTime (* 3 60 60)))}))
(doseq [x [sqlite postgres]]
(jdbc/db-do-commands x
(ddl/create-table :foo [:id :int "PRIMARY KEY"] [:bar :int])))
(doseq [x [sqlite postgres]]
(jdbc/insert! x :foo {:id 1 :bar 1}))
(defmacro bench
[expr n]
`(dotimes [_# 3]
(let [start# (. System (nanoTime))]
(dotimes [_# ~n]
~expr)
(let [end# (. System (nanoTime))
elapsed# (/ (double (- end# start#)) 1000000.0)
operation-per-sec# (long (/ (double ~n) (/ (double (- end# start#)) 1000000000)))]
(prn (str "Elapsed time: " elapsed# " ms (" (format "%,d" operation-per-sec#) " ops)"))))))
(bench (jdbc/query sqlite ["select * from foo"]) 20000)
(bench (jdbc/execute! sqlite ["update foo set bar=bar+1 where id=?" 1]) 100)
(bench (jdbc/query postgres ["select * from foo"]) 20000)
(bench (jdbc/execute! postgres ["update foo set bar=bar+1 where id=?" 1]) 5000)
输出是：
; Running "select * from foo" 20000 times in SQLite
"Elapsed time: 1802.426963 ms (11,096 ops)"
"Elapsed time: 1731.118831 ms (11,553 ops)"
"Elapsed time: 1749.842658 ms (11,429 ops)"
; Running "update foo set bar=bar+1 where id=1" 100 times in SQLite
"Elapsed time: 6362.829057 ms (15 ops)"
"Elapsed time: 6405.25075 ms (15 ops)"
"Elapsed time: 6352.943553 ms (15 ops)"
; Running "select * from foo" 20000 times in PostgreSQL
"Elapsed time: 2898.636079 ms (6,899 ops)"
"Elapsed time: 2824.77372 ms (7,080 ops)"
"Elapsed time: 2837.622659 ms (7,048 ops)"
; Running "update foo set bar=bar+1 where id=1" 5000 times in PostgreSQL
"Elapsed time: 3213.120219 ms (1,556 ops)"
"Elapsed time: 3564.249492 ms (1,402 ops)"
"Elapsed time: 3280.128708 ms (1,524 ops)"
pg_fsync_test结果：
C:\temp>"C:\Program Files\PostgreSQL\9.3\bin\pg_test_fsync"
5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 81199.920 ops/sec 12 usecs/op
fdatasync n/a
fsync 45.337 ops/sec 22057 usecs/op
fsync_writethrough 46.470 ops/sec 21519 usecs/op
open_sync n/a
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 41093.981 ops/sec 24 usecs/op
fdatasync n/a
fsync 38.569 ops/sec 25927 usecs/op
fsync_writethrough 36.970 ops/sec 27049 usecs/op
open_sync n/a
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
1 * 16kB open_sync write n/a
2 * 8kB open_sync writes n/a
4 * 4kB open_sync writes n/a
8 * 2kB open_sync writes n/a
16 * 1kB open_sync writes n/a
Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close 45.564 ops/sec 21947 usecs/op
write, close, fsync 33.373 ops/sec 29964 usecs/op
Non-Sync'ed 8kB writes:
write 889.800 ops/sec 1124 usecs/op
答案 0 :(得分：15)
它分解了它们如何实现快照隔离。
SQLite使用文件锁定作为隔离事务的手段，只有在完成所有读取操作后才允许写入。
相比之下，Postgres使用了一种称为多核货币版本控制（mvcc）的更复杂的方法，它允许多次写入与多次读取并行发生。http://www.sqliteconcepts.org/SI_index.html
http://www.postgresql.org/docs/current/static/mvcc-intro.html
答案 1 :(得分：6)
怀疑是正确的。使用您指定的设置的PostgreSQL不能在每秒单独的顺序事务中对旋转媒体执行1500次更新。
你的IO堆栈中可能存在关于它如何实现同步的谎言或错误。这意味着在意外断电或操作系统故障后，您的数据可能会出现严重损坏。
查看pg_test_fsync的结果，情况确实如此。 open_datasync，这是Windows下的默认设置，似乎不切实际，因此必须是不安全的。当我在Windows7机器上运行pg_test_fsync时，我看到同样的事情。
答案 2 :(得分：4)
Denis的答案包含您需要的所有链接。我会找一个不太详细但可能更容易理解的答案。
Sqlite不使用任何复杂的事务管理器，其中没有隐藏的高级多任务逻辑。它按照这个顺序执行你告诉它执行的内容。换句话说：它完全按照你的要求去做。如果您尝试从两个进程使用相同的数据库 - 您将遇到问题。
另一方面，PostgreSQL是一个非常复杂的数据库：它有效地支持多个并发读写。把它想象成一个异步系统 - 你只安排要完成的工作，你实际上并没有在它的细节中控制它--Postgres为你做了。如何处理您的效率？加入几个 - 几十个 - 数百个更新/插入到一个事务中。对于一个简单的表格，您将获得非常好的表现。
答案 3 :(得分：2)
实际上，旋转磁盘上的任何写入都是10 ms的数量级（典型值为8 ms）。
这意味着每秒写入次数超过100次，如果您在磁盘中写入相同的位置，这对于数据库来说是一个非常奇怪的情况。请参阅＆＃34;您不知道关于磁盘的插孔＆＃34;从ACM来看，通常磁盘可以在一次轮换中安排10次读取或写入。
http://queue.acm.org/detail.cfm?id=864058
因此，数据库每秒可执行1,000次写入甚至更多次写入。我看到应用程序10年前在桌面计算机上每秒执行1,500笔交易。
答案 4 :(得分：1)
假设您使用的是普通硬盘（即没有ssd），则每秒最多可以进行50-100次写入。似乎每秒15次写入略低，但并非不可能。
因此，如果Postgres每秒进行1500次更新，则会将其写入某个缓冲区/缓存或折叠为单个更新。在不了解实际测试的情况下，很难说实际的原因是什么，但是如果要打开一个事务，更新单行1500次并在此之后提交，而Postgres应该足够聪明，只能执行单个“真实”写入磁盘。