他們說生活中的一切都值得至少嘗試一次。 如果您習慣使用關係型 DBMS，那麼首先在實務中熟悉 NoSQL 是值得的，至少對於一般開發來說是如此。 現在，由於這項技術的快速發展，關於這個主題有很多相互矛盾的觀點和激烈的爭論，這尤其引起了人們的興趣。
如果深入探究這些爭議的本質，就會發現它們都是因為錯誤的做法而產生的。 那些在需要的地方使用 NoSQL 資料庫的人會感到滿意，並從該解決方案中獲得所有優勢。 那些依賴這項技術作為萬靈丹的實驗者感到失望，因為它根本不適用，他們失去了關係資料庫的優勢，卻沒有獲得顯著的好處。
我將向您介紹我們實施基於 Cassandra DBMS 的解決方案的經驗：我們必須面對什麼、我們如何擺脫困境、我們是否能夠從使用 NoSQL 中受益以及我們必須在哪些方面投入額外的精力/資金。
最初的任務是建立一個在某種儲存中記錄通話的系統。
系統的工作原理如下。 輸入包括具有描述調用結構的特定結構的檔案。 然後，應用程式確保該結構儲存在適當的列中。 未來，已儲存的通話將用於顯示訂閱者的流量消耗資訊（費用、通話、餘額記錄）。
他們選擇 Cassandra 的原因非常清楚 - 她的寫作就像機關槍一樣，易於擴展且容錯。
所以，這就是經驗給我們的
是的，失敗的節點並不是悲劇。 這就是Cassandra容錯的本質。 但 一個節點可能處於活動狀態，但同時效能開始受到影響。 事實證明，這會立即影響整個集群的性能。
卡桑德拉（Cassandra）不會保護您，而甲骨文（Oracle）透過其限制拯救了您。 如果應用程式的作者事先沒有理解這一點，那麼到達 Cassandra 的雙倍並不比原來的差。 一旦它到達，我們就會把它放進去。
IB 非常不喜歡開箱即用的免費 Cassandra： 沒有記錄使用者操作，沒有權限區分。 有關通話的資訊被視為個人數據，這意味著所有以任何方式請求/更改該資訊的嘗試都必須記錄下來，以便進行後續審核。 此外，您還需要意識到需要為不同使用者劃分不同等級的權限。 一個簡單的維運工程師和一個可以自由刪除整個keyspace的超級管理員是不同的角色，不同的職責和能力。 如果沒有這種存取權限的區分，資料的價值和完整性將比任何一致性等級更快地立即受到質疑。
我們沒有考慮到呼叫需要針對各種條件進行認真的分析和定期採樣。 由於隨後應該刪除並重寫所選記錄（作為任務的一部分，我們必須支援當資料最初錯誤地進入循環時更新資料的過程），Cassandra 在這裡不是我們的朋友。 Cassandra 就像一個存錢筒——放東西很方便，但你不能數。
我們在將資料傳輸到測試區時遇到問題 （測試中有 5 個節點，舞會上有 20 個節點）。 在這種情況下，無法使用轉儲。
更新寫入 Cassandra 的應用程式的資料模式時出現的問題。 回滾將產生大量墓碑，這可能會以不可預測的方式導致生產力損失。。 Cassandra針對記錄進行了最佳化，在寫入之前不會考慮太多，任何對其中已有資料的操作也是一種記錄。 也就是說，透過刪除不必要的記錄，我們只會產生更多記錄，並且只有其中一些記錄會被標記為墓碑。
插入時超時。 卡桑德拉在錄音中很漂亮，但是 有時，傳入的流量會讓她感到非常困惑。 當應用程式開始圍繞著由於某種原因無法插入的幾筆記錄進行循環時，就會發生這種情況。 我們需要一個真正的 DBA，他將監視 gc.log、系統和調試日誌以了解慢速查詢、壓縮掛起的指標。
集群中的多個資料中心。 從哪裡讀取、從哪裡寫入？
或許分為閱讀和寫作？ 如果是這樣，是否應該有一個更靠近應用程式的 DC 來進行寫入或讀取？ 如果我們選擇了錯誤的一致性級別，我們最終會不會出現真正的腦裂？ 有很多問題、很多未知的設定、你真正想要修改的可能性。
我們如何決定
為了防止節點下沉，禁用了SWAP。 現在，如果記憶體不足，節點應該關閉並且不會造成較大的GC暫停。
因此，我們不再依賴資料庫中的邏輯。 應用程式開發人員正在重新培訓自己，並開始在自己的程式碼中積極採取預防措施。 資料儲存和處理的理想清晰分離。
我們從 DataStax 購買了支援。 盒裝 Cassandra 的開發已經停止（最後一次提交是在 2018 年 XNUMX 月）。 同時，Datastax提供優質的服務以及針對現有IP解決方案的大量修改和改編的解決方案。
我還想指出，Cassandra 對於選擇查詢不是很方便。 當然，CQL 對用戶來說是一大進步（與 Trift 相比）。 但是，如果您的整個部門都習慣了這種方便的聯接、任意字段的免費過濾和查詢優化功能，並且這些部門正在努力解決投訴和事故，那麼Cassandra 上的解決方案對他們來說似乎是敵對和愚蠢的。 我們開始決定我們的同事應該如何製作樣品。
我們考慮了兩個選項：第一個選項中，我們不僅在 C* 中編寫調用，還在存檔的 Oracle 資料庫中編寫調用。 只是，與 C* 不同，該資料庫僅儲存當月的呼叫（對於充值情況有足夠的呼叫儲存深度）。 在這裡，我們立即看到以下問題：如果我們同步寫入，那麼我們就失去了 C* 與快速插入相關的所有優勢；如果我們非同步寫入，則根本無法保證所有必要的呼叫都進入 Oracle。 有一個優點，但一個很大的優點：對於操作，仍然保留相同熟悉的 PL/SQL Developer，即我們實際上實現了“Facade”模式。另一種選擇。 我們實現了一種機制，可以卸載來自C* 的調用，從Oracle 中的相應表中提取一些數據進行豐富，連接生成的樣本並給出結果，然後我們以某種方式使用該結果（回滾、重複、分析、欣賞）。 缺點：流程步驟較多，而且沒有操作人員的介面。
最後我們選擇了第二種方案。 Apache Spark 用於從不同的 jar 進行取樣。 該機制的本質已簡化為 Java 程式碼，該程式碼使用指定的鍵（訂閱者、呼叫時間 - 部分鍵）從 C* 中提取數據，以及從任何其他資料庫中提取必要的數據。 之後，它將它們連接到記憶體中，並將結果顯示在結果表中。 我們在火花上畫了一個網面，結果證明它非常有用。
在解決工業測試數據更新問題時，我們又考慮了幾個解決方案。 兩者都透過 Sstloader 進行傳輸，並且可以選擇將測試區中的集群分成兩部分，每個部分交替與促銷集群屬於同一集群，從而由促銷集群提供支援。 更新測試時，計劃交換它們：在測試中起作用的部分被清除並投入生產，而另一部分則開始單獨處理資料。 但經過再思考，我們更加理性地評估了哪些數據值得轉移，發現調用本身就是一個不一致的測試實體，需要時快速生成，而促銷數據集是沒有轉移價值的。測試。 有幾個儲存物件值得移動，但這些實際上只是幾個桌子，而且不是很重的桌子。 因此我們 作為解決方案，Spark 再次拯救了我們，在它的幫助下，我們編寫並開始積極使用腳本 prom-test 在表之間傳輸資料。
我們目前的部署策略允許我們無需回滾即可工作。 在促銷之前，有一個強制性的測試運行，其中一個錯誤的代價並不那麼昂貴。 如果出現失敗，您始終可以刪除案例空間並從頭開始滾動整個方案。
為了確保 Cassandra 的持續可用性，您需要一名 dba，而不僅僅是他。 每個使用應用程式的人都必須了解在哪裡以及如何查看當前情況以及如何及時診斷問題。 為此，我們積極使用 DataStax OpsCenter（工作負載的管理和監控）、Cassandra Driver 系統指標（寫入 C* 的超時次數、從 C* 讀取的超時次數、最大延遲等），監控操作與Cassandra 一起使用應用程式本身。
當我們思考上一個問題時，我們意識到我們的主要風險可能在哪裡。 這些是資料顯示表單，顯示來自多個獨立查詢到儲存的資料。 這樣我們就可以獲得非常不一致的資訊。 但如果我們只使用一個資料中心，這個問題也同樣重要。 所以這裡最合理的當然是在第三方應用上創建一個讀取資料的批次函數，這將保證在單一時間段內接收到資料。 至於從效能角度分割讀寫，這裡我們遇到了這樣的風險：如果 DC 之間失去一些連接，我們最終可能會得到兩個彼此完全不一致的群集。
結果，目前 寫入 EACH_QUORUM 時停止在一致性級別，讀取時停止於 LOCAL_QUORUM
簡要印象和結論
為了從營運支援和進一步發展前景的角度評估最終的解決方案，我們決定考慮這種開發還可以應用在哪裡。
立即開始，然後對諸如“方便時付款”之類的程序進行數據評分（我們將信息加載到C *中，使用Spark腳本進行計算），按區域聚合進行索賠核算，存儲角色並根據角色計算用戶訪問權限矩陣。
正如您所看到的，劇目廣泛且多樣。 如果我們選擇NoSQL的支持者/反對者陣營，那麼我們將加入支持者的行列，因為我們得到了我們的優勢，而且正是我們所期望的。
即使開箱即用的 Cassandra 選項也允許即時水平擴展，絕對輕鬆地解決系統中資料增加的問題。 我們能夠將用於計算呼叫聚合的非常高負載的機制移至單獨的電路中，並將應用程式模式和邏輯分開，從而擺脫在資料庫本身中編寫自訂作業和物件的不良做法。 我們有機會選擇和配置，以加速我們將在哪些 DC 上執行計算以及我們將在哪些 DC 上記錄數據，我們確保自己不會發生單一節點和整個 DC 的崩潰。
將我們的架構應用到新專案中，並且已經有了一些經驗，我想立即考慮到上述細微差別，並防止一些錯誤，平滑一些最初無法避免的尖角。
例如， 及時追蹤Cassandra的更新因為我們遇到的許多問題已經是已知的並且解決。
不要將資料庫本身和 Spark 放在同一節點上 （或嚴格除以允許的資源使用量），因為 Spark 可以吃掉比預期更多的 OP，我們很快就會從清單中得到問題 1。
提升專案測試階段的監控和操作能力。 首先，盡可能考慮我們解決方案的所有潛在消費者，因為這是資料庫結構最終依賴的。
多次旋轉所得電路以進行可能的最佳化。 選擇可以序列化的欄位。 了解我們應該製作哪些附加表，以便最正確和最佳地考慮，然後根據請求提供所需的資訊（例如，假設我們可以將相同的資料儲存在不同的表中，並根據不同的情況考慮不同的細分）不同的標準，我們可以顯著節省讀取請求的 CPU 時間）。
不錯 立即提供附加 TTL 和清理過時資料的功能。
從 Cassandra 下載資料時 應用程式邏輯應遵循 FETCH 原則，以便並非所有行都一次載入到記憶體中，而是批次選擇。
建議在將專案轉移到所描述的解決方案之前 透過進行一系列碰撞測試來檢查系統的容錯能力，例如一個資料中心內的資料遺失、一定時期內損壞資料的復原、資料中心之間的網路斷線等。 此類測試不僅可以讓人們評估所提出的架構的優缺點，而且還可以為進行測試的工程師提供良好的熱身實踐，並且如果在生產中重現系統故障，所獲得的技能也絕非多餘。
如果我們處理關鍵資訊（例如計費資料、使用者債務計算），那麼也值得關注能夠降低由於 DBMS 功能而產生的風險的工具。 例如，使用nodesync實用程式（Datastax），已為其使用制定了最佳策略，以便 為了保持一致性，不要對 Cassandra 造成過多的負載 並且只對特定時期內的特定表格使用。
卡桑德拉六個月後會發生什麼事？ 總的來說，不存在未解決的問題。 我們也不允許發生任何嚴重事故或資料遺失。 是的，我們必須考慮補償一些以前從未出現過的問題，但最終這並沒有為我們的架構解決方案帶來太大影響。 如果您想要並且不害怕嘗試新事物，同時又不想太失望，那麼請做好準備，接受沒有什麼是免費的這一事實。 與舊的遺留解決方案相比，您將必須更多地理解、深入研究文件並組裝您自己的個人耙子，並且沒有任何理論可以提前告訴您哪個耙子正在等待您。
來源： www.habr.com