网站开发公司的销售方式,大诚设计网站建设,菲律宾菠菜网站建设,怎样设置 自己的网站纪事本 乱码总览 使任何数据结构或算法尽可能快的方法是使代码完全执行您想要的操作#xff0c;而无需执行其他操作。 建立一个可以做任何人想做的每件事的数据存储的问题是#xff0c;它做得特别不好。 自定义数据存储在性能方面可以实现什么#xff1f; 您可以支持#… 纪事本 乱码 总览 使任何数据结构或算法尽可能快的方法是使代码完全执行您想要的操作而无需执行其他操作。 建立一个可以做任何人想做的每件事的数据存储的问题是它做得特别不好。 自定义数据存储在性能方面可以实现什么 您可以支持 大约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支持请联系saleschronicle.software 翻译自: https://www.javacodegeeks.com/2015/09/chronicle-journal-customizable-data-store.html纪事本 乱码
