長期大量交易都很糟糕

Question

你好，

我正在編寫一個數據庫應用程序，它使用偽serialisable隔離級別（ snapshot isolation ）執行大量插入和更新。

為了不進行大量的網絡往返，我在PreparedStatement的一次交易中批量插入和更新。 它們應該很少失敗，因為插入是預先檢查的，幾乎與其他事務沒有沖突，所以不經常發生回滾。

擁有大量交易應該對WAL有利，因為它可以刷新大塊而不必刷新小型交易。

1.）我只能看到大交易的積極影響。 但我經常讀到它們很糟糕。 為什么他們的用例會不好？

2.）當local snapshots合並回真實數據庫時，檢查沖突是否如此昂貴？ 數據庫必須比較所有可能沖突的寫集（並行事務）。 還是它做了一些高速快捷方式？ 或者那是相當便宜的嗎？

[ 編輯 ]如果有人能夠清楚地了解快照隔離數據庫如何檢查時間線上具有重疊部分的事務是否針對析取寫集進行檢查，那么可能會很有趣。 因為那就是假的可序列化隔離級別。

Answer 1

這里真正的問題有兩個方面。 第一個可能的問題是膨脹。 大型事務可能會導致很多死元組一次出現。 另一個可能的問題是長時間運行的交易。 只要長時間運行的事務正在運行，它觸摸的表就不能被清理，所以也可以收集大量的死元組。

我會說只需使用check_postgresql.pl來檢查膨脹問題。 只要你在長期交易后沒有看到很多表格膨脹，你就可以了。

Answer 2

1）手冊說它很好： http ： //www.postgresql.org/docs/current/interactive/populate.html

我還建議使用COPY，刪除索引（但首先測試），增加maintenance_work_mem，增加checkpoint_segments，運行ANALYZE（或VACUUM ANALYZE）。

如果您不確定，我不會建議：刪除外鍵約束，禁用WAL存檔和流復制。

2）始終在提交時合並數據，但沒有檢查，只寫入數據。 再讀一遍： http ： //www.postgresql.org/docs/current/interactive/transaction-iso.html

如果您的插入/更新不依賴於其他插入/更新，則不需要“完全一致的視圖”。 您可以使用read committed和transaction永遠不會失敗。