cassandra

介紹

多年來， Grid Dynamics擁有許多與NoSQL相關(guān)的項目，尤其是Apache Cassandra。 在這篇文章中，我們要討論一個給我們帶來挑戰(zhàn)的項目，而我們在該項目中試圖回答的問題今天也仍然適用。

數(shù)字營銷和在線廣告在2012年很受歡迎，并且對它們的需求僅在增加。 實時出價（RTB）是領(lǐng)域的組成部分。 實時出價工具假設(shè)通過數(shù)字廣告的實時拍賣來放置（購買和出售）廣告。 如果中標，買方的廣告將立即顯示在發(fā)布商的網(wǎng)站上。 實時出價需要服務器端的低延遲響應（<100ms），否則出價將丟失。 我們的客戶之一，一家美國媒體公司，對實時出價和用戶跟蹤（即對網(wǎng)站訪問者的行為及其偏好的分析）感興趣。

最初，客戶用于處理RTB請求的基礎(chǔ)結(jié)構(gòu)包括安裝Kyoto Cabinet 。 在下圖（圖片1）上，您可以看到RTB和第三方請求的來源。 所有請求都發(fā)送到實時應用程序，該應用程序在數(shù)據(jù)庫中執(zhí)行查找和更新請求。 Kyoto Cabinet會將整個數(shù)據(jù)集保存在內(nèi)存中，而自定義附件提供了保留管理和持久性功能。

圖1.以前的體系結(jié)構(gòu)。

從延遲的角度來看，上述架構(gòu)足夠好，但是它有幾個缺點：

可擴展性。 該架構(gòu)假定僅安裝了京都櫥柜的服務器就可以垂直擴展。 當時，每臺服務器都配備了約50GB的內(nèi)存。 眾所周知，增加內(nèi)存量可以長期解決該問題。

堅固性。 如果發(fā)生故障，僅安裝京都櫥柜可能會導致非常嚴重的后果。

跨數(shù)據(jù)中心復制。 該體系結(jié)構(gòu)在數(shù)據(jù)中心之間沒有自動同步。 手動同步確實令人頭疼，因為它需要大量其他操作。

我們的任務是為系統(tǒng)創(chuàng)建一個新的體系結(jié)構(gòu)，該體系結(jié)構(gòu)不具有上述缺點，同時使我們能夠在響應延遲方面獲得良好的結(jié)果。 換句話說，我們需要一個數(shù)據(jù)存儲區(qū)，該數(shù)據(jù)存儲區(qū)將允許我們保留用戶個人資料以及對其進行查找和更新，并且所有操作都將在特定時間間隔內(nèi)執(zhí)行。 該體系結(jié)構(gòu)應該圍繞這樣的數(shù)據(jù)存儲構(gòu)建。

要求

新的體系結(jié)構(gòu)旨在解決所有這些問題。 對新體系結(jié)構(gòu)的要求如下：

• 持久性（一個或兩個數(shù)據(jù)中心停電時，任何數(shù)據(jù)都不應丟失）
• 高可用性（應該沒有單點故障）
• 可伸縮性（通過添加更多節(jié)點，數(shù)據(jù)庫量應該相對容易增加）
• 跨數(shù)據(jù)中心復制（兩個數(shù)據(jù)中心之間的數(shù)據(jù)應同步）
• 數(shù)據(jù)的TTL（過期的用戶配置文件應自動清除）
• 數(shù)據(jù)量（約10億個具有多個屬性的同類記錄，其中一個記錄約為400字節(jié)）
• 吞吐量（每個數(shù)據(jù)中心每秒5000次隨機讀取+每秒5000次隨機寫入）
• 響應延遲（平均3毫秒，對于99％的請求，處理時間不應超過10毫秒）

此外，我們還有一些與基礎(chǔ)架構(gòu)有關(guān)的限制。 限制之一是每個數(shù)據(jù)中心最多只能為每個數(shù)據(jù)庫安裝八臺服務器。 同時，我們可以選擇某些服務器硬件，例如內(nèi)存量，存儲類型和大小。 客戶的其他要求之一是使用復制因子TWO，由于數(shù)據(jù)的統(tǒng)計性質(zhì)，該因子是可以接受的。 這樣可以降低硬件成本。

