nosql数据库做数据备份_NoSQL数据库的5个陷阱

nosql数据库做数据备份

I recorded a video in which I talk about the advantages of NoSQL databases. The response was interesting, but I had the impression that not everyone sees the two sides of the coin. The facts are that they can cause us a lot of problems 😉.

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

模式管理 (Schema Management)

Each NoSQL database approaches the schema in its own way. In some there is no schema (MongoDB), in some, it is dynamic (Elasticsearch), and in some it resembles the one from relational databases (Cassandra). In the conceptual model, data ALWAYS have a pattern. Entities, fields, names, types, relations. Regardless of the type of base, the physical model is a representation of the conceptual model.

每个NoSQL数据库都以其自己的方式处理该模式。 在某些情况下没有模式( MongoDB )，在某些情况下它是动态的( Elasticsearch )，在某些情况下它类似于关系数据库中的模式( Cassandra )。 在概念模型中，数据始终具有模式。 实体，字段，名称，类型，关系。 不管基础类型如何，物理模型都是概念模型的表示。

NoSQL databases give us more freedom in terms of schema. In MongoDB, we can add two different documents with the same field names but different types. Does this make sense? Rather not. Can this happen? Of course, it can. A simple human error can break our app.

NoSQL数据库在架构方面为我们提供了更多自由。 在MongoDB中，我们可以添加两个具有相同字段名称但类型不同的不同文档。 这有意义吗？ 而不是。 这会发生吗？ 当然可以。 一个简单的人为错误可能会破坏我们的应用程序。

Another issue is related to relationships between entities. Even if there are no relations in our db, we have to document the relationships between the data. From the relational database we can generate an ERD diagram. In case of NoSQL databases this may not work.

另一个问题与实体之间的关系有关。 即使我们的数据库中没有关系，我们也必须记录数据之间的关系。 从关系数据库中，我们可以生成ERD图。 如果是NoSQL数据库，则可能无法使用。

When using NoSQL databases we have to remember about schema management and data validation issues. Without it the data can “explode”. Interesting fact: Some companies replace MongoDB with PostgreSQL.

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

较低的误差范围 (Lower margin of error)

Performance of NoSQL databases is the result of proper data modeling, indexing and partitioning. In a relational database we can add columns, transform tables, flip data from one table to another, add an index if we have forgotten about it before. In case of NoSQL databases, this will not be possible in all cases. We may need to use some external tools like Apache Spark or even drop and recreate our data model.

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

In Elasticsearch, if we don’t get the schema/mapping of an index, we have to use e.g. Reindex API, which means that we have to re-index data to another index.

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

In Cassandra, we can only filter by partition and clustering keys. If we forgot to add one of the columns to the key, there is a possibility of adding an index, but this can kill performance if the cardinality of the set is large.

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

无酸 (No ACID)

The ACID properties simplify code writing. We do not need to handle errors related to the fact that the data in the X-table is already there, and not yet in the Y-table (if at all). From the CAP theorem we know that there are consistent and eventual consistent databases. The most popular database of this type is Apache Cassandra. Eventual consistency requires a different approach to data modeling and application logic. The code should be written in a more defensive way, as it is not certain that the record you just changed is already available from another part of the application. HBase is an example of a consistent database, but even Cloudera believes that it will not replace a relational database. Some databases advertise themselves as consistent, and consistency is only ensured to some extent. For example, MongoDB offers transactions, but multi-document transactions are available only since version 4.0.

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

没有SQL (No SQL)

The disadvantage of NoSQL is the lack of… SQL 😁. We may like it or not, but SQL is the basis for data. Many analysts use SQL every day and learning another language may discourage them from using the database. There is a reason why Spark SQL or Beam SQL was created.

NoSQL的缺点是缺少SQL😁。 我们可能喜欢不喜欢，但SQL是数据的基础。 许多分析师每天都在使用SQL，学习其他语言可能会阻止他们使用数据库。 创建Spark SQL或Beam SQL的原因是有原因的。

分析有限和/或没有加入 (Limited analysis and/or no JOINs)

This is a little of a discussion of differences between OLTP and OLAP systems. We are used to using GROUP BY and JOIN clauses, but not every database will offer such features. Aggregations and mergers may be very limited (if possible) due to the nature of the database. In the case of Apache Cassandra, analytical capabilities are often achieved by putting together the Apache Spark cluster. You will learn how to connect one to the other from this story of mine.

这只是关于OLTP和OLAP系统之间差异的讨论。 我们习惯于使用GROUP BY和JOIN子句，但并非每个数据库都会提供此类功能。 由于数据库的性质，聚合和合并可能非常有限(如果可能)。 对于Apache Cassandra，分析功能通常是通过将Apache Spark集群组合在一起来实现的。 您将通过我的这个故事学习如何将彼此联系起来。

概要 (Summary)

Is it worth using NoSQL then? Of course, it is. We must remember that each database was created to solve a class of problems. Bending “destiny” is possible, but there are consequences. Screws are easier to screw in with a screwdriver, to hammer nails with a hammer and to pain walls with a roller.

那么值得使用NoSQL吗？ 当然是这样。 我们必须记住，创建每个数据库都是为了解决一类问题。 弯曲“命运”是可能的，但会带来后果。 螺丝刀更容易用螺丝刀拧入，用锤子敲钉子和用滚子使墙壁疼痛。

An interesting alternative is NewSQL databases. An example of such bases are CockroachDb and Spanner. They solve the problems of traditional relational databases (mainly the issue of scaling) while maintaining ACID properties.

一个有趣的替代方法是NewSQL数据库。 这样的基础的一个例子是CockroachDb和Spanner 。 他们解决了传统关系数据库的问题(主要是扩展问题)，同时保持了ACID属性。

翻译自: https://medium.com/@zorteran/5-pitfalls-of-nosql-databases-c35012431a80

nosql数据库做数据备份