是否有記錄所有更改並允許選擇性回滾特定更改的儲存引擎/數據庫？

是否有自然支持此案例的儲存引擎或數據庫：

1) Key-Value storage. Small Fixed Length Key, and value within [1KB, 64KB]
2) Access is read-mostly
3) Latency more important than throughput.
4) Use discs for values; not a memory-database, but keys could be kept in RAM.
5) Transactions (that involve several values) are NOT required
6) It should be possible to roll-back to a point-in-time (say, 1 week ago max).
7) All changes are attributed to some specific entity (a user)
8) It should be possible to roll-back changes done by a specific group of users
  within a certain time interval.
9) Rollback happens rarely, so transaction logs should not be kept in RAM.
10) Online backups are possible.
11) I should be directly or indirectly accessible from a JVM.

雖然我知道幾個通常適合的引擎/數據庫，但第 7 點和第 8 點更有問題。

什麼最適合這個案例？

$$ EDIT $$這是我的第一個“獨立”/私人項目，我沒有太多錢投資軟體。此外，我還不確定我是否會為此收費，或者在完成後將其開源，所以我更喜歡免費儲存，或者至少有一個免費版本。這裡澄清一下第一個答案中提出的一些問題。

3) I'm sold to SSD already.
4) I said "use disc" simply because the data will not all fit in the RAM I can
  afford. Also I suspect I will have a lot of "cold" data, that gets created once
  and never accessed again, so it would seem a waste to keep it all in RAM, as
  would be the case with VoltDB, for example.
7) Adding explicitly the UserID is not problem in most database. I just thought that
  some storage system might have some kind of "special" ID that makes rollback
  easier.
8) This is where the real problem is. Writing a traditional "undo/rollback" by hand
  is time-consuming and error-prone. I know I can do all the rest with most DB.
  What I'm looking for is one that implements the undo/rollback for me, given some
  transaction ID or similar. And most importantly, without undoing other
  independent transactions that happened before or after.
9) I think redis does that; not sure.
10) I was (implicitly) thinking about a free one, where it's not always a given.

這是我正在努力解決的問題，我認為您在嘗試查找此類系統時會發現。（特別是當它達到要求 7 和 8 時。）

假設您有使用者 A 將值從 1 更改為 2。然後使用者 B 將其從 2 更改為 26。如果您嘗試回滾使用者 A 的值，您會將其回滾到什麼位置？你把它改回1還是你把它留在26？你會做一些奇怪的業務邏輯並使其成為 25 嗎？

有幾種可能的情況，但最終，沒有通用的方法來處理這種類型的數據。如果不回滾，則無法滿足規則 8。如果回滾，則無法滿足規則 7（僅允許某個使用者的更改回滾）。如果你做了一些瘋狂的數學規則，那麼每個規則都必須非常具體到要修改的列。

我認為沒有任何數據庫可以在一般基礎上處理這個問題。可以基於時間點回滾，但這完全違反了規則 7（允許您回滾某個組的更改）。

在自定義編寫的特定用途應用程序之外，我看不出如何在通用數據庫系統上實現 7 和 8。

引用自：https://dba.stackexchange.com/questions/4618