As I looked at the chapters, I briefly reviewed the acid principle of transactional processing of relational databases, where atomicity and persistence were better understood. Because it was not studied in depth before. I have questions about consistency and isolation, after finishing the analysis as follows:
Consistency: The consistency in the book refers to the fact that the data is transferred from one consistent state to another in a consistent state before and after transaction processing. The book cited example is that the general ledger should not change before and after bank transfer. But I am puzzled that the consistency of the general ledger before and after the transfer should be controlled in the application, how can the database be guaranteed? Finally, my understanding is that the database itself does not guarantee the consistency of your data, but it has some processing, so long as your application does not have a problem, you can guarantee this consistency. For example, in an application, in a transaction, make a transfer: a = a + 30;b = B-30; How do we ensure this consistency? First of all, to ensure that the atomicity, either all succeed, or all fail, otherwise it will result in inconsistent data. Second, to ensure read consistency, the data queried in the transaction is the state of the point at which the transaction begins, and is not disturbed by other transactions (even transactions that have been committed since the start of the current transaction), and the individual feels that if the two points are guaranteed, the transfer operation will be consistent. Of course, the database itself can provide some consistent processing, such as primary foreign KEY constraints, check constraints, and so on. For example, when inserting data, it is possible to see if the foreign key exists in the corresponding table, otherwise the execution will fail. So, in a comprehensive understanding of the consistency measures that the database provides, I understand that there is a temporary read consistency and various constraints. This is when I read the understanding of the time, I later on the Internet access to more information, found that my understanding is only partial. (Even the author's understanding is wrong, such as the author of 2.1.5 The consistency of the simple understanding of the role of check constraints) in fact, the primary foreign KEY constraints, check constraints are the scope of database integrity (why is the integrity of the acid in the no longer?) I understand that because it only checks the check constraints on the data at the point at which the database executes, it is not the same as the entire transaction, so it is no longer the acid category. )。 And read consistency is only one important aspect of database consistency. The correct understanding of database consistency should be that the database itself does not fully guarantee the consistency of the data, only provide a mechanism (NoSQL should not even have this mechanism) to ensure consistency, such as Oracle's statement-level read consistency mechanism, transaction isolation level (can prevent dirty read, Non-repeatable reading, phantom reading, etc.), transaction-level read consistency, rollback segment mechanism are all important mechanisms to ensure read consistency. isolation: As for isolation, the book says that "when different transactions operate on the same data, each transaction has its own working space". I understand that when different times come to operate the same data, only one transaction is exclusive, and the other transaction can only wait for the exclusive transaction to execute commit or rollback. Later I thought that the author's so-called "operation" should include "Update" and "read, the update operation for one transaction is not read by another transaction until it is committed. It's reasonable. In conclusion, isolation means that each transaction is isolated from one another and is not known until completion (commit or rollback) is performed.
NoSQL database Technology in practice-1th NoSQL data consistency acid for traditional relational databases