具有大量更新的长时间运行事务的数据库。

Question

我构建了一个数据提取和转换工具。典型用例--以事务方式处理大量数据。

数字是-10秒-5分钟持续时间，200-10000行更新(长持续时间不是由数据库本身，而是由事务期间使用的外部服务造成的)。

有两种类型的代理访问数据库-多个读代理，和只有一个写代理(因此，从来没有多个并发写入)。

在交易期间：

• 读取代理应该能够读取数据库并在当前状态下查看它。
• 写代理应该能够读取数据库(它在事务期间同时进行读和写)，并将其置于新的(尚未提交)状态。

对于这种类型的负载，PostgreSQL是一个很好的选择吗？我知道它使用的是MVCC，所以在一般情况下应该是可以的，但是广泛地使用长事务和大事务可以吗？

还有什么其他开放源码的事务性数据库可能是一个不错的选择(我不局限于SQL)？

附注：

我不知道切分是否会影响表演。数据库将被分割。对于每个碎片，将有多个读者和一个作者，但多个不同的碎片可以同时写入。

我知道在交易过程中最好不要使用外部服务，但在这种情况下--这就是目标。该数据库作为一个可靠和一致的索引，为一些沉重，庞大，缓慢和最终一致的数据处理工具。

Answer 1

巨大的免责声明:一如既往，只有真实的测试才能告诉你真相。

但是，我认为PostgreSQL不会让您失望，如果您使用最新版本(至少9.1，更好的9.2)并正确地调整它。

我的服务器上有一些类似的负载，但R/W比略差:大约10:1。事务从几毫秒到1小时(有时甚至更长)不等，一个事务最多可以插入或更新100 k行。具有长事务的并发写入器的总数可以达到10个或更多。到目前为止还不错--我真的没有任何严重的问题，表现很好(当然不会比我预期的更糟)。

真正有帮助的是，我的热工作数据集几乎符合可用内存。

所以，试一试，它会对你的负载起很大的作用。

Answer 2

看看这个链接。Maximum transaction size in PostgreSQL

基本上，在软件方面，您的事务可以有多大的技术限制。