MongoDB - 我可以使用滾動方法創建 TTL 索引嗎
我被困在 MongoDB 3.6 中歸檔大量數據
我想刪除集合中的 5.06 億條記錄。我嘗試使用 bulk.remove() 刪除，但這也很慢。每秒刪除 50 條記錄。
但在我讀到的某個地方，TTL 索引並每 1 小時進行一次掃描間隔。所以它會以更快的方式刪除。
但是如果我在前台創建這個索引，它會鎖定集合。所以我正在考慮使用滾動索引創建方法。
如果這樣做，假設在 3 節點副本集上，分離 node3 然後創建索引。一旦創建，它將開始自動刪除數據。然後一旦我將節點添加回副本集，也許主節點會在我創建索引後執行刪除，到時候它會嘗試複製，在最壞的情況下，該節點上的數據已經被刪除，然後它’會打破複製？
我可以使用滾動方法創建 TTL 索引嗎
是的，這是在副本集上建構索引的受支持方法。但是，如果您的目標是有效地刪除大量現有文件，則需要注意一些注意事項，如下所述。
我嘗試使用 bulk.remove() 刪除，但這也很慢。（每秒刪除 50 條記錄）。
如果您已經有一個支持查找過期文件的索引，則 TTL 索引不會加速文件的刪除：TTL 執行緒仍然需要查找和刪除匹配的文件，因此將執行與批量刪除類似的工作。
我會調查為什麼您目前的批量刪除操作很慢。例如，確保您有一個最佳索引來查找要刪除的文件並監控您的系統資源（記憶體、I/O、網路……），以確保沒有任何明顯的瓶頸。
如果在創建 TTL 索引時準備好刪除大量文件，這可能會對性能產生重大影響。帶有支持索引的批量刪除查詢可以更好地控制影響，因為您可以添加查詢條件來限制與每個批量刪除匹配的文件範圍。
但在我讀到的某個地方，TTL 索引並每 1 小時進行一次掃描間隔。所以它會以更快的方式刪除。
該時間不正確：TTL 刪除任務每 60 秒執行一次。基於索引的日期欄位，TTL 監視器可以在指定的秒數過去後使文件過期或在特定時鐘時間使文件過期。
假設您的文件有一個到期日期範圍，一旦過期文件的初始刪除完成，TTL 索引將能夠以較小的批次刪除文件，這將比不頻繁的批量刪除影響更小。
但是如果我在前台創建這個索引，它會鎖定集合。所以我想與滾動索引創建方法有關。
在 MongoDB 4.2 之前，在填充集合上建構的前台索引將阻止保存該集合的數據庫上的所有其他操作。對於生產環境中的填充集合，您肯定希望使用滾動索引建構或後台索引建構。滾動索引建構確保只有一個副本集成員正在建構索引，並允許前台索引建構更快地完成，但是這種方法確實存在該成員在獨立模式下執行時變得陳舊的風險。
MongoDB 4.2+ 使用優化的索引建構過程，將鎖定範圍限制為受影響的集合，並且僅在索引建構的開始和結束時持有排他鎖。您仍然可以使用滾動索引建構方法，但不再有前台與後台索引建構的區別。
如果這樣做，假設在 3 節點副本集上，分離 node3 然後創建索引。一旦創建，它將開始自動刪除數據。
副本集成員上的TTL 索引執行緒僅在成員處於主狀態時刪除文件。文件刪除通過 oplog 複製，因此輔助節點始終與目前主節點具有一致的時間點。
如果您在獨立模式下重新啟動副本集成員，則不會啟動 TTL 收集監視器（再次保持輔助狀態一致）。