大家知道，像ob，hbase這種儲存系統，插入資料的時候，一般資料上都會有乙個時間戳(ts)。
hbase有乙個ttl（time to live），可以標識資料的有效期，比如，可以把ttl設定成86400*1000，也就是說資料將於1天後過期。這是乙個表級的設定，必須在建表時指定。
但是如果說你需要儲存某一天內的資料，到第二天0點失效。這種情況ttl是沒法控制的，因為ttl只能控制資料在一段時間後失效，而不能控制在特定的時間點失效。
ttl的本質是通過對比資料的ts，與當前系統時間，然後確定是否應該失效，於是，我們可以通過ts來hack一下。
假設資料的ttl是1天，如果我在凌晨1點插入資料，那麼正常情況，它會到第二天凌晨1點失效。實際上就是判斷：currentmilliseconds - ts > 86400*1000，如果滿足，資料就失效了。
這時如果要控制資料在第二天0點就失效，我們把插入資料的ts往後推一小時就可以了，它就會提前失效。
這個方案理論上看起來沒有問題，但是如果你的表涉及到刪除資料，那麼，坑就來了。
hbase普通的操作，都會寫入wal（write ahead log），累積到一定數量後（或者根據時間），根據操作的ts，進行merge，然後對真實的資料做commit，這個跟資料庫的log是有點類似的。
這裡面隱含的一點是，hbase中的操作，是需要ts比當前資料中的ts大，操作才會有效，否則就無效（正常的都是這樣的，因為時間是不斷變大的嘛）。
比如當前有2個操作：
put 'key', 'value', ts=1
put 'key', 'value', ts=2
那麼經過合併後，實際上只會有乙個操作：
put 'key', 'value', ts=2（因為這個時間戳比較大嘛）
接著來，如果有3個操作：
put 'key', 'value', ts=1
put 'key', 'value', ts=2
del 'key', 'value', ts=3
那麼，合併後，就只有delete的操作了。
坑就在這裡，因為我們是手動設定插入資料的ts的。這就意味著，如果要刪除資料，那必須要將刪除操作的ts設定得比原來的資料的ts要大（在我們的情況中，兩個時間都是未來）。
如果刪除操作，使用了系統預設的ts，那麼造成的結果是：資料無法被刪除。
ok，那我們就知道，會將刪除的ts設大。可是這時，如果你再插入資料，就必須將插入資料的ts設定得比刪除操作的ts還要大。。。其實就是，對同乙個cell的操作，要想你的操作有效，你必須將它的ts設定為比當前操作序列中最大的還要大。。。
然後，如果一不小心，你想當然地把刪除的ts設定成了long.max_value，你就會發現，你永遠也插入不了資料了。。。。（其實不是永遠啦，要到下一次major compact）。
最後的總結：謹慎修改資料的ts。。。
Docker踩坑小記
docker是乙個開放平台用於快速開發 分發和部署應用程式。docker是一種容器管理技術。解決頭疼問題原則 回歸最簡單的方式來。確保最初級的方案沒有錯誤。curl ssl sh s同時記得的授權 chmod x usr local bin docker compose from microsoft...
Hbase實戰踩坑
寫幾個hbase踩過的坑吧 問題1 truncate table 後region 個數為1 故不要 truncate table。hbase 盡力不要執行truncate table。一旦執行 region個數就會變為1，之前的預分割槽就沒有用了。那麼如果想要刪除 清空資料 只能重新建表！問題2 t...
初識Rust踩坑小記
首先開始安裝rust，我是在linux環境下安裝的 執行命令 curl ssf sh然後重新登陸下linux，下列命令生效即表示rust安裝成功 rustup h然後使用rustup可能會報 以下錯誤 error no default toolchain configured 然後使用以下命令配置預...