blocks|key|3252358|text|在过去的一个月左右，我一直在调查NoSQL。我认为通常可以这样说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3252359|3252360|KV商店不知道为关键|unordered-list-item|3252361|文档实际存储的值内容，这允许您在值内容中定义二级索引，因为数据库知道文档结构(例如博客文章的标签)。|3252362|NoSQL解决方案每个解决方案都有应该考虑的特定功能，例如KV商店中的|3252363|特殊数据类型(例如，在redis中具有左/右弹出/推送的集合)|3252364|+riak所说的简单的扩展/缩小群集(我还没有尝试过...Voldemort|3252365|build-in+web配置中的yet)|3252366|pluggable数据存储和CouchDB+/+couchapp|3252367|3252368|中的web应用程序支持|3252369|​|3252370|entityMap^0|0|0|0|0|1|1|1|1|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|15|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|16|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|18|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

Well, I've been investigating NoSQL myself the past month or so. I think it generally could be stated something like

<ul>
<li>KV stores doesnt know of the value
content actually stored for a key</li>
<li>Document based lets you define secondary
indexes within the value content, as
the db knows the document structure
(e.g. tags of a blog post).</li>
<li>NoSQL solutions each have specific features which should be taken into consideration, such as

<ul>
<li>Special datatypes in a KV store (e.g. sets with left/right pop/push like in redis)</li>
<li>easy scale up/down cluster as riak says it has (I havent tried it ... yet)</li>
<li>pluggable data store as in Voldemort</li>
<li>build-in web configuration and web app support like in CouchDB / couchapp</li>
</ul></li>
</ul>

blocks|key|304866|text|键值存储提供了最简单的数据模型，顾名思义:它是一个存储由键索引的值的存储系统。您只能通过键进行查询，并且值是不透明的，存储对它们一无所知。这允许非常快的读写操作(一个简单的磁盘访问)，我认为这个模型是一种非易失性缓存(即，如果您需要通过键快速访问长期数据，则非常适合)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|304867|面向文档的数据库扩展了以前的模型，并以数据库可以理解的结构化格式(文档，因此得名)存储值。例如，一个文档可以是一篇博客文章，并以一种非规范化的方式存储和，以及标签。因为数据是透明的，所以存储可以做更多的工作(比如对文档的字段进行索引)，并且您不限于通过键进行查询。正如我所暗示的，这样的数据库允许通过一次查询获取整个页面的数据，并且非常适合面向内容的应用程序(这就是为什么像Facebook或Amazon这样的大网站喜欢它们)。|304868|其他类型的NoSQL数据库包括面向列的存储、图形数据库甚至对象数据库。但这超出了问题的范围。|304869|另请参阅|304870|304871|Comparing+Document+Databases+to+Key-Value+Stores|unordered-list-item|304872|Analysis+of+the+NoSQL+Landscape|304873|304874|entityMap|0|LINK|mutability|MUTABLE|url|http://nosql.mypopescu.com/post/659390374/comparing-document-databases-to-key-value-stores|1|http://blog.knuthaugen.no/2010/03/the-nosql-landscape.html^0|1I|4|0|23|4|2F|3|0|0|0|0|0|1C|0|0|0|V|1|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1B|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|1D|8|@]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|P|3|Q|5|O|7|1H|8|@]|D|@$9|1I|A|1J|1|1K]]|E|$]]|$1|R|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z]]|10|$5|V|W|X|E|$Y|11]]]]

A key-value store provides the simplest possible data model and is exactly what the name suggests: it's a storage system that stores values indexed by a key. You're limited to query by key and the values are opaque, the store doesn't know anything about them. This allows very fast read and write operations (a simple disk access) and I see this model as a kind of non volatile cache (i.e. well suited if you need fast accesses by key to long-lived data).
A document-oriented database extends the previous model and values are stored in a structured format (a document, hence the name) that the database can understand. For example, a document could be a blog post and the comments and the tags stored in a denormalized way. Since the data are transparent, the store can do more work (like indexing fields of the document) and you're not limited to query by key. As I hinted, such databases allows to fetch an entire page's data with a single query and are well suited for content oriented applications (which is why big sites like Facebook or Amazon like them).
Other kinds of NoSQL databases include column-oriented stores, graph databases and even object databases. But this goes beyond the question.
<h3>See also</h3>
<ul>
<li><a href="http://nosql.mypopescu.com/post/659390374/comparing-document-databases-to-key-value-stores" rel="noreferrer">Comparing Document Databases to Key-Value Stores</a></li>
<li><a href="http://blog.knuthaugen.no/2010/03/the-nosql-landscape.html" rel="noreferrer">Analysis of the NoSQL Landscape</a></li>
</ul>

blocks|key|307712|text|在键值数据库模型中，用户可以选择键是什么，而文档模型中的文档标识符通常是system-generated.+|type|unstyled|depth|inlineStyleRanges|entityRanges|data|307713|ordered-list-item|307714|307715|307716|键值数据库模型中的键值对不能分组，而在文档数据库中，我们可以将键值对分组到单独的文档中；而且，某些形式的文档数据库甚至允许我们进一步分组这些文档，即所谓的“集合”或“域”。|307717|307718|尽管文档数据库中的文档具有明确定义的内部结构(因此，DBMS可以对其进行操作；例如，创建索引)，但对于键值数据库中的值，情况并非如此，在这种数据库中，这些值的任何可能的内部结构对于DBMS+perspective.是不透明的(|307719|307720|307721|307722|在键值模型中，访问多个数据库条目(在本例中是键值对)需要单独的请求。另一方面，在文档模型中，可以在单个请求中检索多个数据库条目(在本例中为文档)。|307723|307724|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|C|7|T|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|C|7|W|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Y|8|@]|9|@]|A|$]]|$1|K|3|-4|5|C|7|Z|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|C|7|12|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|R|$]]

<ol>
<li>In the key-value database model, users can choose what the keys are, whereas the document
identifiers in the document model are typically system-generated.
</li>
<li>The key-value pairs in the key-value database model cannot be grouped whereas, in a
document database, we can group key-value pairs into separate documents; moreover, some
forms of document databases allow us to even group these documents further, namely into
so, called &quot;collections&quot; or &quot;domains&quot;.
</li>
<li>While the documents in a document database have an internal structure that is clearly
defined (and, thus, can be operated on by the DBMS; for instance, to create indexes), the
same is not the case for the values in a key-value database where any possible internal
structure of such values is opaque from a DBMS perspective.
</li>
<li>In the key-value model, access to multiple database entries (key-value pairs, in this case)
requires separate requests. In the document model, on the other hand, multiple database
entries (documents, in this case) may be retrieved in a single request.
</li>
</ol>

What does going with a document based NoSQL option buy you over a KV store, and vice-versa?

What does "Document-oriented" vs. Key-Value mean when talking about MongoDB vs Cassandra?

数据存储

SQL数据库

数据库

NoSQL

与KV商店相比，基于文档的NoSQL选项能为您带来什么，反之亦然？

问在讨论MongoDB和Cassandra时，“面向文档的”和“键值”是什么意思？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在讨论MongoDB和Cassandra时，“面向文档的”和“键值”是什么意思？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在讨论MongoDB和Cassandra时，“面向文档的”和“键值”是什么意思？
EN