我录制了一段视频，讲述了NoSQL数据库的优势。 回应很有趣，但是我给人的印象是，并不是每个人都看到硬币的两面。 事实是它们会给我们带来很多问题。
Schema管理
每个NoSQL数据库都以其自己的方式处理该模式。 在某些情况下没有Schema(MongoDB)，在某些情况下它是动态的(Elasticsearch)，在某些情况下它类似于关系数据库中的Schema(Cassandra)。 在概念模型中，数据始终具有Schema。 实体，字段，名称，类型，关系。 不管基础类型如何，物理模型都是概念模型的表示。
NoSQL数据库在架构方面为我们提供了更多自由。 在MongoDB中，我们可以添加两个具有相同字段名称但类型不同的不同文档。 这有意义吗? 而不是。 这会发生吗? 当然可以。 一个简单的人为错误可能会破坏我们的应用程序。
另一个问题与实体之间的关系有关。 即使数据库中没有关系，我们也必须记录数据之间的关系。 从关系数据库中，我们可以生成ERD图。 如果是NoSQL数据库，则可能无法使用。
使用NoSQL数据库时，我们必须记住有关模式管理和数据验证的问题。 没有它，数据可能会"爆炸"。 有趣的事实：一些公司用PostgreSQL替换了MongoDB。
较低的误差范围
NoSQL数据库的性能是适当的数据建模，索引和分区的结果。 在关系数据库中，我们可以添加列，转换表，将数据从一个表翻转到另一个表，以及如果我们之前忘记了索引，则可以添加索引。 对于NoSQL数据库，并非在所有情况下都可行。 我们可能需要使用一些外部工具，例如Apache Spark，甚至删除并重新创建我们的数据模型。
在Elasticsearch中，如果我们无法获取索引的架构/映射，则必须使用例如 重新索引API，这意味着我们必须将数据重新索引到另一个索引。
在Cassandra中，我们只能按分区键和群集键进行过滤。 如果我们忘记在键中添加一列，则有可能添加索引，但是如果集合的基数很大，则会降低性能。
不支持ACID
ACID属性简化了代码编写。 我们不需要处理与以下事实有关的错误：X表中的数据已经存在，而Y表中的数据尚未存在(如果有的话)。 根据CAP定理，我们知道存在一致的数据库和最终一致的数据库。 这种类型最流行的数据库是Apache Cassandra。 最终的一致性要求对数据建模和应用程序逻辑采用不同的方法。 应该以一种更具防御性的方式编写代码，因为不确定您刚刚更改的记录是否可以从应用程序的另一部分获得。 HBase是一致性数据库的一个示例，但是即使Cloudera相信它也不会替代关系数据库。 一些数据库宣称自己是一致的，并且仅在一定程度上确保了一致性。 例如，MongoDB提供事务，但是多文档事务仅自版本4.0起可用。
不支持SQL
NoSQL的缺点是缺少SQL。 我们可能喜欢不喜欢，但SQL是数据的基础。 许多分析师每天都在使用SQL，学习其他语言可能会阻止他们使用数据库。 创建Spark SQL或Beam SQL的原因是有原因的。
分析有限和/或没有Join
这只是关于OLTP和OLAP系统之间差异的讨论。 我们习惯于使用GROUP BY和JOIN子句，但并非每个数据库都会提供此类功能。 由于数据库的性质，聚合和合并可能非常有限(如果可能)。 对于Apache Cassandra，分析功能通常是通过将Apache Spark集群组合在一起来实现的。 您将通过我的故事学习如何将彼此联系起来。
概要
那么值得使用NoSQL吗? 当然是这样。 我们必须记住，创建每个数据库都是为了解决一类问题。 歪曲"命运"是可能的，但会带来后果。 螺丝刀更容易用螺丝刀拧入，用锤子敲钉子和用棍子使墙壁疼痛。
一个有趣的替代方法是NewSQL数据库。 这样的一个例子是CockroachDb和Spanner。 他们解决了传统关系数据库的问题(主要是扩展问题)，同时保持了ACID属性。
