紀(jì)事本 亂碼

總覽

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

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

您可以支持；

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

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

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

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

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

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

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

低延遲，高吞吐量

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

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

您希望能夠自定義哪些選項(xiàng)？

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

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

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

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

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

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

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

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

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

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

復(fù)制模型

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

• 最終的一致性。 我們贊成這種模型，因?yàn)樗梢院芎玫靥幚泶竽X分裂情況。
• 事務(wù)更新。 事件對于群集中的所有節(jié)點(diǎn)都是可見的，或者都不可見。
• 至少一個(gè)備份。 更新被保存到至少兩個(gè)節(jié)點(diǎn)。 如果失敗，則數(shù)據(jù)不會丟失。 這可能比確保每個(gè)節(jié)點(diǎn)都接受更新要快。
• 多集群復(fù)制。 盡管可以在本地群集中自由復(fù)制數(shù)據(jù)，但是您可能需要控制哪些數(shù)據(jù)可以復(fù)制到區(qū)域之間以及如何執(zhí)行。
• 流量整形可能需要控制更新速率，使用的帶寬以及是否使用壓縮。

同步或異步持久性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在React式系統(tǒng)中，使用者可以合并錯(cuò)過的更新嗎？

如果您的系統(tǒng)使用速度較慢，則需要一種簡單的方法來趕上。 您將始終擁有暫時(shí)落后的消費(fèi)者，但是在某些系統(tǒng)中，他們可能會落后很長一段時(shí)間。 例如，在“編年史隊(duì)列”中，使用者可以不僅僅停留在生產(chǎn)者后面，而不會刪除更新。

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

有時(shí)您需要查看每個(gè)事件/消息/更改，無論它們多大。 這對于審核目的很有用。

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

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

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

我們的大多數(shù)解決方案都試圖將每筆交易的開銷降至極低，以最大程度地減少延遲，因此添加批處理可能會帶來比節(jié)省的開銷更多的開銷。

更強(qiáng)大的安全模型

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

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

時(shí)間戳變更

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

審核信息并簡化安全性

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

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

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

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

Chronicle Journal的設(shè)計(jì)具有更高的可定制性，從而需要更多的咨詢來實(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

紀(jì)事本 亂碼

總結(jié)

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

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