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

时间:2012-08-30 12:07:05

标签: performance nosql overhead

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

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

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

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

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

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

1 个答案:

答案 0 :(得分:1)

首先,任何开销或低效率往往只是代表优先选择;某处的开销可以让你在其他地方获得优势。

至于你的具体要点,我认为答案将取决于确切的NoSQL产品,甚至在键值或基于文档的子组中,但这里有一些想法:

  

1-你有很多重复,因为(几乎)一切都是非标准化的。你无能为力,因为这是这类数据库的重点。

实际上,大多数(如果不是全部)键值数据库都可以与您想要的任何架构一起使用。因此,您可以在键值存储上放置“规范化模式”,从而不会出现重复。不要忘记某些(或大多数?)键值数据库可以使用SQL解决方案。

  

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

我想这取决于数据库引擎的实现方式,但压缩 - 复杂或简单的“标记化” - 都可以使用,并且不会产生明显的开销。

  

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

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