我感兴趣的是保持数据库中某些表发生的每个更改的运行历史记录,从而能够重建数据库的历史状态以进行分析.

我正在使用Postgres,这个MVCC似乎我应该能够为此目的利用它,但我找不到任何文档来支持这个.我可以做吗？有没有更好的办法？

任何输入都表示赞赏!

UPD

我已经将丹尼斯的回答标记为答案,因为他确实回答了MVCC是否是我想要的问题.但是,我已经确定的策略详述如下,以防有人发现它有用:

Postgres功能可以满足我的需求:在线备份/时间点恢复.

http://www.postgresql.org/docs/8.1/static/backup-online.html解释了如何使用此功能,但基本上您可以将此"预先写入日志"设置为存档模式,拍摄数据库的快照(比如说) ,在它上线之前),然后不断归档WAL.然后,您可以随时使用日志重播来调用数据库的状态,如果您选择(通过不断重播备用服务器上的新WAL),可以获得热备用的附带好处.

也许这种方法不像其他保存历史记录那样优雅,因为你需要为你想要查询的每个时间点实际构建数据库,但是它看起来非常容易设置并且丢失零信息.这意味着当我有时间改进对历史数据的处理时,我将拥有一切,因此能够将我笨重的系统转换为更优雅的系统.

使其如此完美的一个关键事实是,我的"有效时间"与特定应用程序的"交易时间"相同 - 如果不是这种情况,我只会捕获"交易时间".

在我发现WAL之前,我正在考虑每天拍摄快照或其他东西,但是大尺寸要求和数据丢失并不适合我.

为了快速启动和运行,从一开始就不影响我的数据保留,这似乎是一个完美的解决方案.

我在PostgresQL中有一个非常大的数据库表和一个像"复制"的列.每个新行开始都是未复制的,稍后将通过后台程序复制到另一个东西.该表上有一个部分索引"btree(ID)WHERE replicated = 0".后台程序最多选择2000个条目(LIMIT 2000),对它们起作用,然后使用2000个准备好的sql-commands在一个事务中提交更改.

现在的问题是我想给用户一个重置这个复制值的选项,让它再次为零.

更新表集已复制= 0;

不可能:

• 这需要很长时间
• 由于MVCC,它重复了表格的大小
• 它在一个事务中完成:它要么失败要么经过.

在这种情况下,我实际上不需要事务功能:如果系统发生故障,它将只处理部分事务.

其他几个问题:做一个

update set replicated=0 where id >10000 and id<20000

同样糟糕的是:它在整个表格上执行顺序扫描,这太慢了.如果它没有这样做,它仍然会很慢,因为这将是太多的寻求.

我真正需要的是一种遍历所有行,改变它们而不受大型事务约束的方法.

奇怪的是,一个

UPDATE table 
  SET replicated=0 
WHERE ID in (SELECT id from table WHERE replicated= LIMIT 10000)

也很慢,虽然它应该是一件好事:按DISK顺序浏览表...

(注意,在那种情况下,还有一个覆盖这个的索引)

(像Mysql这样的更新LIMIT不适用于PostgresQL)

BTW:真正的问题更复杂,我们在谈论已经部署的嵌入式系统,因此远程架构更改很困难,但遗憾的是它可能是PostgresQL 7.4.

我正在谈论的行数例如是90000000.数据库的大小可以是几个千兆字节.

数据库本身只包含5个表,一个是非常大的表.但这不是一个糟糕的设计,因为这些嵌入式盒子只能运行一种实体,它不是ERP系统或类似的东西!

有任何想法吗？

如何向MVCcontrib网格的每一行添加一个复选框.然后在发布表单时找出选择了哪些记录？我在寻找这个时找不到多少.谢谢

我在Web上找到了许多资源,给出了MVCC(多版本并发控制)概念的一般概述,但没有关于它应该如何工作或实现的详细技术参考.是否有任何在线或书籍离线的文件,其中包含足够的理论(以及一些实际的帮助,理想情况下)作为实施的基础？我希望或多或少地模仿PostgreSQL的功能.

(有关信息,我将在SAS使用SAS /股实现它 - 它提供了一些锁定原语和并行读/写访问底层数据存储,但没有在事务隔离或适当的DBMS功能的方式,如果有人熟悉SAS/Share认为这是一项不可能完成的任务,请大声喊!)

MongoDB对我来说是一个很棒的数据库.但是,有些情况下我确实需要原子多文档事务.例如,在账户之间转移资金(如金钱或信誉),这需要完全成功或完全失败.