我們研究了幾種可能滿足我們要求的解決方案，最后選擇了Cassandra。 Cassandra的新體系結(jié)構(gòu)成為一種更為優(yōu)雅的解決方案。 它只是兩個數(shù)據(jù)中心之間同步的Cassandra集群。 但是有關(guān)其硬件規(guī)格的問題仍未得到解答。 最初，我們有兩個選擇：

• SDD，但內(nèi)存較少（少于整個數(shù)據(jù)集）
• HDD和更多內(nèi)存（足以保留整個數(shù)據(jù)集）

實際上，還有一個選項暗示使用硬盤驅(qū)動器和更少的內(nèi)存，但是這種配置不能提供我們所要求的可接受的讀取延遲，因為從HDD隨機讀取甚至需要10ms RPM的硬盤也需要8毫秒。 結(jié)果，它從一開始就被拒絕了。

因此，我們有兩種配置。 經(jīng)過一些調(diào)整（調(diào)整本身將在下一節(jié)中討論），它們都滿足了我們的需求。 他們每個人都有自己的優(yōu)點和缺點。 SSD配置的主要缺點之一是成本。 當時，企業(yè)級SDD相當昂貴。 此外，一些數(shù)據(jù)中心提供商對使用SSD維護服務器收取額外費用。

使用HDD的方法意味著從磁盤緩存中讀取數(shù)據(jù)。 該配置的大多數(shù)缺點與高速緩存有關(guān)，例如，冷啟動問題。 這是由于在系統(tǒng)重新引導后清除了緩存而造成的。 結(jié)果，從HDD讀取未緩存的數(shù)據(jù)會導致額外的超時。 實際上，超時是在10毫秒內(nèi)沒有響應的請求。 此外，由于在啟動時從Cassandra服務器復制了大量數(shù)據(jù)，可能會意外清理磁盤緩存。 最后一個問題與內(nèi)存大小有關(guān)，而不是與緩存有關(guān)。 增加單個節(jié)點的數(shù)據(jù)量非常困難。 可以添加一個額外的HDD或幾個HDD，但是單臺計算機的內(nèi)存大小是有限的，并且不是很大。

最后，我們設(shè)法解決了大多數(shù)上述HDD配置問題。 通過使用cat實用程序讀取數(shù)據(jù)并將其輸出重定向到啟動時的/ dev / null，解決了冷啟動問題。 修補了用于創(chuàng)建備份的rsync后，與磁盤緩存清理相關(guān)的問題就消失了。 但是內(nèi)存限制問題仍然存在，并在以后引起了一些麻煩。

最后，客戶端選擇了HDD + RAM配置。 每個節(jié)點在RAID 5 + 0中配備了96GB內(nèi)存和8個HDD。

調(diào)整卡桑德拉

我們開始使用的Cassandra版本是1.1.4。 進一步，在開發(fā)過程中我們嘗試了不同的版本。 最后，我們決定批準使用1.2.2版，因為它包含我們已承諾對Cassandra存儲庫進行的更改。 例如，我們添加了一項改進 ，該改進使我們可以為每個列族分別指定populate_io_cache_on_flush選項（它將在內(nèi)存表刷新和壓縮時填充磁盤緩存）。

我們必須測試其余兩種配置，以選擇一種更好的配置。 在我們的測試中，我們使用了一個Cassandra群集，該群集包含3個節(jié)點，每個節(jié)點具有64GB內(nèi)存和8個內(nèi)核。 我們從寫操作開始測試。 在測試期間，我們以每秒7000次寫入的速度將數(shù)據(jù)寫入Cassandra。 選擇的速度與群集大小和所需的吞吐量成正比（將寫入速度加倍，以考慮跨數(shù)據(jù)中心復制的開銷）。 這種方法論適用于所有測試。 值得一提的是，我們使用了以下首選項：

