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