CQRS與polyglot設置中的cockroachdb

Question

我正在考慮使用cockroachdb以ACID保證的方式在第三範式中寫入數據。所以所有的寫作都會被轉移到cockroachdb。

這些讀取可能都是基於rowkey到Cassandra的點查找。我相信這樣的讀取設置將消除對Redis緩存的需要，因爲Cassandra會自行快速讀取。所以Cassandra表將根據訪問路徑進行非規範化。

可能存在基於事件的同步插入/更新/刪除內部cockroachdb規範化模式插入/更新/刪除cassandra denormalzied模式。

問題1：

這是否讀/寫分離成適合使用cockroachdb有效的用例？其目的是減少連接並快速讀取以及寫入。蟑螂數據庫也成爲單一的事實源頭，攝取事件源類數據。而像cassandra和elasticsearch這樣的其他數據庫就成爲最終保持同步的查詢投影。

問題2：

此安裝配合，其中N報表需要進行自動完成的金融交易？根據我的理解，讓我們假設在cockroachdb 3NF模式中有事務性地執行了N個SQL語句。在此之後，讀取從Cassandra/ElasticSearch發生，由於同步延遲，這些讀取將不會同步。在這種最終的一致性方案中，如果用戶發送另一個命令以並行地從其他機器獲得相同的結果，則將轉到將在cockroachdb中查找的命令處理程序。我認爲既然CockroachDb符合ACID標準，那麼在查找cockroachdb後，在命令驗證步驟期間，我們將確保無效命令。我相信這個cockroachdb會拋出樂觀鎖定異常，因爲寫入同一個表的一個事務已經在進行中。所以問題是 - 在這種情況下，我們是否應該閱讀CockroachDB而不是Cassandra/ElasticSearch？

問題3

最後用例我腦子裏想的是讓cockroachdb起什麼火花集羣將做卡桑德拉相對於聚合作用。我們可以在cockroachdb中進行聚合，這個聚合包含所有的數據並存儲在cassandra的預聚合表中。雖然ElasticSearch也能夠進行聚合，但這裏有個問題 - 這個用例是否聽起來正確w.r.t使用cockroachdb而不是elasticsearch進行聚合？

Answer 1

作爲一般指導原則，我建議從零開始設計系統，而不是從如此複雜的體系結構開始。如果您從CockroachDB開始，將其作爲您的「單一來源」，那麼您可以單獨使用CockroachDB多遠？您是否有隻能通過緩存層滿足的性能要求？你需要一個單獨的系統來進行彙總/報告嗎？如果答案是「是」，那麼然後你可以開始考慮這些組件應該採取什麼形式。

可能存在基於事件的同步插入/更新/刪除內部cockroachdb規範化模式插入/更新/刪除cassandra denormalzied模式。

注意CockroachDB還沒有以流更新到外部系統的好方法，所以這不會是容易的事情。

爲了您的具體問題：

1. 讀緩存可以是一個有價值的除了一個系統，但同時也增加了很多複雜的，所以不要引進一個，直到你知道你需要它。您也可以在SQL數據庫中對事物進行規範化處理，而像CockroachDB的interleaved tables等功能可以減少對非規範化的需求。

2. 您只有在事務中轉到CockroachDB的讀取事務保證。這裏的確切行爲將取決於您的交易如何編寫。例如，根據您的模式，兩個「添加評論」事務可以同時應用而不會相互衝突。您可能需要通過提供適當的唯一ID或在事務開始時執行SELECT來防止出現這種情況，以確保數據庫的狀態符合您的預期。 （另外，不要對「樂觀鎖定例外」做出太多假設，CockroachDB的併發性是樂觀和悲觀模型的組合）

3. 同樣，這取決於。 ElasticSearch可以做很多CockroachDB無法做到的事情，而CockroachDB也沒有做過多的預聚合。但是SQL是一種用於聚合和報告的非常靈活的語言，因此您可以在CockroachDB中執行所需的操作。