總覽

使任何數(shù)據(jù)結(jié)構(gòu)或算法盡可能快的方法是使代碼完全執(zhí)行您想要的操作，而無需執(zhí)行其他操作。 建立一個可以做任何人想做的每件事的數(shù)據(jù)存儲的問題是，它做得不好。

自定義數(shù)據(jù)存儲在性能方面可以實現(xiàn)什么？

您可以支持；

• 大約75納秒的讀/寫延遲。
• 每秒處理4000萬次操作。
• 二進制編碼和壓縮功能可以將數(shù)據(jù)大小減少100倍或更多。 這樣可以節(jié)省內(nèi)存并提高可伸縮性。
• 控制復(fù)制如何利用您的網(wǎng)絡(luò)或與數(shù)據(jù)庫同步。

我們真的需要可定制的數(shù)據(jù)存儲嗎？

大多數(shù)開發(fā)人員不太在意其數(shù)據(jù)存儲的效率，而通用數(shù)據(jù)存儲足夠好地工作并隱藏其實際工作方式的細節(jié)。 這可以為開發(fā)人員節(jié)省大量時間，使他們不必擔(dān)心數(shù)據(jù)存儲如何工作的細節(jié)。

有時候，選擇數(shù)據(jù)存儲及其操作方式確實很重要。 如果數(shù)據(jù)存儲空間被大量使用，那么數(shù)據(jù)的排列方式，數(shù)據(jù)提供的功能以及同樣重要的是，數(shù)據(jù)存儲所不具有的功能確實很重要。 您不想支付不使用的支持功能的開銷。

為什么無功系統(tǒng)有更高的要求？

反應(yīng)系統(tǒng)對及時性有更高的要求，需要在幾毫秒甚至幾微秒的時間內(nèi)查看事件/更新。

反應(yīng)性系統(tǒng)更可能在乎數(shù)據(jù)如何到達最終狀態(tài)。 與輪詢系統(tǒng)不同，在輪詢系統(tǒng)中，您更有可能僅看到多次更改的最終結(jié)果，而被動系統(tǒng)可能需要準(zhǔn)確查看以什么順序進行了哪些更改。

低延遲，高吞吐量

一個簡單的線程安全的分段鍵值存儲可以具有大約75納秒的延遲，并且每秒支持4000萬次訪問（獲取或放置）。 添加對更多功能的支持將影響性能，因此，如果性能也很關(guān)鍵，則只想添加所需的功能。

即使是簡單的事情，例如添加一個時間戳，它可能需要30納秒的聲音，但可能意味著操作時間要長50％。

您想自定義哪些選項？

您是否需要總體訂購，基于商店的訂購，基于細分的訂購或基于密鑰的訂購？

排序約束與事件的鎖定或序列化緊密相關(guān)。 鎖定更易于實現(xiàn)并支持更豐富的功能，但是無鎖定算法不僅可以更快，更可擴展且具有更一致的延遲。

在數(shù)據(jù)存儲中，通過總排序，您將以一致的順序看到所有更改。 盡管這是最安全的選擇，但它對所有數(shù)據(jù)提出了全局序列化要求。 這極大地限制了并發(fā)更新的選項。 這確實簡化了鎖定，因為您對所有數(shù)據(jù)都具有全局鎖定。

另一種方法是訂購數(shù)據(jù)存儲。 這意味著您將知道商店所有更改的確切順序，但不會記錄商店之間的更改。 （您可以添加時間戳以獲取發(fā)生更改的理想時間）

要允許商店內(nèi)的并發(fā)，您可以使用細分或基于頁面的排序。 更新分配給細分的條目時，該細分被鎖定，但其他細分也可以更新。 您可以獲取該細分受眾群中所有事件的順序，但不能獲得細分受眾群之間的所有事件的順序。

僅通過限制單個鍵的更改順序就可以實現(xiàn)最大的并發(fā)性。 這樣，可以同時更新任意數(shù)量的密鑰，但是至少您知道什么密鑰可以持續(xù)更新。

