nosql - 面向键值的数据库 vs 面向文档的数据库

要开始，最好指出错误最少的词汇。过去被称为 nosql 的范围太广，并且通常在两个被称为 nosql 的数据库之间没有特征方面的交集，除了它们以某种方式处理“数据”这一事实。什么程序不处理数据？！本着同样的精神，我避免使用关系数据库管理系统 (RDBMS) 一词。大多数演讲者和听众都清楚，RDBMS 是 SQL Server、某种 Oracle 数据库、MySQL、PostgreSQL 之间的某种东西。它是否包括 SQLite，这已经是一个指标，“关系数据库”不是描述其背后概念的完美词，这是模糊的。更重要的是，人们通常所说的nosql 从不禁止关系。即使在“键值”存储之上，也可以建立关系。在资源描述框架数据库中，SQL 行的等价物被称为元组、三元组、四元组，更普遍且更简单的是：关系。关系数据库的另一个例子是由 datalog 提供支持的数据库。因此，RDBMS 和关系数据库不是描述预期概念的好词，当有人使用时，只能谈论他们对数据（基础）世界中存在的各种范式的狭隘看法。

在我看来，最好使用“SQL 数据库”来描述支持 ISO 标准定义的 SQL 编程语言的子集或超集的数据库。

那么，NoSQL 的措辞是有道理的：不提供对 SQL 编程语言支持的数据库。特别是，不包括 Cassandra 和 Neo4J，它们可以用一种语言（分别是 CQL 和 Cypher / GQL）进行编程，其表面语法看起来像 SQL，但没有 SQL 的语义（既不是超集，也不是 SQL 的子集） .仍然是 Google BigQuery，感觉很像 SQL，但我对它不够熟悉，无法划清界限。

键值存储也是模糊的。 memcached、REDIS、foundationdb、wiredtiger、dbm、东京机柜等。 al 彼此非常不同，并且用于 verrrrrrrrrrry 不同的用例。

抱歉，面向文档的数据库不够精确。从历史上看，它们是两个主要的数据库，即所谓的文档数据库：ElasticSearch 和 MongoDB。而那些又一次，是非常不同的软件，如果使用得当，并不能解决同样的问题。

您可能已经猜到了，您的问题表明缺乏工作，并且措辞，即使我不想剃掉与数据库相关的词汇量，也太宽泛了。

<块引用>

由于它们具有相似的结构，

没有

<块引用>

它们的保存和检索方式不是完全相同吗？

没有

<块引用>

如果是这样，为什么我们将它们定义为单独的类型？

它们的编程接口、部署策略和内部结构以及预期用例大不相同。

<块引用>

否则，它们如何保存在文件系统中？

这个问题本身就太宽泛了，你需要问一个具体的问题，至少解释你对一个或多个数据库如何工作的理解，并问一个关于你想去哪里/你想了解什么的问题。 “如何从 A 点理解（给出），到 B 点理解（问题）”。在你的问题中没有A点，B点模糊或过于宽泛。

摩尔：

首先，确保您对 SQL 数据库有扎实的了解，至少对 SQL 语言有深入的了解（然后深入研究索引，最后进行微调）。没有 SQL 知识，你在就业市场上一文不值。如果您已经很好地掌握了 SQL，我的建议是放弃除 FoundationDB 之外的所有其他内容。
如果你仍然想要“基准”数据库，首先设置一个情况（真实的或想象的）即。一个你很熟悉的项目，它需要一个数据库。尝试适应几个数据库来解决那个项目的问题。

最后，如果您心中有一个精确的项目，请尝试回答以下问题，然后再在 database-design 上提出另一个问题：

你需要什么保证。质疑 ACID 的所有属性：原子性、一致性、隔离性、持久性。查看BASE。您不一定需要 ACID 或 BASE，但它是一个很好的基础，有据可查，可以了解您想要/需要去哪里。
数据的大小是多少？
数据的形状是什么？它们是定义明确的类型吗？它们是多态类型（异质形状）吗？
工作负载：一次写入然后只读，主要是读取，主要是写入，两者的混合。还要回答写入或读取的速度有多快或多慢的问题。
查询：查询的样子：递归/深度、列或行，或邻居查询（如 graphql 和没有递归查询的 SQL）。同样，预计响应时间是多少。

在提交特定解决方案之前，至少不要放弃审查部署和扩展策略。

就我而言，我选择了foundationdb，因为它在这些方面是最通用的，即使目前它需要一些代码来替代所有 postgresql 功能。< /p>

面向键值的数据库 vs 面向文档的数据库

1 个答案: