當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

纪事本乱码_纪事日记–可自定义的数据存储

發(fā)布時(shí)間：2023/12/3 编程问答 42 豆豆

生活随笔收集整理的這篇文章主要介紹了纪事本乱码_纪事日记–可自定义的数据存储小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

紀(jì)事本亂碼

總覽

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

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

您可以支持；

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

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

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

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

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

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

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

低延遲，高吞吐量

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

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

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

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

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

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

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

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

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

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

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

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

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

復(fù)制模型

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

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

同步或異步持久性

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

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

我們測(cè)試過的操作系統(tǒng)不會(huì)完全隱藏磁盤子系統(tǒng)。對(duì)于每十個(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倍。臺(tái)式機(jī)固態(tài)硬盤可以高出1000倍，因此您可以期望這也將成為企業(yè)磁盤的標(biāo)準(zhǔn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

時(shí)間戳變更

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

審核信息并簡(jiǎn)化安全性

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

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

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

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

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

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

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