NoSQL数据库的开销和(in)效率？

Question

我有一个关于NoSQL类型数据库的问题,特别是MongoDB,但它通常适用于大多数基于键值或基于文档的存储.NoSQL的一些卖点是速度和可伸缩性,但在我看来,与关系数据库相比,存在显着的开销.

1. 你有很多重复,因为(几乎)一切都是非标准化的.你无法做很多事情,因为这是这类数据库的重点.我更关心下一个:

2. 有很多开销,因为如果你有一个JSON文档,你必须保存每个文档的所有键(和所有结构信息).因此,对于10000行,您必须保存字符串'age','name',... 10000次.

3. 数据库不能做很多聪明的事情,比如创建索引或二叉树(以节省时间)或以紧凑的方式存储整数(因为其中一个自由格式的文档可能有一个字符串,其他所有的都有一个int,等等.)

我知道你可以编写你自己的视图或map/reduce算法来获得类似索引的东西,但乍一看似乎对于一般情况来说NoSQL必须是非常低效的空间和CPU.

真的那么糟糕吗？NoSQL数据库中有哪些优化(比如MongoDB)？与使用关系数据库相比,存储大量相同的复杂JSON文档的开销是多少？

Answer 1

首先，任何开销或低效率通常都只是代表优先级的选择；某处的开销会给你在其他地方带来优势。

至于你的具体要点，我认为答案在很大程度上取决于确切的 NoSQL 产品，甚至在键值或基于文档的子组中，但这里有一些想法：

1-你有很多重复，因为（几乎）一切都是非标准化的。您对此无能为力，因为这是此类数据库的重点。

实际上，大多数（如果不是全部）键值数据库可以与您想要的任何模式一起使用。因此，您可以在键值存储上建立“规范化模式”，从而避免重复。不要忘记，有些（或大多数？）键值数据库有可用的 SQL 解决方案。

2- 开销很大，因为如果您有一个 JSON 文档，则必须在每个文档中保存所有键（以及所有结构信息）。因此，对于 10000 行，您必须保存字符串“age”、“name”... 10000 次。

我想这取决于数据库引擎的实现方式，但是可以使用压缩（无论是复杂的还是简单的“标记化”）并且不会产生显着的开销。

3-数据库不能做很多聪明的事情，比如创建索引或二叉树（以节省时间）或以紧凑的方式存储整数（因为自由格式文档之一可能有一个字符串，而所有其他文档都有一个字符串）整数等）

同样，没有什么可以阻止键值或基于文档的数据库在后台使用任何类型的树或以紧凑的方式存储整数（例如，它可以有一个简单的二进制标志来指示数据是否存储为字符串或“紧凑整数”）。至于创建索引，这也是可能的（出于与 1 中所述相同的原因，或由应用程序手动完成）。