多语言持久化

2006年，我的同事Neal Ford创造了“多语言编程”一词，用来表达应用程序应该用多种语言编写，以利用不同语言适合解决不同问题的优势。复杂的应用程序结合了不同类型的问题，因此为工作选择合适的语言可能比试图将所有方面都纳入一种语言更有效率。

在过去的几年里，人们对新语言，特别是函数式语言的兴趣激增，我经常很想花些时间钻研Clojure、Scala、Erlang等语言。但我的时间有限，我将优先考虑另一个更重要的转变，即“数据库解冻”。第一批客户和其他联系人的反馈已经传来，前景诱人。我可以自信地说，如果你要启动一个新的战略性企业应用程序，你不应该再假设你的持久化应该是关系型的。关系型数据库可能是正确的选择，但你应该认真考虑其他选择。

有趣的结果之一是，我们正在为向多语言持久化[1]的转变做好准备，在这种转变中，任何规模可观的企业都将拥有各种不同的数据存储技术来处理不同类型的数据。仍然会有大量的数据在关系型数据库中管理，但我们将越来越多地首先询问我们希望如何操作数据，然后才确定哪种技术最适合它。

即使在单个应用程序中，这种多语言的影响也很明显[2]。复杂的企业应用程序使用不同类型的数据，并且通常已经集成了来自不同来源的信息。我们将越来越多地看到，此类应用程序根据数据的用途使用不同的技术来管理自己的数据。这种趋势将与将应用程序代码分解为通过Web服务集成的独立组件的趋势相辅相成。组件边界是包装为其数据操作方式选择特定存储技术的好方法。

这将以复杂性为代价。每种数据存储机制都引入了一个新的接口需要学习。此外，数据存储通常是性能瓶颈，因此您必须了解该技术如何才能获得理想的速度。使用正确的持久化技术将使这更容易，但挑战不会消失。

许多NoSQL选项都涉及在大型集群上运行。这不仅引入了一种不同的数据模型，还引入了一系列关于一致性和可用性的新问题。事务性的单一数据源将不再占据主导地位（尽管它作为这种角色的时代常常是虚幻的）。

因此，多语言持久化将付出代价，但它会到来，因为好处是值得的。当关系型数据库使用不当时，它们会对应用程序开发造成巨大的阻力。我最近与一个团队交谈，他们的应用程序本质上是编写和提供网页。他们只按ID查找页面元素，不需要事务，也不需要共享数据库。像这样的问题更适合使用键值存储，而不是他们必须使用的企业级关系型数据库。卫报是一个很好的公开例子，说明了如何为工作选择正确的NoSQL，他们已经感觉到使用MongoDB比以前的关系型数据库有明显的效率提升。

另一个好处是在集群上运行。使用垂直扩展来扩展到大量流量变得越来越困难，这一事实我们已经知道了很长时间。许多NoSQL数据库被设计为在集群上运行，并且可以处理比单台服务器更大量的流量和数据。随着企业希望更多地使用数据，这种扩展将变得越来越重要。在gotoAarhus2011上描述的丹麦药物系统就是一个很好的例子。

所有这些都导致了巨大的变化，但这不会很快发生，因为公司在数据存储方面自然比较保守。

更直接的问题是，哪些类型的项目应该考虑替代持久化模型？我的想法是，首先，你应该只考虑那些处于“实用与战略二分法”战略端的项目。这是因为实用型项目没有足够的好处来值得采用新技术。

对于战略性项目，你有两个驱动因素可以提出替代方案：减少开发阻力或处理密集的数据需求。即使在这里，我怀疑许多项目，可能是大多数项目，最好还是坚持关系型数据库的正统观念。但不应该这样做的少数人也是一个重要的群体。

一个可能不太重要的因素是项目是新的还是已经建立的。卫报转向MongoDB的转变发生在过去一年左右的时间里，而代码库是几年前开发的。多语言持久化是你可以在现有代码库上引入的东西。

所有这些都意味着，如果你在企业应用程序领域工作，现在是时候开始熟悉替代数据存储选项了。这不会是一场快速的革命，但我相信，未来十年将见证数据库解冻的快速发展。