我构建了一个数据提取和转换工具。典型用例 - 事务处理大量数据。
数字是 - 大约10秒 - 持续5分钟，更新200-10000行（长时间不是由数据库本身引起的，而是由交易期间使用的外部服务引起的）。
有两种类型的代理可以访问数据库 - 多个读取代理，只有一个写代理（因此，永远不会有多个并发写入）。
在交易期间：
PostgreSQL是否适合这种类型的负载？我知道它使用的是MVCC - 所以它一般都可以，但是可以广泛使用长期和大型交易吗？
其他哪些开源事务性数据库可能是一个不错的选择（我不仅限于SQL）？
P.S。
我不知道分片是否会影响性能。数据库将被分片。对于每个碎片，将有多个读取器和只有一个写入器，但可以同时写入多个不同的碎片。
我知道最好不要在交易过程中使用外部服务，但在这种情况下 - 这是目标。该数据库用作一些可靠且一致的索引，用于某些繁重，巨大，缓慢且最终一致的数据处理工具。
答案 0 :(得分：4)
巨大的免责声明：一如既往，只有现实生活测试才能说实话。
但是，我认为PostgreSQL不会让你失望，如果你使用最新版本（至少9.1，更好的9.2）并正确调整它。
我的服务器负载有点类似，但R / W比稍差：大约10：1。事务的范围从几毫秒到1小时（有时甚至更多），一个事务可以插入或更新多达100k行。具有长事务的并发写入者总数可以达到10或更多。 到目前为止一切都那么好 - 我真的没有任何严重的问题，性能很好（肯定不会比我预期的差）。
真正有用的是我的热工作数据集几乎适合可用内存。
所以，试一试，它应该适合你的负载。
答案 1 :(得分：1)
看一下这个链接。 Maximum transaction size in PostgreSQL
基本上，软件方面可能存在一些技术限制，以确定交易的大小。