这是一种非常简单而且已经拥有悠久历史的解决思路：在数据库中利用一套分布式架构实现请求数据的快速返回。此类方案会在同时间于多台服务器上运行数据库查询操作，而后将来自成百甚至上千台集群内服务器的返回结果汇总起来进行交付。
即使并不新鲜，这种理念为什么最近又赢得了新的关注？这是因为它成为MapReduce背后的核心机制，而MapReduce正是Hadoop在大数据分析工作中所采用的并行处理模式。这些分布式工作负载近年来被大规模使用，通常与均匀的服务器集群相搭配——也就是说需要运行在大量同样的服务器设备之上。这种均匀性要求将用户限制在了单一服务器集群或者单一云环境当中，意味着我们需要为其搭配一种资源类型及成本方案、再无其它可选。
但在迅速兴起的多云方案当中，数据处理工作负载运行在那些能够真正切合工作负载实际需求的云服务之上。目前面向多云架构的积极探索为用户带来了将工作负载安置在公有或者私有云服务上，从而为负载自身需求提供最短条件的能力。这同时也允许大家将工作负载运行在那些***成本效率的云服务之上。
跨多个云平台处理数据实例
举例来说，当处理流程以查询形式出现时，启动这条数据库查询的客户端可能驻留在托管服务供应商的运行环境下。不过它可能会将请求指向Amazon Web Services公有云服务上的多个服务器实例。它同样可以管理栖身于微软Azure云环境下的事务型数据库。此外，它也能够将数据请求结果保存在本地OpenStack私有云当中。灵活多样，相信大家已经明白这一特性了。
由此带来的好处是显而易见的：大家可以将云服务与工作负载进行混合与匹配，从而在提升性能表现的同时降低使用成本。事实上，我们完全可以根据实际需要将工作负载在不同云环境之间随意迁移。
时至今日，已经有大量数据库处理机制选择云计算服务作为依托——则其使用成本并不便宜。将工作负载在不同云服务之间迁移为那些管理着大型分布式数据库的使用者带来了巨大力量，允许他们只选择那些提供***、***性价比服务的供应商——或者是那些最能满足其数据库处理需要的供应商。
当然，这类事务处理方式颇为复杂，而且必然会对管理与自动化提出要求。云管理平台工具在这方面应该能够起到作用，因为它们可以提供之前描述的实际处理流程的能力。
请大家保持清醒的头脑——这种新思路绝不像听起来那么难以驯服，而拥有更多选择也永远不是坏事。
原文链接：
原文标题：The right cloud for the job: Multicloud database processing is here
