弃用NoSQL数据库 CouchDB再见了(2)

　　压缩(Compaction)有时会没有任何提示的终止，有时还不得不被删除残留的文件使其重新运行。 这在我们提高了磁盘容量报警上线之前导致了一些可怕的情况，因为我们发现这一点时，由于做压缩，磁盘仅剩下非常小的空间。

　　在早期版本中，我们遇到了有关文件句柄使用的三、四个错误。 Bug reports快速修复了他们，并在1.0.2版本中更新了有关代码。

　　性能：

　　真的还有一件事要在这里说，那个CouchDB的视图查询的性能问题，并没有达到我们曾经期望的与MySQL索引查询大致相等的性能级别。 这不是一个巨大的惊喜或者一个巨大的问题，但是哇塞(but wow)，现在很多事情更快了，我们的数据库机器是负担减少了许多。

　　维护问题：

　　当CouchDB出错时，会使所有正在运行的查询出错。 其中包括复制和压缩，所以我们需要脚本来检查这些进程，并在必要时重新启动它们。

　　视图索引仅在查询时才更新-插入操作不会更新索引。 这意味着你必须写一个脚本来定期查看你的视图，除非你想在一段时间无人问津时他们变的出奇的慢。 在实践中，我们总是倾向于不通过插入操作更新索引来获得提高性能的可能。但是写一些可靠的脚本监控数据的索引是机警(tricky)的。

　　用于压缩的简单的复制收集器 可以花大量时间查看长期的文档。当一个数据库既有长期文件又有短期文件时这尤其是个坏消息：压缩需要很长时间，但急需控制住磁盘使用率。 另外，你不得不自己运行压缩和监测，以确保它的工作是有意义的。 压缩应该是自动化和分代(generational)的。

　　未实现的诺言：

　　CouchDB的设计看起来对像自动分片等NoSQL的主要功能非常完美，但事实并不是这样。

　　映射化简(MapReduce)只能在一台机器上运行有何意义? 我们原本以为这是为分布式查询而设计的功能。

　　我们从来没有清楚过CouchDB开发人员对其核心用途的考虑。 我们看到了发展的重点是集所有功能于一身的应用程序服务，然后是大规模多方向移动应用程序的复制。 两个都是有趣的想法，但不是我们所需要的。

　　(我们被告知在最近发布的CouchDB 1.2，这些问题已经解决。)

　　我们能够有效发挥CouchDB的性能，并随着时间的推移，我们了解到各种的维修问题的脚本方式。 但我们担心CouchDB好像被和我们不同的用法所吸引着，这是最终最终迫使我们做数据库转换的导火索。 我们谈到了一些可能的选择，和最终的一个典型解决方案。

　　MySQL，原始的NoSQL数据库

　　那么，为什么不能切换到另一个像MongoDB面向文档的数据库或其他NoSQL数据库呢? 我们曾经对MongoDB非常感兴趣，但在做一些研究和听到褒贬不一的评论后 ，我们得出结论：同CouchDB一样，它也有很多相同的问题使我们的工作受到影响。其他NoSQL数据库往往一样不同的，像CouchDB与MySQL之间一样区别很大。

　　) -因此很难选择 -而且对我们还有很多不熟悉的事情。 鉴于对MySQL的经验，我们知道这它能足够满足我们的需求，很难证明其他的选择同样适合。

　　我们很熟悉MySQL的缺点：别的咱不说，光它的配置就很麻烦(提示：优化性能中最重要的设置是innodb_buffer_pool_size)，存储引擎的选择，以及除了面向SQl,分析执行查询SQL语句的时间花费。经验丰富的MySQL用户期望写出很多强制索引子句。

　　另一方面，InnoDB存储引擎整体来看还是非常强大的。在过去十年中，它已经在一些最大的互联网公司大量使用，而且变得越来越强壮。几乎所有的数据库在底层是都建立在相同的基本B-树算法、散列和类似InnoDB存储引擎的缓存。在尊重基本原理的前提下，任何新的数据库管理系统对在真实环境性能和和靠性的突破都是非常艰难的。 但也许未必一定这样：Percona的前瞻性思维的键/值接口是一个可靠的InnoDB存储引擎如何成为真正的NoSQL架构的很好的例子。

　　刚换到MySQL数据库时，我们对它还像原始存储引擎一样。现在我们将使用MySQL，开发出之前NoSQL全部功能的方法。

　　我们设法将CouchDB的模型层(model layer)移植到MySQL中且对代码库的影响最小。对 大多数使用模型的代码(model-using code)，使用MySQL看起来和使用CouchDB的完全一样。 除了它的速度更快，而且这样的数据库从未出错。

　　我们不使用外键，或者多语句事务，到目前为止也未使用join。 一旦我们需时，我们已经准备好横向扩展(horizontally scale)。 (不过，这将需要一段时间!自从分片被发明的时期过后，硬件已经发展的更加强大，而且那些日子你可以仅靠单一的写主库运行很长的时间。)

　　我们的所有表都含有一个TEXT的字段用以存储JSON，我们的模型层为了大多数需求而悄悄将对待他们像真正的列一样。这个主意就像Rails 的ActiveRecord ::商店 。虽不是和MySQL的功能设置非常完美融合， MySQL不能真正操作这些JSON列 - 但它仍然是一个伟大的想法，让我们向无模式数据库更加紧密。

　　这是一个已证明的可靠的数据库存储引擎和给我们很多NoSQL数据库优点的架构的组合， 这种设置工作过去一两个月了，我们发现它非常难于达到最好的两个世界的途径。

原文转自：http://blogread.cn/it/article/5356