基于文档的数据库和基于键/值的数据库之间的区别?

发布于 2024-09-15 13:36:36 字数 267 浏览 8 评论 0原文

我知道存在三种不同的、流行的非 SQL 数据库类型。

  • 键/值:Redis、Tokyo Cabinet、Memcached
  • ColumnFamily:Cassandra、HBase
  • 文档:MongoDB、CouchDB

我读过很多关于它的博客,但了解不多。

我了解关系数据库并熟悉基于文档的数据库,例如 MongoDB/CouchDB。

有人能告诉我这些和列表中的前两个之间的主要区别是什么吗?

I know there are three different, popular types of non-sql databases.

  • Key/Value: Redis, Tokyo Cabinet, Memcached
  • ColumnFamily: Cassandra, HBase
  • Document: MongoDB, CouchDB

I have read long blogs about it without understanding so much.

I know relational databases and get the hang around document-based databases like MongoDB/CouchDB.

Could someone tell me what the major differences are between these and the 2 former on the list?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

雨的味道风的声音 2024-09-22 13:36:36

主要区别在于数据模型和查询功能。

键值存储

第一种类型非常简单,可能不需要任何进一步的解释。

数据模型:不仅仅是键值存储

虽然有一些关于 Cassandra 等数据库的正确名称的争论,我想将它们称为列族存储。尽管键值对是 Cassandra 的重要组成部分,但它不仅限于此。它允许您嵌套键值对,因此一个键可以引用多个子键值对。

但您不能无限期地嵌套键值对。您仅限于三层(列族)或四层嵌套(超级列族)。如果术语“列族”没有引起您的注意,请参阅 WTF 是一篇 SuperColumn 文章,很好地解释了 Cassandra 的数据模型。

文档数据库,例如 CouchDB 和 MongoDB,以 JSON 对象的形式存储整个文档< /a>.您可以将这些对象视为嵌套的键值对。与 Cassandra 不同,您可以根据需要嵌套键值对。 JSON 还支持数组并理解不同的数据类型,例如字符串、数字和布尔值。

查询

我相信列族存储只能通过键或通过编写映射缩减函数来查询。您无法像在 SQL 数据库中那样查询值。如果您的应用程序需要更复杂的查询,您的应用程序将必须创建和维护索引才能访问所需的数据。

文档数据库还支持按键查询和映射缩减功能,但也允许您按值进行基本查询,例如“给我所有拥有超过 10 个帖子的用户”。文档数据库通过这种方式更加灵活。

The main differences are the data model and the querying capabilities.

Key-value stores

The first type is very simple and probably doesn't need any further explanation.

Data model: more than key-value stores

Although there is some debate on the correct name for databases such as Cassandra, I'd like to call them column-family stores. Although key-value pairs are an essential part of Cassandra, it's not limited to just that. It allows you to nest key-value pairs, so a key could refer to multiple sub-key-value pairs.

You cannot nest key-value pairs indefinitely though. You are limited to three levels (column families) or four levels of nesting (super-column families). In case the term column family doesn't ring a bell, see the WTF is a SuperColumn article, it's a good explanation of Cassandra's data model.

Document databases, such as CouchDB and MongoDB store entire documents in the form of JSON objects. You can think of these objects as nested key-value pairs. Unlike Cassandra, you can nest key-value pairs as much as you want. JSON also supports arrays and understands different data types, such as strings, numbers and boolean values.

Querying

I believe column-family stores can only be queried by key, or by writing map-reduce functions. You cannot query the values like you would in an SQL database. If your application needs more complex queries, your application will have to create and maintain indexes in order to access the desired data.

Document databases support queries by key and map-reduce functions as well, but also allow you to do basic queries by value, such as "Give me all users with more than 10 posts". Document databases are more flexible in this way.

韵柒 2024-09-22 13:36:36

Ayende 对于 Key 之间的区别给出了很好的解释-值和文档数据库:

文档数据库的核心是具有一个主要内容的键/值存储
例外。 文档数据库不只是在其中存储任何 blob
要求数据将以数据库可以支持的格式存储
理解(即 JSON、XML 等)。在大多数文档数据库中,这意味着我们
现在可以允许查询文档数据。


Ayende has given a nice explanation regarding the difference between Key-Value and Document database:

A document database is, at its core, a key/value store with one major
exception. Instead of just storing any blob in it, a document db
requires that the data will be store in a format
that the database can
understand (i.e. JSON, XML etc). In most doc dbs, that means that we
can now allow queries on the document data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文