开源同盟 越来越多的应用开发商和托管服务提供商认识到NoSQL和MySQL一直是开源同盟，没有因数据库类型不同而成为不相往来的仇敌。归于一点，数据就是数据，它应该用来为应用程序和用户服务，不应该受到后端数据库的限制。 越来越多的Rackspace客户发现自己面临和Craigslist同样的处境。当关系型数据库涵盖所有他们的数据领域时，他们构建了自己的数据结构，而现在他们已经进入应用时代了。 达到100万客户原先需要数年时间，现在只需要几周就可以了，而且社会共享和实时查询对数据提出了新的要求——也需要支持这些数据的基础设施，这一系列变化使他们面临的数据量达到了每月10亿之巨。 他们不一定要挖掘MySQL数据库，但他们需要增加数据引擎。为了增加数据库的速度和灵活性，MongoDB、Cassandra或者 Redis（这类数据库）会被纳入数据结构中。但这些开源数据库不太可能用于存储用户机密信息或者财务记录，因为这些内容必须始终保持一致性。 目前，技术公司在聘请传统关系型数据库管理员同时，组建一个NoSQL应用开发团队也很常见。有时，基于关系型数据库和非关系型数据库的同一个应用甚至可以在Web层进行通信。 过去的数据库管理员必须和新一代使用NoSQL编程的开发人员合作，进行有关部署和体系结构的决策（也许这些数据库管理员和开发人员也能成为朋友）。 可能这类公司连数据库管理员也没有，它们将所有的应用和数据层外包给托管服务供应商，这样的话，它们就得充分利用深厚的专业知识和团队合作，才能跨越SQL与NoSQL之间的鸿沟。 选择其中一个？还是两者都要？ 应用程序是否应该与关系型数据库或NoSQL（也许是两者）相一致，当然，这得基于被生成或被检索数据的性质。和大多数科技领域的事物一样，做决定时要折中考虑。 如果规模和性能比24小时的数据一致性更重要，那NoSQL是一个理想的选择 （NoSQL依赖于BASE模型——基本可用、软状态、最终一致性）。 但如果要保证到“始终一致”，尤其是对于机密信息和财务信息，那么MySQL很可能是最优的选择（MySQL依赖于ACID模型——原子性、一致性、独立性和耐久性）。 作为开源数据库，无论是关系型数据库还是非关系型数据库都在不断成熟，我们可以期待还会有一大批基于ACID和BASE模型的新应用产生。 暂且把它称为混合方案。有时这些应用程序的设计需要认真地权衡利弊，有时还能意外的得到发展，做出一系列调整以适应不断变化的数据需求，毕竟，谁能预测到今天社会共享数据的大规模增加（即使是在五年前）？ 像往常一样，开发人员处于这种创新的最前沿，他们促使托管服务提供商将这两个数据领域结合到一起。在必要时候，他们还会对开源数据技术进行修正。 比如，在Oracle占有了MySQL后，MySQL有闭源的风险，基于MySQL的MariaDB很好的替代了MySQL。开发者社区要求其开源工具完全透明，包括开放对测试用例bug修复的权限。 此混合方案在2014年将继续发展，托管公司也会提供更好的支持。在媒体上，我们就不会再说“要么关系型数据库，要么非关系型数据库”这样的话了。 这和混合云领域所用方法是类似的。专用硬件有着优越的性能，而公共云有很好的可扩展性，结合两者优点可以带来更大的灵活性，产生最合适的解决方案，这才是解决问题的最优办法。 毕竟，数据收集和解释的最终目标是捕获这个瞬息万变世界发生的每一条信息。数据，无论来自何处，都只是一个窗口，真正重要的是透过这个窗口看到的景象。 |