• 復制因子= 2
• write_consistency_level =兩個
• 分層壓縮策略

之所以使用LeveledCompactionStrategy（LCS），是因為該客戶端的工作流應該具有很多更新操作。 使用LCS的另一個原因是整體數(shù)據(jù)集大小和讀取延遲減小。 兩種配置的測試結(jié)果均相同：

• 平均延遲時間：?1ms
• 超時：0.01％
• CPU使用率：<5％

兩種配置都滿足了我們的需求，盡管在此階段我們沒有花時間調(diào)查超時的性質(zhì)。 超時將在后面討論。 據(jù)推測，大多數(shù)響應時間是由網(wǎng)絡傳輸占用的。 另外，我們嘗試增加每秒的寫查詢次數(shù)，并產(chǎn)生了良好的結(jié)果。 沒有明顯的性能下降。

之后，我們進入下一步，即測試讀取操作。 我們使用了相同的集群。 所有讀取請求均以read_consistency_level = ONE發(fā)送。 寫入速度設(shè)置為每秒3500個查詢。 每個服務器上大約有40GB的數(shù)據(jù)，單個記錄的大小約為400字節(jié)。 因此，整個數(shù)據(jù)集適合內(nèi)存大小。 測試結(jié)果如下：

表1.讀取操作的初始測試結(jié)果

查看兩種配置的測試結(jié)果，我們發(fā)現(xiàn)超時值的百分比不令人滿意，它們是所需值的2-3倍（2-3％對1％）。 此外，我們還擔心CPU負載過高（約20％）。 至此，我們得出的結(jié)論是我們的配置有問題。

找到與超時相關(guān)的問題的根源并不是一件容易的事。 最終，我們修改了Cassandra的源代碼，并為所有讀取請求返回了一個固定值（跳過從SSTables，memtables等進行的任何查找）。 之后，再次對讀取操作執(zhí)行相同的測試。 結(jié)果是完美的：GC活動和CPU使用率顯著降低，并且?guī)缀鯖]有檢測到超時。 我們恢復了更改，并嘗試為GC找到最佳配置。 在嘗試了其選項之后，我們確定了以下配置：

• -XX：+ UseParallelGC
• -XX：+ UseParallelOldGC
• -XX：MaxTenuringThreshold = 3
• -Xmn1500M
• -Xmx3500M
• -Xms3500M

我們設(shè)法減少了GC對Cassandra性能的影響。 值得注意的是，讀取操作的超時次數(shù)超過了寫入操作的超時次數(shù)，因為Cassandra在讀取過程中在堆中創(chuàng)建了很多對象，這又導致大量的CPU使用率。 至于等待時間，它足夠低，并且可以很大程度上歸因于數(shù)據(jù)傳輸時間。 與更密集的讀取一起執(zhí)行相同的測試表明，與寫入操作相比，增加讀取操作的數(shù)量會顯著影響超時的數(shù)量。 據(jù)推測，這一事實與GC的生長活性有關(guān)。

眾所周知，應該為每種情況分別配置GC。 在這種情況下，并發(fā)標記掃描（CMS）效果不如Parallel Old GC。 將堆大小減小到相對較小的值也很有幫助。 盡管上面的配置可能不是最好的配置，但它是滿足我們需求的一種。 另外，我們嘗試了不同版本的Java。 Java 1.7使我們相對于Java 1.6有了一些性能改進。 相對超時數(shù)減少了。 我們嘗試的另一件事是在Cassandra中啟用/禁用行/鍵緩存。 禁用緩存會略微減少GC活動。

下一個產(chǎn)生令人驚訝結(jié)果的選項是池中處理Cassandra中的讀/寫請求的線程數(shù)。 由于我們的基準測試模擬了多個客戶端（最多500個線程），因此將該值從32增加到128會對性能產(chǎn)生重大影響。 另外，我們嘗試了不同版本的CentOS和SELinux的各種配置。 切換到更高的6.3版本后，我們發(fā)現(xiàn)Java期貨在較短的時間內(nèi)通過超時返回了控制權(quán)。 SELinux的配置更改對性能沒有影響。

