8000万行テーブルのUUIDのインデックス

Question

私たちは、8,000万行のテーブルのUUIDタイプカラムにインデックスを追加するために、postgresを使ってRuby on Railsの移行を使用しています。

concurrentlyパターンと、disable_ddl_transaction!パターンに従いました。しかし、導入直後、移行中に、重度の減速に気づき始め、最終的にテーブルが応答を停止しました。私たちは途中で移行をキャンセルしましたが、テーブルは最終的に回復しましたが、テーブルの応答を停止させた原因はまだ分かりません。

私たちはAWS RDSを使用しており、すべての統計情報を確認していますが、CPUまたはI/Oが超過しているようには見えません。

私の質問は、この移行中に減速/停止の原因となった可能性がある他の考慮事項は何ですか？

他のテーブルが応答していましたが、アプリケーションがロードされましたが、この1つのテーブルはちょうど立ち往生していました。ここ

移行です：移行の

class AddIndexToPublicId < ActiveRecord::Migration 
    disable_ddl_transaction! 

    def up 
    change_column :table1, :public_id, :uuid, null: false 
    change_column :table2, :public_id, :uuid, null: false 
    change_column :table3, :public_id, :uuid, null: false 
    add_index :table1, :public_id, unique: true, algorithm: :concurrently 
    add_index :table2, :public_id, unique: true, algorithm: :concurrently 
    add_index :table3, :public_id, unique: true, algorithm: :concurrently 
    end 

    def down 
    remove_index :table1, :public_id 
    remove_index :table2, :public_id 
    remove_index :table3, :public_id 
    change_column :table1, :public_id, :uuid, null: true 
    change_column :table2, :public_id, :uuid, null: true 
    change_column :table3, :public_id, :uuid, null: true 
    end 
end 

change_column一部が正常に動作するように見えたが、インデックスは、私たちのschema.rbにはないところ、我々は今、奇妙な状態にしているので、終了しませんでした私たちのdbにマッチします。

Answer 1

一度に複数のインデックスを同時に追加しているため、速度が遅くなると思います。このオプションを使用するとPostgres document

によると、PostgreSQLは、テーブルの2回のスキャンを実行する必要があり、しかもそれが潜在的に終了するためにインデックスを変更したり、使用することができ、すべての既存のトランザクションを待つ必要があります。

したがって、同時にインデックスを追加する場合、Postgresはテーブルを2回スキャンする必要があります。

はあなたの移行を打破するために試してみてください。change_columnため

• 一つの移行。
• 各1回の移行。add_index。

一度に1つだけ実行してください。