Key to enterprise application of NoSQL

The discussion about whether NoSQL can be competent for enterprise-level databases is rampant. The focus of attention is that the environment of NoSQL databases is uncertain and changing. Some No

The discussion about whether NoSQL can be competent for enterprise-level databases is rampant. The focus of attention is that the environment of NoSQL databases is uncertain and changing. Some No

The discussion about whether NoSQL can be competent for enterprise-level databases is rampant. The focus of attention is that the environment of NoSQL databases is uncertain and changing.

Some NoSQL enterprises claim that they have prepared enterprise-level services, but in fact they still do not have solid functional attributes they need, some even remove related attributes to ensure database performance. This situation is acceptable for testing prototypes or non-production environments, but it is hard to imagine that in practical applications, enterprises will process their most critical data in such a dangerous way.

NoSQL databases are flexible, agile, fast, and scalable, and provide disaster recovery and high availability. Of course, if you develop an enterprise-level NoSQL database, the above features are not enough. The most important thing is to support the requirements of enterprise-level applications, including transaction consistency and SQL support.

Today, NoSQL has entered the mainstream of the database industry. Data Center administrators are carefully studying this new technology to ensure that it can meet all the requirements of enterprises, it is not just a part of it. Only in this way can enterprises effectively explore and manage the value behind a large amount of data, standardize operations, and avoid possible risks.

Transactions

ACID transactions were originally an "exclusive stunt" of RDBMS, and today's NoSQL basically does not have such content. Because the consistency function is added to a database that is not originally aimed at consistency, the difficulty is conceivable. Therefore, the "final consistency" appeared later ". With "final consistency", although the data cannot be completely consistent at all times, the consistency problem is also largely solved, and in actual application, "eventual consistency" can fully meet the requirements of most applications.

In addition, transactions and NoSQL are not in opposition, and they can fully realize the organic combination of transactions and NoSQL. For enterprise applications, the existence of transactions can ensure the security and reliability of data operations. I think enterprise-level NoSQL should support simple transaction operations. For example, operations in a transaction can only insert data, modify data, and delete data. Other operations executed in the transaction process will not be included in the transaction category, that is to say, non-transaction operations will not be rolled back during transaction rollback. If data in a table or tablespace involves transaction operations, the table or tablespace cannot be deleted. In this way, although the functions are not as comprehensive as RDBMS, they can meet the vast majority of enterprise-level applications!

SQL support

Some people think that NoSQL cannot and should not support SQL statements. In fact, I think this is a misunderstanding. The SQL language was originally based on the relational model, but many operations and statements are not limited to relational databases. In addition, for most database users and DBAs, the SQL thinking has been deeply rooted in their minds, on the one hand, it is very difficult and unnecessary to completely change this idea. At the same time, the SQL language is still very suitable in many enterprise-level application scenarios. I don't think it can be totally denied.

Therefore, I think NoSQL is also very important for SQL language support. The SequoiaDB mentioned earlier uses a self-developed converter to support PostgreSQL. In our practical application, SQL support indeed saves us a lot of learning time.

Read/write splitting

In database operations, to ensure consistency, other programs cannot call data that is being written, which will inevitably affect the performance. Even though the document-type NoSQL data model is not an RDBMS table structure but an independent JSON document, it has improved performance, but in the case of write operations, you still need to "Lock" the written document ". Therefore, I think read/write splitting is crucial for enterprise NoSQL. For example, in SequoiaDB, they applied the Master-Slave mode to build a data group, so that the data on the Master node is asynchronously replicated to the Slave node. The Slave node performs read-only operations while the Master node performs write operations, in this way, read/write splitting is achieved, further improving the performance.

NoSQL has already been used in many enterprise-level applications. However, most NoSQL products do not seem to have corresponding functions and policies for enterprise-level products. Most of these problems are solved by the actual application team, as a result, SequoiaDB is designed for enterprise users at the beginning, and NoSQL databases with proprietary functions designed for enterprise users are the first choice for enterprises that really need applications!

Quick Start to NoSQL databases. For details about how to download high-definition PDF, see

Basic knowledge about NoSQL Databases