视频

了解更多
需要了解数据持久性和数据可用性之间的区别吗?你最喜欢的狂欢观看节目可以帮助你阐明其中的区别。
数据有保质期。数据容易受到比特腐烂的影响——也称为数据衰减、比特衰减和数据腐烂。这对软件和媒体来说都是如此,例如那些消失的网站,它们带走了多年的新闻文章、电影或其他信息,其中只有一小部分被 Wayback Machine 捕获。
但是,比特衰减也适用于存储设备的物理介质以及由此导致的存储在其中的信息的數據完整性下降。随着时间的推移,丢失了一点点这里和那里的一点点字节,最终会导致无法信任的数据。数据丢失意味着,数据消失了——可能是重要的文档,例如历史电子商务记录或税务信息。更糟糕的是,驱动器故障可能意味着数据被不准确地存储,这意味着错误的信息。
这不仅仅是一个技术问题。在 金融服务 等行业,脆弱或缓慢的数据可能导致信誉良好的品牌名称失去客户忠诚度,损害其声誉并导致收入损失。
现在,举手,看看你是否在流媒体服务上有一个最喜欢的节目。
根据 Statista 的数据,2022 年,83% 的美国消费者使用了点播流媒体服务。通常,客户希望在他们想要的时候观看他们最喜欢的电视节目,无论他们在世界的哪个地方。该电视节目的媒体——假设是《安多》——是相同的一组比特,无论在何处观看,因此它可以作为持久数据的良好示例。它说明了数据持久性和 可用性 的重要性,以及使用不良数据的影响。
不,持久性和可用性不是一回事!但是,要使用可信数据,持久性和可用性必须协同工作。没有一个是无法实现真正的數據品質的。
让我们用你最喜欢的狂欢观看节目来探究为什么会出现这种情况。
数据持久性是一种在发生故障或中断时保护数据免受丢失或损坏的方法。
数据持久性是确保数据完好无损(并保持完好无损)的过程,没有任何降级。从本质上讲,持久数据意味着未受损的数据。
在流媒体方面,想象一下你正准备观看最新的星球大战衍生剧。你的 4K 电视已准备好。你听说效果令人惊叹。然而,由于某种原因,节目开始了,但质量却大打折扣。
在这种情况下,某些东西可能干扰了流媒体的数据持久性,即质量下降,但信息仍然可用。
了解 Redis 如何通过 AOF 和快照持久性选项来提高 数据持久性。
数据持久性依赖于持久数据。
当数据是持久性的时,它在下一个 应用程序会话 开始时即可访问并可以使用。预计在最后一次会话和下一次会话之间不会丢失任何数据。
为了保持数据持久性,将数据持久化到磁盘至关重要。数据以两种不同方式之一定期持久化到磁盘:追加文件 (AoF) 和快照。
AoF 提供了两种将写入操作追加到磁盘的选择:
对于任何需要实时获取完整数据的组织而言,AoF 通常是最明智的选择。
快照是一种数据复制,它在特定时间点捕获数据库的状态。与 AoF 不同,快照通常以 1、6 或 12 小时的间隔写入磁盘。
数据库持久性的标准并不统一。持久性配置取决于数据库类型(是 NoSQL 还是关系数据库)和数据库大小,以及其他事项。因此,最好在建立架构时做出配置决策。
另一种选择是编辑现有数据库的配置。请注意,更改不会自动进行。更改数据库的持久性模型可能需要一些时间才能完成。
换句话说,如何衡量数据库对比特衰减或丢失导致的损坏的恢复能力?
持久性通常用百分比表示,例如 11 个 9 (99.9999999%) 或 99.9999999% 的持久性,根据 Google Cloud 的说法,这意味着“即使有十亿个对象,你也很可能在百年内不会丢失任何一个!”
所有这些 9 的背后的数学需要一些密集的统计学,因此请注意,用于衡量数据持久性的主要统计测量通常是泊松分布和二项式分布。而 泊松分布 衡量的是事件在给定时间间隔内发生 (k) 次的概率,而 二项式分布 则评估可重复测试中两种结果之一的概率,即“成功”或“失败”。
数据可用性意味着数据是可操作的。当请求数据时,会提供数据。换句话说,数据可用性是系统正常运行时间的同义词。
这就是为什么数据持久性和可用性共同创造了完美的公式:未受损的数据加上正常运行时间和可访问性或对未损坏文件的即时访问。
哦,是的!让我们再回到新的星球大战系列一秒钟。
你在节目中看到一个悬念,但你必须赶往机场进行国际商务旅行。你可以在到达酒店后开始一个新的会话。当你重新启动节目时,就像魔法一样,你会从你上次离开的地方继续观看,即使你身处地球的另一端。这就是可用性和高可用性的魅力所在。它赋予你力量,让你说,“我要让我的小尤达清晰锐利地出现在意大利,即使我在堪萨斯州时暂停了他。”
尽管你的位置发生了重大变化,但让接下来的会话如此流畅和成为可能的原因是主动-主动地理分布——而不是“原力”,尽管那会很酷。主动-主动地理分布采用数据库的复制数据,并使其可用于分布在多个可用区域的节点。通过在具有副本的本地节点中建立节点,延迟会大大降低,从而改善观看体验。
小尤达行动缓慢。你的数据库不应该让事情变得更糟。
数据可用性是通过将总正常运行时间除以正常运行时间加上停机时间的总和来衡量的:可用性 = 正常运行时间 ÷ (正常运行时间 + 停机时间)。
可用性通常被称为“五个 9”或“十一个 9”,但通常以百分比表示,例如 99.999%。最终,“五个 9”平均每年约有 5 分钟的停机时间。
放在上下文中,假设我们知道某个实例在一周内(168 小时)仅可使用 145 小时。这是 13 小时的差异。在这种情况下,计算将类似于:145 ÷ (145 + 13) = 91.772% 的可用性。
高可用性架构非常有趣,(对于技术人员而言)探索其最佳潜力的可能性非常有趣。查看 高可用性架构揭秘 和 什么是数据复制,以获取有关集群和灾难恢复的更多信息。
2022 年,Uptime Institute 的停机分析发现,“超过 60% 的故障导致至少 10 万美元的总损失,远高于 2019 年的 39%。在同一时期内,导致超过 100 万美元损失的停机事件比例从 11% 上升至 15%。”
这是一个现实世界的结果。元宇宙和游戏平台 Roblox 在 2021 年 10 月发生了 73 小时的停机。据数据中心前沿报道,这给该公司带来了估计 2500 万美元的预订损失。
例如,在金融行业,数十亿美元的交易取决于谁先到达——每毫秒的数据不可用都可能转化为收入损失、合作机会损失以及潜在的客户流失。
Netflix 在 2022 年 7 月发生了一次 1.5 小时的停机事件,影响了美国、法国和印度的客户。据 路透社 报道,这引发了负面反应,例如,“周五晚上,@netflix 停机了!你的周五晚上过得怎么样?”
希望你与 Baby Yoda 的周五夜晚过得愉快!
想了解更多关于 Redis Enterprise 的内置灾难恢复功能?观看我们的 技术讲座。