Key-Value 数据库指南
Key-Value 数据库
工作原理、主要特性、优势
Key-Value 数据库是近几十年数据库设计中的几项重大创新之一。与许多较新的数据库设计一样，它用与开发者产生共鸣的新方法取代了一些传统的设计方面。
通过彻底改变数据的存储和查询方式，Key-Value 数据库使企业能够利用他们掌握的数据做更多的事情。
什么是 Key-Value 数据库？
Key-Value 数据库（也称为 Key-Value 存储）是一种 noSQL 数据库。与先前在定义的表和列中存储数据的关系数据库不同，Key-Value 数据库而是使用单个或组合键来检索关联的值。它们一起被称为键值对。这些值可以是任何东西，从简单的像字符串或整数的数据类型到具有多个嵌套值的复杂对象。每个键都是一个唯一的标识符，它映射到一个值或正在存储的数据的位置。
人们在描述 Key-Value 数据库设计时，有时会解释说这种新型数据库就像应用于数据库系统的面向对象编程。OOP 中标记对象及其属性的一些相同想法也适用于 Key-Value 数据库及其构建方式。
Key-Value 数据库如何工作？
Key-Value 数据库具有键值对集合，其中键是标识符，值是有问题的数据。键值对与许多编程语言中哈希表的各种不同实现非常相似，例如 Python 中的字典和 Javascript 中的对象。Key-Value 数据库的主要区别在于，您的数据是通过您正在使用的数据库持久化和管理的。
在底层，Key-Value 数据库通过维护映射到磁盘上存储的数据的内存数据结构来工作。RAM 比从磁盘访问数据快得多，因此大多数数据库都将使用某种算法将频繁访问的数据保存在 RAM 中，并且仅在索引尚未存储在内存中时才回退到磁盘。
有些人将 Key-Value 数据库描述为“最简单”的 noSQL 数据库类型。它对于可扩展的数据设置和其他需要灵活性的企业用途非常有用。通过允许更自由的数据方向，Key-Value 数据库提供了一种存储数据的方式，以便更灵活地检索，以适应在开发过程中应用程序需求发生变化时经常需要的模式更改。
Key-Value 数据库在其实现方面可能存在显著差异，具体取决于预期用例。数据库之间的一些差异可能包括
- 一致性模型
- 键是否可以排序
- 复制
- 分片
- 序列化策略
Key-Value 数据库的特性
任何 Key-Value 数据库所需的最基本功能是使用键创建、更新、检索和删除数据的能力。但是，许多最流行的数据库都提供了超出基本功能的功能，以提高开发者的工作效率。以下是流行的 Key-Value 数据库提供的一些最常见的功能。
数据类型支持
许多 Key-Value 数据库都提供对定义的数据类型和半结构化数据的支持。这可以是像数组或嵌套字典之类的东西。通过向数据库提供有关您的数据的更多信息，在存储和查询性能方面有更多的优化空间。
排序键
Key-Value 数据库的最简单实现具有可以直接访问的键。一个有用的常见功能是以某种方式对键进行排序，以便可以有效地迭代键。此功能的一些常见用例
- 抓取所有以某个字母开头的键
- 抓取某个数字范围内的所有键
- 抓取所有小于或大于某个数字的键
- 如果键是时间戳，则抓取某个时间段内的键
辅助键/索引支持
一些 Key-Value 数据库允许您定义多个不同的键来访问相同的信息。例如，如果您正在存储用户数据，您可能希望能够通过使用姓名、电子邮件地址或电话号码来查找该信息。辅助键支持使所有这些选项成为可能，而不是被迫选择单个键。
复制和分区
许多 Key-Value 数据库都提供对开箱即用的高级扩展功能的支持。复制意味着您可以拥有多个节点，其中包含相同数据的副本。这不仅有助于扩展，还有助于灾难恢复；如果一个节点发生故障，您仍然拥有您的数据。
分区是您的数据如何在节点之间分解。许多数据库提供了一种默认的执行此操作的方法，但也让您可以选择精确定义您希望如何对数据进行分区。一个简单的例子是使用每个键的第一个字母作为分区，这将产生 26 个分区，字母表中每个字母一个分区。
更高级的 Key-Value 数据库将自动支持跨多个数据中心分发您的数据库。这使您的应用程序更可靠，并提高了性能，因为您可以通过使用本地数据中心来响应世界各地用户的查询。
ACID 支持
虽然 NoSQL 数据库可能获得的大部分性能提升是由于放弃了对 ACID（原子性、一致性、隔离性、持久性） 等事物的支持，但许多 Key-Value 数据库可以选择在需要时使用 ACID 事务，但会损失一些性能。仅仅拥有该选项对开发者来说是一个巨大的好处，因为他们可以在需要时使用它，但在不需要它的情况下仍然可以获得出色的性能。
Key-Value 数据库的优势
既然您已经熟悉了 Key-Value 数据库的一些通用功能，那么现在是时候了解它们提供的具体优势以及开发者选择使用它们的原因了。
可扩展性
Key-Value 数据库和 NoSQL 数据库的主要卖点通常是它们与关系数据库相比提供的可扩展性。这些数据库在亚马逊和谷歌等大型科技公司撰写了他们内部构建的数据库以处理扩展问题后开始流行起来。
数据库通常会成为软件的主要瓶颈，许多开发者都感受到了尝试实施复制、分片和用于扩展关系数据库的其他策略的痛苦。能够抽象出这一点并专注于编写驱动业务价值的代码吸引了许多科技公司，这也是 Key-Value 数据库的使用量增长如此之快的原因。
开发者生产力
Key-Value 数据库的第二个好处是开发者生产力。上面已经提到了很大一部分——不必花费那么多时间来扩展数据库，这让开发者可以专注于其他事情。
此外，Key-Value 和 NoSQL 数据库的无模式特性使得在编写代码时更容易迭代。使用关系数据库更改模式需要迁移和潜在的停机时间，而 Key-Value 数据库则不会发生这种情况。
还有“阻抗失配”的概念，它与您的代码中操作数据的方式与数据存储在关系数据库中的方式之间的心智模型有关。尝试将您在代码中使用的对象映射到关系数据库中的一堆不同表在许多情况下感觉不自然。Key-Value 数据库在很大程度上消除了这个问题，并使软件工程师更容易使用他们的数据。
性能
即使忽略 Key-Value 数据库提供的可扩展性功能，对于各种用例，与更通用的关系数据库相比，单节点 Key-Value 数据库在读取和写入数据方面也具有性能优势。
Key-Value 数据库的劣势
当涉及到计算机科学时，没有适用于所有问题的完美解决方案。虽然我们已经介绍了 Key-Value 数据库的一些优势，但总会有权衡。在本节中，您将了解使用 Key-Value 数据库的一些缺点，以及如何根据您的用例确定使用 Key-Value 数据库是否有意义。许多这些缺点只是上述优点的权衡，如果您为工作选择合适的工具，则不会成为问题。
还应该注意的是，许多这些“缺点”都有现代 Key-Value 数据库或构建在 Key-Value 存储之上的多模型数据库提供的解决方案。但无论如何，了解一些潜在的陷阱是有用的。
缺乏 ACID 支持
许多 Key-Value 数据库不提供对 ACID 的支持以提高其可扩展性。在 NoSQL 早期采用时，许多开发者会尝试通过在其应用程序代码中基本上复制事务来弥补这一点，这导致了许多问题。
混乱的模式
虽然无模式可以在短期内提高开发者生产力，但如果工程团队不够自律，如果他们没有做好适当的计划，他们的数据模型可能会变得一团糟。能够动态更改模式可以弥补计划不周，并导致长期问题。在某些方面，被迫使用关系数据库绘制数据模型可以被视为一种好处。
高级查询支持不可用
标准的 Key-Value 数据库实现不提供任何关于实际值包含什么内容的见解——当您使用键抓取值时，您无法保证您得到的是什么。这意味着您将不得不在您的应用程序代码中过滤或处理您不需要的数据。与在数据库中完成大部分工作相比，这通常在性能方面效率较低。
缺少查询语言也意味着通常保留在数据库中的逻辑现在位于您的应用程序代码中，这可能会导致复杂性并使维护代码更加困难。
更新值也可能效率低下，因为即使您只想更新嵌套数据结构中的单个字段，也必须替换整个数据块。
可能效率较低的存储和查询优化
使用定义的模式类型，关系数据库能够在某些情况下通过使用压缩来优化存储，并且还可以优化常见查询，例如获取列值的聚合。
Key-Value 数据库用例
在本节中，您将了解 Key-Value 数据库的一些常见用例。这可能包括用作整个应用程序的主要数据库，或者仅用于应用程序中的一些小众用例。
性能敏感型应用程序
与许多应用程序配合使用的一种常见设计模式是使用像 Redis 这样的 Key-Value 数据库来提高应用程序的读取性能。关系数据库可以充当数据写入的真实来源，然后将数据推送到许多地理分布的 Key-Value 数据库节点。这降低了延迟，因为数据更接近用户，并且还使应用程序更具可扩展性和可靠性。
Key-Value 数据库还可以用于存储对用户体验至关重要的预计算数据。Twitter 提前生成用户的新闻提要并缓存它们，以便用户获得更快的首页加载速度就是一个例子。
更高级别数据库的存储引擎
许多数据库在底层使用 Key-Value 数据库作为存储引擎，因为它们的原始性能以及通过不重新发明轮子来节省开发时间。RocksDB 是 Facebook 创建的开源嵌入式 Key-Value 数据库，已被 MySQL、Cassandra、MariaDB、MongoDB、YugabyteDB 和 InfluxDB 使用或支持。
物联网
许多不同行业的许多企业都在使用传感器和相关技术来收集更多关于运营的数据。它可能与制造和产品开发有关，或者与使用服务模式来检索客户数据有关。公司可能正在收集有关供应商和销售合同以及这些运营如何运作的数据。
相应的优势适用于新的通信模型，如物联网，其中使用更多的设备通过业务网络移动数据。在 IoT 中，数据“始终在传输中”——通过更多的硬件跳跃进行过滤，以及可能由此产生的所有后勤问题。
作为回应，现代工程已经构想出 更接近单个数据点起源的处理方法。专家们经常提倡使用 noSQL 数据库“靠近边缘”进行计算的想法——在存储设备收集信息的环境中的数据库。Key-Value 数据库补充了这种数据操作。由于它们的灵活性，它们允许更好、更有效地处理这种不稳定的活动。
通常，Key-Value 数据库和 Influx 时序模型的使用可以与其他策略合并，以构建业务效率。例如，更好地利用带时间戳的数据可以与提供业务洞察的数据可视化相结合。
使用这些类型的 noSQL 数据库设置实现更多目标的另一种方法是将它们与供应商服务模型中的动态资源联系起来。无服务器功能是这种工作原理的一个主要例子。通过利用 AWS Lambda 或一些 无服务器功能 服务，业务用户可以以不浪费计算能力的方式补充围绕带时间戳数据的强大数据库系统。
Key Value 数据库示例
在本节中，您将了解现实世界中 Key-Value 数据库的一些流行示例，以及导致当前 NoSQL 和 Key-Value 数据库流行的早期数据库。
Berkeley DB
Berkeley DB 是最早的 Key-Value 数据库实现之一。它于 1991 年在加州大学伯克利分校为他们的 BSD 操作系统创建，是 AT&T 为 Unix 编写的专有 DBM 等价物的替代品。Berkeley DB 的独特之处在于它是一个嵌入式 Key-Value 存储，这意味着默认情况下它不提供网络访问，并且旨在嵌入到应用程序中。为了简单性和性能优势而做出的许多架构决策可以被认为是 NoSQL 的先驱。
Berkeley DB 启发了 Facebook 和 Google 创建的类似嵌入式 Key-Value 数据库，称为 RocksDB 和 LevelDB。
Dynamo
Dynamo 是亚马逊发表的一篇非常有影响力的论文，内容关于他们内部的 Key-Value 数据库，该数据库用于扩展他们的亚马逊市场。虽然 Dynamo 使用的许多概念已经存在了几十年，但亚马逊将它们带入了主流，并证明使用 NoSQL 类型数据库具有商业价值。
Redis
Redis 是完全内存中的 Key-Value 数据库。这意味着所有数据都存储在 RAM 而不是磁盘上，这大大提高了读取和写入的性能，因为 RAM 对于顺序数据读取通常快 50 倍，对于随机访问数据快 100,000 倍。缺点是将数据保存在 RAM 中比将数据存储在硬盘驱动器上贵得多。Redis 通常与另一个数据库一起用作缓存来处理读取请求。
InfluxDB 作为 Key-Value 存储
作为一种前沿的时序数据库，InfluxDB 借鉴了 Key-Value 数据库设计的一些思想。早期版本的 InfluxDB 实际上提供了对 RocksDB 作为存储引擎的支持。
InfluxDB 维护着所谓的时序数据库。换句话说，该数据库针对 带时间戳的数据 的使用进行了优化。这在许多方面增强了企业的实力。查询可以揭示关于带时间戳的数据的时间线的信息，并找出更多关于某些内容如何添加到数据库的上下文。时序数据库 在处理时序数据方面提供了许多性能优势，与关系数据库或 Key-Value 数据库相比，因为它们已针对这种类型的工作负载以及从时序数据中获得有价值的见解所需的独特查询进行了优化。
Key-Value 数据库常见问题解答
Key-Value 数据库定义
Key-Value 存储或 Key-Value 数据库是一种将键映射到值的数据库，这些值可以是任何类型的数据。Key-Value 数据库可用于存储不适合标准关系数据库的数据集合。
何时使用 Key-Value 数据库？
Key-Value 数据库可以在许多不同的情况下使用。它们可以用于库存和产品跟踪、客户关系管理等等。开发者可以使用它们来扩展和实施不同类型的分析应用程序。简而言之，Key-Value 存储适用于任何需要灵活数据模型和可扩展存储的情况。
Key Value 数据库和文档数据库之间有什么区别？
文档数据库是另一种 noSQL 设计类型。从技术上讲，文档数据库是 Key-Value 数据库模型的扩展。文档数据库不仅仅是根据映射到值的键来存储数据，而是存储结构化数据。这些文档可以包含多个定义的可以索引的值，以加快查询速度并抓取相关数据。文档数据库可以被视为 Key-Value 数据库和关系数据库之间的一种中间地带，在其中您可以选择在您选择的情况下创建半结构化模式。
公司应如何看待 Key-Value 数据库的实施？
使用 Key-Value 存储和其他 noSQL 方法可以帮助公司将遗留系统迁移到新的系统中，这将更好地满足未来几年业务的需求。遗留系统迁移通常是为了将数据移动到功能更强大、成本更低且更易于维护的云原生系统中。在 Key-Value 数据库的具体案例中，公司可能会将其数据的子集从关系数据库移动到 Key-Value 存储，或者使用像 Redis 这样的 Key-Value 存储作为缓存来直接提供数据，并且仅查询数据库以获取缓存中尚不存在的数据。
公司最初为什么使用关系数据库设计？
关系数据库设计最初是为了解决数据冗余问题而创建的。它是一个以表形式存储数据的系统，其中每个表包含行和列。行表示特定类型信息的记录或实例，列表示属性或字段。
在数据库的早期，云和大数据服务尚未发展起来。早期的数据库相对简单明了，没有考虑到企业今天可以采用的动态使用模式。
Key-Value 数据库 vs 缓存
键值数据库和缓存在使用场景和底层工作原理方面有些相似，在某些方面可以被认为是概念重叠的。根本的区别在于，缓存是为更快地响应数据请求而保留的数据副本，并且不接受对数据的写入或更新。数据库将是永久存储位置和真理来源；缓存将获取该数据，然后将其存储在内存中以更高效地响应请求，但如果底层数据库值发生更改，则需要更新缓存。
大多数键值数据库默认情况下都会有自己的缓存，并且会自动将频繁请求的数据保存在 RAM 中，但额外的缓存层始终也是一个选项。
什么是分布式键值数据库？
分布式键值数据库是一种将数据以键值对形式存储的数据库，数据存储在通过网络相互连接的多个节点上。这些节点不需要位于同一位置，可以分布在不同的地理位置。这使得数据库具有高可用性和可扩展性。
分布式数据库通过客户端应用程序访问。客户端应用程序将命令发送到数据库服务器，然后数据库服务器与网络中的其他节点并行执行命令。对于最终用户而言，分布式数据库被视为一个单一实体，他们不会注意到因冗余而导致的任何性能下降，反而只会看到延迟优势。
