NoSQL数据库的5个陷阱

我录制了一段视频，在视频中我谈到了NoSQL数据库的优势。回答很有趣，但我的印象是，并不是每个人都看到了硬币的两面。事实是他们会给我们带来很多问题😉。

每个NoSQL数据库都以自己的方式接近模式。有些没有模式(MongoDB)，有些是动态的(Elasticsearch)，有些类似于关系数据库中的模式(Cassandra)。在概念模型中，数据总是有一个模式。实体、字段、名称、类型、关系。无论基础的类型如何，物理模型都是概念模型的表示形式。

NoSQL数据库在模式方面给了我们更大的自由度。在MongoDB中，我们可以添加两个字段名称相同但类型不同的不同文档。这有道理吗？还是不要了。这会发生吗？当然可以。一个简单的人为错误就可能破坏我们的应用程序。

另一个问题与实体之间的关系有关。即使我们的数据库中没有关系，我们也必须记录数据之间的关系。从关系数据库中，我们可以生成ERD图。对于NoSQL数据库，这可能不起作用。

在使用NoSQL数据库时，我们必须记住模式管理和数据验证问题。如果没有它，数据可能会“爆炸”。有趣的事实：一些公司用PostgreSQL取代了MongoDB。

NoSQL数据库的性能是正确的数据建模、索引和分区的结果。在关系数据库中，我们可以添加列、转换表、将数据从一个表翻转到另一个表，如果我们以前忘记了，还可以添加索引。对于NoSQL数据库，这并不是在所有情况下都是可能的。我们可能需要使用一些外部工具，如Apache Spark，甚至删除并重新创建我们的数据模型。

在Elasticsearch中，如果我们没有得到索引的模式/映射，我们必须使用例如reindex API，这意味着我们必须将数据重新索引到另一个索引。

在Cassandra中，我们只能按分区和聚集键进行过滤。如果我们忘记将其中一列添加到键中，则有可能添加索引，但是如果集合的基数很大，这可能会降低性能。

ACID属性简化了代码编写。我们不需要处理与以下事实相关的错误：X表中的数据已经存在，而Y表中的数据还没有(如果有的话)。根据CAP定理，我们知道存在一致和最终一致的数据库。这种类型的最流行的数据库是Apache Cassandra。最终的一致性需要不同的数据建模和应用程序逻辑方法。代码应该以更具防御性的方式编写，因为不能确定您刚刚更改的记录是否已经从应用程序的另一部分可用。HBase是一致数据库的一个例子，但即使是Cloudera也认为它不会取代关系数据库。一些数据库宣称自己是一致的，并且只在一定程度上保证了一致性。例如，MongoDB提供事务，但多文档事务仅在4.0版之后才可用。

Nosql的缺点是缺少…。Sql😁。不管我们喜欢与否，SQL是数据的基础。许多分析师每天都在使用SQL，学习另一种语言可能会阻碍他们使用数据库。创建Spark SQL或Beam SQL是有原因的。

这是对OLTP和OLAP系统之间的区别的一点讨论。我们习惯于使用GROUP BY和JOIN子句，但并不是每个数据库都会提供这样的功能。由于数据库的性质，聚合和合并可能非常有限(如果可能)。对于Apache Cassandra，分析功能通常是通过组合Apache Spark集群来实现的。你将从我的这个故事中学习如何将两者联系起来。

那么是否值得使用NoSQL呢？当然，是这样的。我们必须记住，创建每个数据库都是为了解决一类问题。改变“命运”是可能的，但这是有后果的。用螺丝刀拧螺丝，用锤子钉钉子，用滚子钉墙更容易。

另一个有趣的选择是NewSQL数据库。这种底座的一个例子是蟑螂Db和扳手。它们在保持ACID属性的同时解决了传统关系数据库的问题(主要是伸缩性问题)。