From the APM perspective, nosql and relational databases are not different.

Michael Kopp has more than 10 years of architecture and development experience in C ++ and Java/Jee. He is now a compuware technology strategist who specializes in the architecture and performance of large-scale product deployment.

The following is a translation:

Traditional enterprise database vendors often propose that nosql lacks professional monitoring and management tools. Their arguments are: enterprise applicationsProgramThe database needs to be fine-tuned and monitored to ensure stable performance and operation. The nosql vendor's point of view is that the lack of such degree does not help RDBMS in solutions. Many nosql vendors also try to differentiate their monitoring and management software levels, such as Cassandra, MongoDB, and hbase. Of course, both of them are correct-especially performance management and monitoring are very important, but nosql vendors have also made the RDBMS mistake for more than 10 years: ignoring the application itself.

Application Performance Management for Databases

The most important thing is not the performance of the database itself, but the application of the database. The logic of the application determines how to use the database. Of course, there are also many ways to optimize the database to conceal the problems of the application itself. Therefore, we need to monitor and optimize the application usage mode. At the same time, the application logic is determined by the input data or the mode of interaction with users in most cases. Therefore, we must analyze user behavior, user operations determine how the database is used. On the other hand, we need to understand the impact of these behaviors on the database. The focus here is to learn that when the performance of data reaches the highest standard, it still becomes the main bottleneck of applications-whether they are incorrectly used or use an incorrect access mode. Both RDBMS and nosql databases share the same experience. Therefore, as an engineer, you need to analyze and manage application performance:

First, we need to know if this slow transaction has a common performance problem and is affected by end users:

Step 2: perform high-grade extraction for slow performance or performance problems. Of course, there are many ways to achieve this purpose, but it is basically a type of fault domain isolation.

The transaction flow shows that 15% of the transactions are used in the database wait (click to view the large image, the same as below)

This transaction flow shows that business backend is calling a Cassandra database cluster.

This will let us know if we are spending time waiting for the database. Here we can see that this phenomenon is not different because of traditional databases or nosql databases like Apache Cassandra.

The key here is whether the database is the main cause, which is not necessarily a problem of the database itself, but also the use of applications. The usage and access mode must be checked below:

The SELECT statement executed in a special transaction type is shown here.

Displays the execution of Cassandra database statements on all servers involved in a special transaction.

Here we will find that the cause of low performance is that we execute too many statements in a single transaction or read too much data. If this is the case, we need to check the application logic and make up for it by developers. This developer must want to know where the statement runs the special task and why it occurs.

Displays the single transaction (purepath) and Cassandra execution statements in it

If a special statement causes performance degradation, it may be a database problem. We can find DBA to solve it. In this case, the difference between the nosql solution is that you can usually have a database cluster, so you need to know whether the problem is caused by a single node. DBA will check whether the access mode is well allocated to the cluster, or just assign it to a point in the cluster.

It shows that the Cassandra server node3 consumes more waiting and I/O time than other nodes.

In fact, this analysis is no different between JDBC, ADO, Cassandra (or other nosql solutions.

Summary

After a lot of research on SQL statements and indexes, we found that the most important thing to optimize is the database usage of applications and applications. SQL tuning always adds complexity, which is generally used as a swap for poor applications or data structure design. In the nosql field, the optimization of database statements has become a thing of the past, but the data structure design retains its importance. At the same time, the logic that should be implemented in the database has been transferred to the application layer, which makes the application design more important than before.

Original article: nosql or traditional database: from an APM perspective there isn' t really much difference