纪事日记–可自定义的数据存储

总览

使任何数据结构或算法尽可能快的方法是使代码完全执行您想要的操作，而无需执行其他操作。建立一个可以做任何人想做的每件事的数据存储的问题是，它做得不好。

自定义数据存储在性能方面可以实现什么？

您可以支持；

大约75纳秒的读/写延迟。
每秒处理4000万次操作。
二进制编码和压缩功能可以将数据大小减少100倍或更多。这样可以节省内存并提高可伸缩性。
控制复制如何利用您的网络或与数据库同步。

我们真的需要可定制的数据存储吗？

大多数开发人员不太在意其数据存储的效率，而通用数据存储足够好地工作并隐藏其实际工作方式的细节。这可以为开发人员节省大量时间，使他们不必担心数据存储如何工作的细节。

有时候，选择数据存储及其操作方式确实很重要。如果数据存储空间被大量使用，那么数据的排列方式，数据提供的功能以及同样重要的是，数据存储所不具有的功能确实很重要。您不想支付不使用的支持功能的开销。

为什么无功系统有更高的要求？

反应系统对及时性有更高的要求，需要在几毫秒甚至几微秒的时间内查看事件/更新。

反应性系统更可能在乎数据如何到达最终状态。与轮询系统不同，在轮询系统中，您更有可能仅看到多次更改的最终结果，而被动系统可能需要准确查看以什么顺序进行了哪些更改。

低延迟，高吞吐量

一个简单的线程安全的分段键值存储可以具有大约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倍。

在反应式系统中，使用者可以合并错过的更新吗？

如果您的系统使用速度较慢，则需要一种简单的方法来赶上。您将始终拥有暂时落后的消费者，但是在某些系统中，他们可能会远远落后。例如，在“编年史队列”中，使用者可以不仅仅停留在生产者之后，还可以充当主存储器，因为它从不丢弃更新。

如果您删除更新，则假设同一密钥有很多更新，或者有一个简单的合并策略，则可以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