最后，您可能不需要任何這些。 如果條目從未更改，它存在或不存在，則這特別有用。 您可能要防止任何記錄被更改。 即只能添加記錄。 如果將具有相同詳細信息的相同記錄添加兩次，則可以接受并將其視為重復(fù)項。

共享內(nèi)存數(shù)據(jù)存儲

我們發(fā)現(xiàn)特別有用的功能是能夠在同一臺機器上的JVM之間共享數(shù)據(jù)。 這允許所有JVM以內(nèi)存速度訪問數(shù)據(jù)。

盡管此功能不會降低解決方案的速度，但確實會在設(shè)計上施加一些限制，以使其能夠正常工作。 特別是，Java不支持JVM之間共享的堆，要共享您需要使用堆外內(nèi)存的內(nèi)存。

復(fù)制模型

有很多方法可以復(fù)制數(shù)據(jù)。

• 最終的一致性。 我們喜歡這種模型，因為它可以很好地處理大腦分裂的情況。
• 事務(wù)更新。 事件對于群集中的所有節(jié)點都是可見的，或者都不可見。
• 至少一個備份。 更新被保存到至少兩個節(jié)點。 如果失敗，則數(shù)據(jù)不會丟失。 這可能比確保每個節(jié)點都接受更新要快。
• 多集群復(fù)制。 盡管可以在本地群集中自由復(fù)制數(shù)據(jù)，但是您可能需要控制哪些數(shù)據(jù)可以復(fù)制到區(qū)域之間以及如何執(zhí)行。
• 流量整形可能需要控制更新速率，使用的帶寬以及是否使用壓縮。

同步或異步持久性

我們的解決方案盡力使同步速度與大多數(shù)異步執(zhí)行更新的解決方案一樣快。 這有助于減少開銷和復(fù)雜性。

通常，對內(nèi)存映射文件的寫操作不會立即刷新到磁盤，因此，只要您沒有使磁盤子系統(tǒng)超載，磁盤子系統(tǒng)的選擇就無關(guān)緊要。 就吞吐量而言，重要的是帶寬利用率。 如果持續(xù)使用帶寬的一小部分，則可能很快就會用完磁盤空間。 如果您僅以12 MB / s的速度持續(xù)寫入，則每天將超過1 TB。

我們測試過的操作系統(tǒng)不會完全隱藏磁盤子系統(tǒng)。 對于每十個寫入中的一個或每一百個寫入中的一個，延遲將取決于您所擁有的磁盤子系統(tǒng)的類型。 如果您關(guān)心99％的切片延遲，那么選擇磁盤子系統(tǒng)仍然很重要。

您將假設(shè)任何關(guān)心性能的人都將使用SSD，而不是PCI-SSD，因為它們的延遲比旋轉(zhuǎn)磁盤快約100倍。 企業(yè)SSD的IOPS（每秒IO）數(shù)也大約高100倍。 臺式機固態(tài)硬盤可以高出1000倍，因此您可以期望這也將成為企業(yè)磁盤的標(biāo)準(zhǔn)。

不幸的是，在大型組織中并不是那么簡單，如果完全可以得到批準(zhǔn)，那么購買SSD驅(qū)動器可能會花費很長時間，例如6到12個月。

一種解決方法是將數(shù)據(jù)異步寫入內(nèi)存，然后在另一個線程中將其后臺處理到磁盤。

數(shù)據(jù)應(yīng)存儲為文本還是二進制？

二進制數(shù)據(jù)通常比文本更有效，除非數(shù)據(jù)已經(jīng)是文本格式。 通過將高度冗長的格式（例如XML或JSon）轉(zhuǎn)換為二進制格式（在檢索時會轉(zhuǎn)換回文本），可以取得一些收益。 這是一種格式特定的壓縮，即使與普通壓縮相比也可以很好地工作（請參閱下一個）

轉(zhuǎn)換為二進制格式可以將數(shù)據(jù)大小減少3到10倍。 如果格式有損，則可以節(jié)省更多空間。 （例如，是否可以刪除空格）如果還使用通用壓縮，則壓縮率可以達到20到200倍。

