什么是键/值存储数据库？

#1 楼

您是否熟悉键/值对的概念？假设您熟悉Java或C＃，这是作为map / hash / datatable / KeyValuePair语言使用的（最后一个是C＃）

此小节演示了它的工作方式示例图：

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

如果有键（左）和值（右）……请注意，它可以是字符串，整数等。大多数KVP对象都允许您在右侧存储任何对象，因为这只是一个值。

由于您将始终拥有要返回的特定对象的唯一键，因此您只需在数据库中查询该唯一键，然后从具有该对象的任何节点取回结果（这就是为什么它对分布式系统有益的原因，因为还涉及其他方面，例如轮询前n个节点以返回与其他节点返回的值匹配的返回值。）现在，上面的示例非常简单，因此这是一个KVP的更好版本

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

因此，您可以看到，简单的密钥生成就是将用户唯一的数字，下划线和对象放入“用户”。同样，这是一个简单的变体，但是我认为我们开始理解，只要我们可以在左侧定义该部分并对其进行统一格式化，就可以提取该值。

注意，对键值（好的，可能有一些限制，例如纯文本）或value属性（可能有大小限制）没有任何限制，但是到目前为止，我还没有真正复杂的系统。让我们尝试进一步：

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

你明白了……所有这些都将存储在分布式节点上的一个大型“表”中（数学后面的内容），您只需向分布式系统索要名称所需的值。

至少，这是我对所有功能的理解。我可能有一些错误，但这就是基础。


强制性Wikipedia链接http://en.wikipedia.org/wiki/Associative_array

#2 楼

用SQL术语来说，NoSQL数据库是一个包含两列的表：一列是（主键），另一列是值。就是这样，这就是NoSQL的全部魔力。

您使用NoSQL的主要原因之一是：可伸缩性。

如果您的应用程序需要每秒处理数百万个查询，则实现此目标的唯一方法是添加更多服务器。使用NoSQL非常便宜且容易。相比之下，扩展传统的SQL数据库要复杂得多。

只有最大的网站才能真正利用NoSQL的全部潜能，例如Facebook，拥有数千台运行Cassandra的服务器。

我强烈建议阅读此博客文章，比较SQL，NoSQL和ORM：

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

#3 楼

我假设您对NoSQL运动和非关系数据库模型有基本的了解。

键值存储是非关系数据库模型之一，例如图形，面向文档的数据库模型。


键值存储和NoSQL运动
/>
通常，SQL设法处理
特殊结构化的数据，并根据
问题部门的需要允许高度动态的查询。

尽管在这个特定的领域中还没有真正的SQL竞争者，但是日常Web应用程序中的用例却不同。您
不会在大型表上找到充满外部和内部联接，并集和复杂计算的查询的高度动态范围
。通常，您会
找到一种非常面向对象的思维方式。特别是采用MVC之类的模式时，通常不对数据库中的数据进行建模，而是对逻辑完整性进行建模，这也有助于人们
能够应付理解。
庞大的软件基础结构。将这些
面向对象模型放入关系
数据库中所做的工作是大量的
规范化，这导致了复杂的表层次结构和完全
反对
面向对象编程背后的主要思想。遵守SQL标准的服务器
也必须实现
的大部分代码，而这些代码对简单数据没有用。
这样存储只会膨胀
内存占用空间，安全风险
，从而导致性能下降。

SQL允许对复杂的
数据集进行任意动态查询的事实被
仅使用SQL数据库用于
持久化而变得无用。存储面向对象的数据
，这基本上是大多数
这些天的应用程序。

这就是键值存储的作用。 Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship。
数据本身通常是某种编程语言的
原语
（字符串，整数，数组）或被
编组的
对象。 />编程语言绑定到
键值存储。这取代了
对固定数据模型的需求，并使
对正确格式化的
数据的要求变得不太严格。

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval。 “简单”商店的最大区别是您可以（或不能）
认证或访问其他商店的方式（如果可能）。尽管在存储和检索
数据方面的速度优势可能是在普通SQL数据库上考虑使用
的原因，但使用
key-时出现的另一个
大优势是-值存储区是，与您的编程语言中的嵌入式SQL字符串相比，生成的
代码趋向于简洁明了
。这是人们倾向于使用对象关系映射框架（例如Hibernate或Active
记录）进行的斗争
。拥有对象关系
映射器似乎基本上是通过在SQL
数据库和面向对象的
之间添加很多非常复杂的代码来模拟
键值存储。编程语言。

整个社区成员聚集在一起，在“ NoSQL”标签下讨论
这些优点以及
使用替代方法的缺点
/>关系数据库管理系统。阅读更多
这是一篇比较老的文章，但是我发现它很有用。


您必须考虑很多因素，例如可伸缩性，性能等...

查看下面的幻灯片/文章，您将了解何时，为什么以及为什么不使用键值存储：)




非关系数据库和键/值存储

键值存储-扩展的关键？

http://highscalability.com/blog/category/key-value-store [必须阅读]
http://ayende.com/Blog/archive/2010/03/29 /that-no-sql-thing-keyvalue-stores.aspx

#4 楼

其他人已经解释了这一点，但是无论如何我还是会尝试。

键/值数据库通过主键存储数据。这使我们可以唯一地标识存储桶中的记录。由于所有值都是唯一的，因此查找非常快：它始终是简单的磁盘查找。

该值只是任何一种值。数据的存储方式对数据库本身是不透明的。当您将数据存储在键/值存储中时，数据库不知道或不在乎它是XML，JSON，文本还是图像。实际上，我们在键/值存储中所做的工作是将了解数据如何从数据库中存储出来的责任转移到检索数据的应用程序中。由于每个存储桶只需要担心一个密钥范围，因此很容易将密钥分布到许多服务器上，并使用分布式编程技术可以快速访问此数据（每个服务器都存储一定范围的数据） 。

这种数据处理方法的缺点是搜索是一项非常困难的任务。您需要读取存储桶中数据的每条记录，否则需要自己构建二级索引。

您可能要使用键/值数据库有以下几个原因：


将写性能放在首位。 Mozilla Test Pilot使用键/值数据库来快速记录数据。
保证只有PK才能进行读取。
使用平面数据模型时。
当您使用无法在RDBMS中进行建模的丰富，复杂的数据模型时。

使用键/值数据库的原因有很多，使用RDBMS，并且有很多论据可以证明一个论据的合理性。重要的是要查看您如何查询数据，并了解该数据访问模式如何指导您如何插入和存储数据。

请记住，键/值数据库只是NoSQL数据库的一种。

#5 楼

如果您有关系数据库，则可以轻松地进行以下实验：

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

这是以前所有数据库的样子，伯克利DBM是一个很好的例子，从1979年。从那时起，事情发展了（在任何RDBMS中每个键都可以有很多值）。对于许多应用程序而言，键值存储就足够了（例如，这就是sendmail存储其别名的方式）。但是，如果您发现自己在自己的代码中预处理了该值（或连接字符串以创建“键”），也许在使用它之前将其分割为定界符或对其进行了解析，则可能会更好一个RDBMS并实际上以这种方式存储它。