NoSQL数据库的5个陷阱我录制了一段视频

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