解決讀取性能問題后，我們便以混合模式（讀取+寫入）進行了測試。 在這里，我們觀察到一種情況，如下圖所示（圖2）。 每次刷新到SSTable之后，Cassandra開始從磁盤讀取數(shù)據(jù)，這又導致客戶端超時增加。 此問題與HDD + RAM配置有關(guān)，因為從SSD讀取不會導致其他超時。

圖2.改進之前混合模式（讀+寫）中的磁盤使用情況。

我們嘗試修改Cassandra配置選項，即populate_io_cache_on_flush（如上所述）。 默認情況下，此選項是關(guān)閉的，這意味著文件系統(tǒng)緩存未填充新的SSTables。 因此，當訪問來自新SSTable的數(shù)據(jù)時，將從HDD中讀取數(shù)據(jù)。 將其值設(shè)置為true可解決此問題。 下圖（圖3）顯示了改進后的磁盤讀取數(shù)。

圖3.改進后，混合模式下的磁盤使用情況（讀+寫）。

換句話說，在整個數(shù)據(jù)集緩存在內(nèi)存中后，即使在混合模式下，Cassandra也停止了從磁盤讀取數(shù)據(jù)。 值得注意的是，雖然從配置文件中排除了該選項，但是從2.1版開始，默認情況下在Cassandra中populate_io_cache_on_flush選項處于打開狀態(tài)。 下面的摘要（表2）描述了我們嘗試的更改及其影響。

表2.對Cassandra和系統(tǒng)本身的更改及其對延遲的影響。

最后，應用了本文中描述的更改之后，我們在SSD和HDD + RAM配置上均取得了可接受的結(jié)果。 在調(diào)整Cassandra客戶端（我們使用Astyanax）以使其在復制因子為2的情況下正常運行并在超時的情況下可靠地按時返回控制方面也付出了很多努力。 我們還希望分享一些有關(guān)操作自動化，監(jiān)控以及確保跨數(shù)據(jù)中心復制正常工作的細節(jié)，但是很難在一個帖子中涵蓋所有方面。 如上所述，我們已經(jīng)開始使用HDD + RAM配置進行生產(chǎn)，并且可以毫無意外地可靠地工作，包括在不停機的情況下在活動集群上進行Cassandra升級。

結(jié)論

卡桑德拉（Cassandra）在引入項目時對我們來說是新手。 我們不得不花費大量時間來探索其功能和配置選項。 它使我們能夠?qū)崿F(xiàn)所需的體系結(jié)構(gòu)并按時交付系統(tǒng)。 同時，我們獲得了豐富的經(jīng)驗。 我們進行了大量工作，將Cassandra集成到我們的工作流程中。 我們對Cassandra源代碼的所有更改都已反饋給社區(qū)。 我們的數(shù)字營銷客戶受益于擁有更穩(wěn)定，可擴展的基礎(chǔ)架構(gòu)以及自動同步功能，從而減少了他們維護系統(tǒng)所需的時間。

關(guān)于網(wǎng)格動力學

Grid Dynamics是為Tier 1零售提供開放，可擴展的下一代商業(yè)技術(shù)解決方案的領(lǐng)先提供商。 Grid Dynamics在商務技術(shù)方面擁有深入的專業(yè)知識，并廣泛參與開源社區(qū)。 偉大的公司與Grid Dynamics合作，通過在全渠道平臺，產(chǎn)品搜索和個性化以及持續(xù)交付領(lǐng)域中實施和管理解決方案，獲得了可持續(xù)的業(yè)務優(yōu)勢。 要了解更多關(guān)于網(wǎng)格動態(tài)，找到我們在www.griddynamics.com或者按照我們的Twitter @GridDynamics。

翻譯自: https://www.javacodegeeks.com/2015/02/apache-cassandra-low-latency-applications.html

cassandra

總結(jié)

以上是生活随笔為你收集整理的cassandra_Apache Cassandra和低延迟应用程序的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。