我想知道是否可以通过实现MultiVersion并发控制模式的库与MongoDB进行交互.

表演有多糟糕？使用混合方法是否可行且有利可图,仅在必要时使用"mongo-mvcc"库,而在仅处理单个文档时使用传统的数据库连接还是会破坏mvcc的内容？

为并发控制实现多版本时间戳排序的DBMS通常包含在其预写日志中？图像之前和之后,还是其中之一？时间戳？还有什么 ？

在PostgreSQL中,MVCC并发控制机制说:

为查询(读取)数据而获取的MVCC锁与写入数据时获取的锁不冲突,因此读取永远不会阻止写入和写入从不阻止读取

因此,即使对于READ_COMMITTED,UPDATE语句也会锁定当前受影响的行,因此在当前事务提交或回滚之前,没有其他事务可以修改它们.

如果并发事务在锁定的行上发出UPDATE,则第二个事务将阻塞,直到第一个事务释放它的锁.

1. 这种行为是否试图阻止写 - 写冲突？

2. 丢失的更新仍然可以在READ_COMMITTED中发生,因为在第一个事务提交之后,第二个将覆盖该行(即使数据库在UPDATE查询开始和查询结束之间已经更改).因此,如果仍然可以丢失更新,为什么第二笔交易必须等待？是否可以使用行级快照来存储未提交的事务更改,以避免事务必须等待释放写锁？

问题总结

这是一个关于 SQL 事务中查询的可序列化性的问题。

具体来说，我正在使用 PostgreSQL。可以假设我使用的是最新版本的 PostgreSQL。根据我所读到的内容，我相信用于支持我正在尝试做的事情的技术被称为“多版本并发控制”或“MVCC”。

总结一下：如果我有一个主表，并且有多个外键链接表连接到该主表，那么对于表中的给定键以及任意数量的 SELECT 语句，我如何保证这一点在一个事务中使用该键，每个事务都从任何链接表中进行选择，我将获得启动事务时存在的数据？

其他问题

这个问题类似，但范围更广，并且问题和答案与 PostgreSQL 没有具体关系： TransactionisolationandreadingfrommultipletablesonSQLServerExpressandSQLServer2005

例子

假设我有 3 张表：

bricks
    brickworks (primary key)
    completion_time (primary key)
    has_been_sold

brick_colors
    brickworks (primary key, foreign key pointing to "bricks")
    completion_time (primary key, foreign key pointing to "bricks")
    quadrant (primary key)
    color

brick_weight
    brickworks (primary key, foreign key pointing to "bricks")
    completion_time (primary key, foreign key pointing to "bricks")
    weight

砖厂一次生产一块砖。它制作的砖块在其 4 个象限的每个象限中可能具有不同的颜色。

后来有人分析了砖块以确定它们的颜色组合，并将结果写入brick_colors 表。

其他人分析砖块以确定其重量，并将结果写入brick_weight 表。

在任何给定时间，现有的砖可能有也可能没有记录颜色，并且可能有也可能没有记录重量。

存在一个应用程序，并且该应用程序收到某人想要购买特定砖块的消息（此时应用程序已通过其 brickworks/completion_time 复合键知道）。

应用程序想要在开始查询的确切时间选择砖块的所有已知属性。

如果在事务中添加颜色或重量信息，则应用程序不想知道它。

应用程序想要执行单独的查询（不是具有多个连接到外键链接表的 …

是否可以查询 db 中有多少多版本行？

我们想测量pg_dump对生产数据库的影响，并在需要时暂停它：它是否创建了太多多版本行？

提前致谢

我一直在学习 PostgreSQL 中的 MVCC。据我了解，当更新行时，将添加一个新行，旧行中的值将具有新添加行xmax的值。xmin当我在 Postgres 数据库中的表中检查它时，xmin和xmax值是相同的。这是什么意思？

   xmin   |   xmax   |    id    |     serial     | paid 
----------+----------+----------+----------------+------
 54569114 | 54569114 | 11099324 | 76605297311437 | t
 54569111 | 54569111 | 11099323 | 38131108141783 | t
 54569101 | 54569101 | 11099322 | 49399633274146 | t
 54569092 |        0 | 11099321 | 44672543705101 | f
 54569090 | 54569090 | 11099320 | 21324499293647 | t
 54569083 |        0 | 11099319 | 82878160317074 | f
 54569079 | …