Michael Kopp拥有十年以上C++、Java/JEE的架构及开发经验，现Compuware技术策略师，专攻大规模产品部署的架构和性能。
以下为译文：
传统企业数据库供应商经常提出NoSQL缺乏专业的监视和管理工具。它们的论点是：企业应用程序需要对数据库进行精细的调优和监视以保证性能和运转的稳定。NoSQL供应商的观点则是：这种程度的缺乏还并不能在解决方案上帮助到RDBMS。许多NoSQL供应商也尝试从它们提供的监视和管理软件等级上进行区分，比如：Cassandra、MongoDB、Hbase等等。当然两者都是正确的 —— 特别是性能方面的管理和监视是非常重要的，但是NoSQL供应商同样犯了RDBMS已经犯了10多年的错误：忽略了应用程序的本身。
针对数据库的应用性能管理
最重要的不是数据库本身的性能，而是使用数据库的应用程序。应用程序的逻辑决定了使用数据库的方式，当然也有很多途径来调优数据库用以掩饰应用程序本身的问题。所以我们需要监视和优化应用程序的使用模式，同时应用程序逻辑又由输入数据或者是大多数情况下与用户交互的方式决定；所以我们必须分析用户的行为，而用户的操作决定了数据库的使用方式。另一方面，我们需要明白这些行为对数据库的影响。这里的重点在于获悉当数据的性能达到最高标准，却仍然成为应用程序的主要瓶颈 —— 它们是否被错误的使用或者是使用了一个错误的访问模式。在这上面不管是RDBMS还是NoSQL数据库都有着相同的遭遇。因此作为工程师，你需要做应用程序的性能分析和管理：
首先我们需要知道这个慢下来的事务是不是有一个普遍的性能问题，并且受到终端用户的影响：
这个事务流显示Business Backend正在调用一个Cassandra数据库集群
这就可以让我们知道是否我们为等待数据库而花费时间。而这里我们看到了这个现象并没有因为传统数据库或者是类Apache Cassandra的NoSQL数据库而变得不同。
这里的重点在于数据库是否是主要原因，这并不一定是数据库本身的问题，也能是应用程序的使用问题。下面就必须检查用法和访问模式：
上图显示了单事务（PurePath）以及里面的Cassandra执行语句
如果一个特殊的语句导致性能下降，那么很可能是数据库问题，我们可以寻找DBA解决。而这种情况下NoSQL方案的不同之处是你通常可以拥有一个数据库集群，所以需要知道的是问题是否是因为单个节点产生的。DBA将去了解访问模式是否被良好的分配到集群中，或者只是分配到集群中的一个点。
上图显示了Cassandra服务器Node3比其它节点消耗了更多的等待和I/O时间
而事实上这个分析在JDBC、ADO、Cassandra（或者其它的NoSQL解决方案）之间并没有什么不同。
总结
经过大量在SQL语句和索引上的研究后发现：最需要优化的地方总是在应用程序以及应用程序使用数据库的方法上。而SQL Tuning总会添加复杂性，一般只作为差用程序或者数据结构设计的调剂。而在NoSQL领域数据库语句的调优已成为过去，但数据结构设计却保留着它的重要性。同时传统上应该在数据库实现的逻辑现已转移至应用层，这使得应用程序的设计较之前更为重要。