我有一个关于 NoSQL 类型数据库的问题，特别是 MongoDB，但它通常适用于大多数基于键值或文档的存储。NoSQL 的一些卖点是速度和可扩展性，但在我看来，与关系数据库相比，开销很大。
你有很多重复，因为（几乎）一切都是非规范化的。您对此无能为力，因为这是此类数据库的重点。我更关心下一个：
有很多开销，因为如果你有一个 JSON 文档，你必须保存每个文档的所有键（和所有结构信息）。因此，对于 10000 行，您必须保存字符串 'age'、'name'、... 10000 次。
数据库不能做很多聪明的事情，比如创建索引或二叉树（以节省时间）或以紧凑的方式存储整数（因为一个自由格式的文档可能有一个字符串，而所有其他文档都有一个 int， ETC。）
我知道您可以编写自己的视图或 map/reduce 算法来获得类似索引的东西，但乍一看，对于一般情况，NoSQL 必须非常低效地占用空间和 CPU。
真的有那么糟糕吗？NoSQL 数据库（比如 MongoDB）中进行了哪些优化？与使用关系数据库相比，存储大量相同的复杂 JSON 文档的开销是多少？
首先，任何开销或效率低下往往不仅仅是代表优先级的选择；某处的开销会给您在其他地方的优势。
至于您的具体点，我认为答案在很大程度上取决于确切的 NoSQL 产品，即使在键值或基于文档的子组中也是如此，但这里有一些想法：
1-您有很多重复，因为（几乎）所有内容都未标准化。您对此无能为力，因为这是此类数据库的重点。
实际上，大多数（如果不是全部）键值数据库可以与您想要的任何模式一起使用。因此，您可以在键值存储上放置一个“规范化模式”，从而避免重复。不要忘记某些（或大多数？）键值数据库有可用的 SQL 解决方案。
2- 有很多开销，因为如果你有一个 JSON 文档，你必须保存每个文档的所有键（和所有结构信息）。因此，对于 10000 行，您必须保存字符串 'age'、'name'、... 10000 次。
我想这取决于数据库引擎的实现方式，但是可以使用压缩——无论是复杂的还是简单的“标记化”——并且不会导致显着的开销。
3- 数据库不能做很多聪明的事情，比如创建索引或二叉树（以节省时间）或以紧凑的方式存储整数（因为一个自由格式的文档可能有一个字符串，而所有其他文档都有一个整数等）
同样，没有什么可以阻止键值或基于文档的数据库在后台使用任何类型的树或以紧凑的方式存储整数（例如，它可以有一个简单的二进制标志来指示数据是否存储为字符串或“紧凑整数”）。至于创建索引，这也是可能的（出于 1 中所述的相同原因，或由应用程序手动完成）。