紀事本 亂碼

總覽

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

自定義數據存儲在性能方面可以實現什么？

您可以支持；

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

我們真的需要可定制的數據存儲嗎？

大多數開發人員不太擔心其數據存儲的效率如何，而通用數據存儲則可以很好地工作并隱藏其實際工作方式的細節。 這可以為開發人員節省大量時間，使他們不必擔心數據存儲如何工作的細節。

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

為什么無功系統有更高的要求？

響應式系統對及時性有更高的要求，需要在幾毫秒甚至幾微秒的時間內查看事件/更新。

React性系統更可能關心數據如何到達最終狀態。 與輪詢系統不同，在輪詢系統中，您更有可能僅看到多次更改的最終結果，而被動系統可能需要準確查看按什么順序進行了哪些更改。

低延遲，高吞吐量

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

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

您希望能夠自定義哪些選項？

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

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

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

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

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

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

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

共享內存數據存儲

我們發現特別有用的功能是能夠在同一臺機器上的JVM之間共享數據。 這允許所有JVM以內存速度訪問數據。

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

復制模型

有很多方法可以復制數據。

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

同步或異步持久性

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

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

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

您將假設任何關心性能的人都將使用SSD，而不是PCI-SSD，因為它們的延遲大約比旋轉磁盤快100倍。 企業SSD的IOPS（每秒IO）數也大約高100倍。 臺式機固態硬盤可以高出1000倍，因此您可以期望這也將成為企業磁盤的標準。

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

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

數據應存儲為文本還是二進制？

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

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

是否應該壓縮數據？

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

這不僅可以節省磁盤空間，還可以節省內存。 這使您可以擴展可以有效存儲的數據量。

如果您有足夠的內存，則可能要避免壓縮以節省CPU。

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

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

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

在React式系統中，使用者可以合并錯過的更新嗎？

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

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

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

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

批處理數據

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

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

更強大的安全模型

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

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

時間戳變更

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

審核信息并簡化安全性

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

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

《紀事報》是開源的嗎？

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

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

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

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

紀事本 亂碼

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。