NoSQL or Traditional Database
From an APM perspective there isn’t really much difference
By: Michael Kopp
Oct. 27, 2012 10:00 AM
Traditional Enterprise Database vendors often bring up the lack of professional monitoring and management tool support for NoSQL solutions. Their argument is that enterprise applications require sophisticated tuning and monitoring of the database in order to ensure a performant and smooth operation. NoSQL Vendors, while arguing that this lack is not enough to favor RDBMS over their respective solutions, do agree. Several vendors try to differentiate themselves by providing enterprise level monitoring and management software, for example, Cassandra, MongoDB, HBase or others. Both are of course correct that monitoring and management of especially the performance aspect is important, but at the same time they are making the same mistake that RDBMS vendors have made for the last decade: they ignore the application.
Application Performance Management for Databases
First we need to understand if a particular business transaction slows down, has a general performance problem and if this has an impact on the end user:
Do any of the business transactions violate a baseline or have negative end user experience
Next we would isolate the high level cause of the slow down or performance issue. There are many ways of doing this, but it's always some kind of fault domain isolation:
Transaction Flow shows that we spend ~15 % waiting for the Database
This Transaction Flow shows that the Business Backend is calling a Cassandra Database Cluster
This tells us if we spend time waiting on the database. We see that there is not much difference between a regular database and something like an Apache Cassandra!
What's important here is that if the database shows up as the main contributor, this does not mean that the database itself is at fault, it might just be the applications usage of it. Thus I would need to check the usage and access pattern next:
This shows the select statements executed within a particular transaction type
This shows all Cassandra database statements against all participating Cassandra servers executed in a particular transaction
Here I might see that the reason for bad performance is that we execute too many statements per transaction, or that we read too much data. If that is the case I would need to check the application logic itself and potentially need a developer to fix it. The developer would of course want to understand where, why and in which particular transaction the statements are executed.
This shows a single Transaction (PurePath) and the Cassandra Statements executed within it
If however a particular statement is slow we, might very well have a database issue and I would talk to the DBA. The only difference in case of a NoSQL solution in this process is that you often have a database cluster, so I would want to understand if the problem is isolated to a particular node or not. And the DBA will want to understand if my access pattern leads to a good distribution across that cluster or if I am hammering away at a subset of them.
This hotspot view shows that Cassandra Server Node3 consumes much more Wait and I/O time than the others
The nice thing is that all in all my analysis does not differ between JDBC, ADO, Cassandra or one of the many NoSQL solutions.
APM Solution Support
Reader Feedback: Page 1 of 1
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week