我一直在看NoSQL的维基百科页面,它列出了键/值存储数据库的几种变体,但是在这种情况下,我找不到关于键/值存储的含义的任何详细信息。有人可以向我解释或链接解释吗?另外,什么时候可以使用这样的数据库?
我一直在看NoSQL的维基百科页面,它列出了键/值存储数据库的几种变体,但是在这种情况下,我找不到关于键/值存储的含义的任何详细信息。有人可以向我解释或链接解释吗?另外,什么时候可以使用这样的数据库?
Answers:
您是否熟悉键/值对的概念?假设您对Java或C#熟悉,使用的语言是map / hash / datatable / KeyValuePair(最后一个是C#)
此小样本图表演示了它的工作方式:
Color Red
Age 18
Size Large
Name Smith
Title The Brown Dog
在有键(左)和值(右)的地方……请注意,它可以是字符串,int或类似内容。大多数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
user1923_color: red, user1923_age: 18, ...
反对user1923: {color: red, age: 18, ...}
。
用SQL术语来说,NoSQL数据库是一个包含两列的表:一列是(主键),另一列是值。就是这样,这就是NoSQL的全部魔力。
使用NoSQL的主要原因之一是:可伸缩性。
如果您的应用程序需要每秒处理数百万个查询,那么唯一的方法就是添加更多服务器。使用NoSQL非常便宜且容易。相反,扩展传统的SQL数据库要复杂得多。
实际上,只有最大的网站才能真正利用NoSQL的全部潜力,例如Facebook,拥有数千台运行Cassandra的服务器。
我强烈建议阅读此博客文章,比较SQL,NoSQL和ORM:
我假设您对NoSQL运动和非关系数据库模型有基本的了解。
键值存储是非关系数据库模型之一,例如图形,面向文档的数据库模型。
键值存储和NoSQL运动
通常,SQL设法处理特殊结构的数据,并根据相关部门的需求允许进行高度动态的查询。
尽管在此特定领域,SQL尚无真正的竞争对手,但日常Web应用程序中的用例却不同。您将不会发现在大型表上充满外部和内部联接,联合和复杂计算的高度动态查询范围。通常,您会发现一种非常面向对象的思维方式。尤其是采用MVC这样的模式时,后端的数据通常不是为数据库建模的,而是为逻辑完整性建模的,这也有助于人们应对巨大的软件基础结构。将这些面向对象的模型放到关系数据库中所做的工作是进行大量的规范化,这导致了表的复杂层次结构,并且完全违背了面向对象编程背后的主要思想。
通过仅将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数据库上考虑使用数据的原因,但是使用键值存储时出现的另一个重大优势是,与嵌入式SQL字符串相比,生成的代码看起来更简洁明了。您的编程语言。人们倾向于使用对象关系映射框架(例如Hibernate或Active Record)来解决这一问题。拥有对象关系映射器似乎基本上是通过在SQL数据库和面向对象的编程语言之间添加许多非常复杂的代码来模拟键值存储。整个社区都聚集在“ NoSQL ”标签下,讨论了使用替代方法建立关系数据库管理系统的这些优点和缺点。阅读更多
这是一篇有点老的文章,但是我发现非常有用。
when would I use such a database?
Could someone explain or link an explanation to me?
它更多的是架构决定,还有一个值得商...的决定...您必须考虑很多因素,例如可伸缩性,性能等。
查看下面的幻灯片/文章,您将了解何时,为何以及为何不使用键值存储的想法:)
其他人已经解释了这一点,但是我还是要坚持一下。
键/值数据库通过主键存储数据。这使我们可以唯一地标识存储桶中的记录。由于所有值都是唯一的,因此查找非常快:它始终是简单的磁盘查找。
价值就是任何一种价值。数据的存储方式对数据库本身是不透明的。当您将数据存储在键/值存储中时,数据库并不知道或不在乎它是XML,JSON,文本还是图像。实际上,我们在键/值存储区中所做的工作是将了解数据如何从数据库中存储出来的责任转移到检索数据的应用程序中。由于每个存储桶只需要担心一个密钥范围,因此很容易将密钥分布在许多服务器上,并使用分布式编程技术可以快速访问此数据(每个服务器都存储一定范围的数据) 。
这种数据处理方法的缺点是搜索是非常困难的任务。您需要读取存储桶数据中的每条记录,否则您需要自己构建二级索引。
您可能要使用键/值数据库有几个原因:
使用键/值数据库的原因与使用RDBMS的原因一样多,并且有许多参数可以证明一个相对于另一个。重要的是要查看您如何查询数据,并了解该数据访问模式如何指导您如何插入和存储数据。
请记住,键/值数据库只是NoSQL数据库的一种。
如果您有关系数据库,则可以轻松地进行以下试验:
create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);
从1979年开始,这就是所有数据库的用法,其中以Berkeley DBM为例就是一个很好的例子。从那时起,事情发展了(在任何RDBMS中每个键可以有很多值)。对于许多应用程序而言,键值存储就足够了(例如,这就是sendmail存储其别名的方式)。但是,如果您发现自己在自己的代码中预处理了该值(或连接字符串以创建“键”),或者在使用它之前将其拆分为一个定界符或对其进行了解析,则可能会更好一个RDBMS并实际上以这种方式存储它。