数据库sharding产品选型案例

(中国软件网讯)AppDynamics是一家位于美国旧金山的APM解决方案提供商，成立于2008年。根据公司数据库总监Boris Livshutz的说法，虽然Clusterix的技术很好，但是AppDynamics最终还是选择了ScaleBase来应对数据库sharding的需求。其中一个重要原因就是ScaleBase提供高质量的个性化定制与技术支持服务。

Livshutz称，Clusterix的产品虽然是业界中最好的，但是它们的价格非常昂贵，而且产品中的许多功能对于AppDynamics来说是多余的。比如，Clusterix会把所有的数据存储在固态硬盘上，这部分硬件开支对于AppDynamics来说是承受不起的。还有Clusterix的连接都是通过InfiniBand技术实现的，而不是现在普遍使用的以太网，AppDynamics在性能上也没有这么高的需求。

sharding这个词最早是由Google的工程师提出，该技术能够让用户对系统进行水平扩展，而且不必去购置新的硬件设备。经过分片后的数据库将可以运行在分布式的服务器集群当中(译者注：database sharding的中文翻译是数据库分片，它与数据库分区partition是有区别的，具体可以参考Fenng的一篇文章：开源数据库 Sharding 技术)。

AppDynamics公司的解决方案能够对企业内部和云中的应用程序进行性能的监控和管理，他们认为Clusterix的产品是使用时下流行的软硬件集成方式，势必会影响整个系统的灵活性，这也是所有一体化产品的通病。

Livshutz表示，Clusterix产品贵就贵在他们的硬件上，他们提供的是一体化的解决方案，而且没有任何商量的余地。这一点跟Oracle非常像，他们买的是高度集成的产品，不会去根据客户的需求进行量身订造。

AppDynamics的选型之路

AppDynamics开始进行产品选型评估是在1年半以前，当时由于其客户的需求，公司也需要将它们的MySQL数据库进行相应的扩展。然而不断添加硬件的成本已经让AppDynamics无法承受。

“从公司老板到底下的员工，每个人都想要一个能够扩展的架构。包括我们的客户也是，他们会看到性能方面的问题是很明显的，” Livshutz解释说：“他们想要立刻进行扩展，并希望我们能够跟随他们也在第一时间完成扩展。”

Livshutz介绍，当初公司评估Clusterix产品的同时，也曾考虑过让团队自己建立一套数据库sharding系统，还参考了CodeFutures公司的dbShards软件。

当然，AppDynamics的团队很快发现自己构建一个内部系统是不现实的，主要因为公司的IT人手实在匮乏，并且团队以年轻人为主，对于系统的维护经验严重不足。此外，团队的主要工作是监控AppDynamics自身的核心应用，而不是一套数据库sharding系统。

“我们有能力自己构建一套系统，但是谁来维护它呢?” Livshutz无奈地说：“现实所迫，我们放弃了自己开发的念头。”

Livshutz在与CodeFutures的dbShards团队接触时发现，他们非常热情，并愿意与AppDynamics的团队共同协作。但是Livshutz对于公司的业务模型表示担忧，他认为CodeFutures是一家非常专业的服务商，而AppDynamics自身只是一家名气不大，成立也仅仅4年的创业公司。因此Livshutz认为，选择与自己相仿的合作伙伴会更靠谱一些。

最终经过一系列的评估，AppDynamics还是选择了ScaleBase公司的Data Traffic Manager产品来管理并扩展他们的数据库环境，据Livshutz介绍，目前公司已经完成了产品部署，并成功运行了几个月的时间。

“从长远角度看，ScaleBase的功能性很难说强大，” Livshutz说：“但是他们愿意与我们合作，并根据我们的需求不断调整系统，添加更多的组件和功能，这正是我们需要的。”

Livshutz表示，ScaleBase的产品在易用性方面很有优势，能够让AppDynamics以最快的速度投身到数据库sharding中来。未来，公司还计划购买一套系统，来监控数据库sharding的操作。

“对于应用性能的监控，我们是专业的，但是数据库sharding就不一样了，我们希望未来的监控系统能够做到像AppDynamics自身的产品一样。” Livshutz说。