支持現有Feed表的邏輯刪除

我想對新聞訂閱記錄實施邏輯刪除以支持稍後撤消。
系統正在生產中，所以任何解決方案都應該支持現有數據。
向記錄插入記錄是冪等的，因此插入已刪除的記錄（具有相同的主鍵）不應該將其刪除。
任何解決方案都應支持查詢以檢索現有或已刪除記錄的頁面。支持現有Feed表的邏輯刪除

飼料表：

CREATE TABLE my_feed (
    tenant_id int, 
    item_id int, 
    created_at timestamp, 
    feed_data text, 
PRIMARY KEY (tenant_id, created_at, feed_id)) 
WITH compression = { 'sstable_compression' : 'LZ4Compressor' } 
AND CLUSTERING ORDER BY (created_at DESC);

有我有想過，但都具有嚴重的缺陷兩種方法：
1.將已刪除的記錄到一個不同的表。查詢是微不足道的，不需要遷移，但冪等插入似乎很困難（只能在插入之前讀取？）。
2.添加is_deleted列。爲該列創建輔助索引以支持查詢。冪等插入似乎更容易支持（輕量級事務或更新技巧）。主要缺點是較舊的記錄具有空值，因此需要數據遷移。

還有第三種更優雅的方法嗎？你是否支持上述建議之一？

來源

2014-10-17 Ohad Bruker

如果您爲已刪除的記錄維護一個單獨的表，您可以使用CQL的BATCH構造來執行「移動」操作，但由於刪除的唯一記錄在該表中，因此您必須首先檢查它是否需要該行爲你已經描述過不重新刪除記錄的動畫。寫之前讀通常是一個反模式等

使用一個is_deleted列可能需要一些遷移工作，你提到的，但你可能有潛在的更嚴重的問題是建立在一個非常低的指數cardinality列通常效率極低。與boolean字段，我認爲你的索引將只包含兩行。如果您不經常刪除，那意味着您的「虛假」行將會非常寬，因此almost useless。

如果你避免創建爲is_deleted列二級指標和你同時允許null和false指示的活動記錄，而只有明確true表示刪除的，你可能不需要遷移任何東西。（你實際上知道在遷移過程中要刪除哪些現有記錄嗎？）然後，您可以將刪除的記錄過濾到客戶端，客戶端可能已經負責一些分頁行爲。這種設計的缺點是你可能不得不要求> N個記錄來獲得N個未被刪除的記錄！

我希望能夠幫助您解決您所提及的問題。我會好奇的想知道爲什麼你需要防範已經被刪除的記錄恢復生機，但我可以想象一種情況，你有多個參與者在處理特定的feed（以及可能出現的CAS問題）。

在一個稍微不相關的說明中，您可能需要考慮使用timeuuid而不是timestamp作爲您的created_at字段。如果這是一個絆腳石，CQL支持dateOf()函數檢索該日期。（在您的tenant_id分區內碰撞也是不可能的，在這種情況下，您可以放心地忽略我。）

來源

2014-10-20 23:56:35

我需要防止已經被刪除的記錄重新生效，因爲系統設計爲可以多次發送單個記錄（重試，遷移，自我修復過程）。在這種情況下，預計插入記錄後，除非用戶將其刪除，否則不會更改。 – 2014-10-27 06:31:35

關於'is_deleted'：假設在查詢中始終指定分區鍵（tenant_id），則輔助索引對低基數字段也應該有效：[http://stackoverflow.com/q/26439396/3950710] – 2014-10-27 06:49:41

支持現有Feed表的邏輯刪除

回答

相關問題