是否應(yīng)該壓縮數(shù)據(jù)？

壓縮數(shù)據(jù)是CPU與消耗的空間之間的折衷。 對于使用更多CPU和進一步壓縮數(shù)據(jù)的策略，有許多壓縮策略要么使用更少的CPU，要么不進行壓縮。

這不僅可以節(jié)省磁盤空間，還可以節(jié)省內(nèi)存。 這使您可以擴展可以有效存儲的數(shù)據(jù)量。

如果您有足夠的內(nèi)存，則可能要避免壓縮以節(jié)省CPU。

如果您的數(shù)據(jù)條目很大，則壓縮每個單獨的條目都可以很好地工作。 如果您的數(shù)據(jù)條目很小，則可以通過壓縮條目塊來獲得顯著收益。

您甚至可能需要一種混合方法，其中不壓縮最新數(shù)據(jù)，而異步壓縮長期數(shù)據(jù)。

如果使用通用壓縮，則壓縮比為5到50倍。

在反應(yīng)式系統(tǒng)中，使用者可以合并錯過的更新嗎？

如果您的系統(tǒng)使用速度較慢，則需要一種簡單的方法來趕上。 您將始終擁有暫時落后的消費者，但是在某些系統(tǒng)中，他們可能會遠遠落后。 例如，在“編年史隊列”中，使用者可以不僅僅停留在生產(chǎn)者之后，還可以充當(dāng)主存儲器，因為它從不丟棄更新。

如果您刪除更新，則假設(shè)同一密鑰有很多更新，或者有一個簡單的合并策略，則可以Swift趕上。

有時候，無論事件多久，您都需要查看每個事件/消息/變更。 這對于審核目的很有用。

您可能需要一種混合方法，其中記錄每個事件，但是某些使用者可以跳過鍵的最新更新。

批處理數(shù)據(jù)

在每筆事務(wù)開銷較高的事務(wù)數(shù)據(jù)中，使用批處理確實有幫助。 批處理對于IO操作再次很有用，以減少開銷。

我們的大多數(shù)解決方案都試圖使每個事務(wù)的開銷非常低，以最大程度地減少延遲，因此添加批處理會帶來比節(jié)省的開銷更多的開銷。

更強大的安全模型

您可能需要控制對單個集合的訪問，但是可能還需要向每個單獨的鍵添加訪問控制列表。

您可能需要基于這些條目的內(nèi)容訪問條目。 例如，紐約的員工可能能夠使用location = New York更新條目。 區(qū)域，組織或團隊中的員工可以管理自己的數(shù)據(jù)。

時間戳變更

更新/事件應(yīng)加蓋時間戳。 這可能是有用的，但是如果不使用的話，則是不小的開銷。

審核信息并簡化安全性

進行更改后，您可能需要記錄其他信息，例如； 誰，何時，從哪個客戶進行更改。 這對于審核目的和簡化安全模型很有用。

可以使用戶意識到他們可以做自己需要做的事情，而不是進行嚴(yán)格的安全控制（用戶可能會避免遇到的障礙而不是有用的障礙），但是所有更改都已記錄下來，因此用戶可能會更仔細地思考關(guān)于他們應(yīng)該做什么。 如果您還具有撤消/更正所做更改的能力，則這可能是處理錯誤的另一種方法。

《紀(jì)事報》是開源的嗎？

我們有兩種開源數(shù)據(jù)存儲解決方案，Chronicle Queue和Chronicle Map，它們可以很好地用于特定的用例，您不妨先嘗試一下，看看它們是否滿足您的需求。

Chronicle Journal的設(shè)計具有更高的可定制性，從而需要更多的咨詢來實現(xiàn)解決方案。 因此，它在GitHub上，但只有擁有支持協(xié)議的客戶才能訪問。

如果您有興趣獲得包括記事本在內(nèi)的Chronicle支持，請聯(lián)系sales@chronicle.software

翻譯自: https://www.javacodegeeks.com/2015/09/chronicle-journal-customizable-data-store.html

總結(jié)

以上是生活随笔為你收集整理的纪事日记–可自定义的数据存储的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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