在转到奥尔胡斯，我们有一个关于NoSQL的一些实际经验的轨道。我被要求做一个初步的演讲来解释NoSQL数据存储的基本原理。我将讨论NoSQL的起源、NoSQL数据模型的形式、许多NoSQL数据库考虑一致性问题的方式，以及多语言持久性的重要性。

近年来，关于无模式数据的优点的讨论越来越多。无模式是感兴趣的主要原因之一NoSQL数据库．但是在数据库和内存数据结构方面，无模式涉及到许多微妙之处。这些微妙之处既体现在无模式的含义上，也体现在使用无模式方法的优缺点上。

我们设计这本书的时候，NoSQL蒸馏，我们在大部分章节的结尾都总结了一些要点，以作为读者重新阅读这本书的复习。我们将这些内容放在网站上，以另一种方式提醒读者注意这些要点。

其中一条铁轨在转到奥尔胡斯让NoSQL供应商有机会谈论他们的各种工具。在跟踪的最后，不同的演讲者被安排在一个小组中讨论一些涉及NoSQL的常见问题。虽然我没有参与(我的演讲(几天后)我也参与了这个小组。

我们在2012伦敦QCon上的主题演讲着眼于数据在我们生活中所扮演的角色(它所做的不仅仅是变得更大)。我们首先看看数据世界是如何变化的:它在增长，变得更加分布式和连接。然后我们转向行业的回应:NoSQL的兴起，向服务集成的转变，事件来源的出现，云的影响，以及对可视化发挥更大作用的新分析。我们将快速浏览一下目前数据是如何被使用的，丽贝卡将特别强调发展中国家的数据。最后，我们考虑这一切对我们作为软件专业人员的个人责任意味着什么。

关于企业中数据存储的未来的信息平台，主要为参与应用程序开发管理的人员编写。解释了为什么关系数据库一直占据主导地位，为什么NoSQL正在挑战这一假设，并概述了Polyglot Persistence的未来，根据应用程序的不同需求，将使用多种数据存储技术。

这是我们工作时首先想到的话题之一Nosql蒸馏NoSQL数据库使用不同于关系模型的数据模型。我看过的大多数来源都至少提到了四组数据模型:键值、文档、列族和图。看一下这个列表，前三者之间有很大的相似之处——它们都有一个基本的存储单元，这是一个密切相关的数据的丰富结构:键值存储是值，文档存储是文档，列族存储是列族。在DDD术语中，这组数据是一个DDD_Aggregate．

几年前，我听到编程语言的人在Java引起的语言中谈论“核冬天”。当时的感觉是，每个人都如此趋同于Java的计算模型(当时的c#被认为不过是一种剽窃)，以至于编程语言的创造力已经消失了。这种感觉现在正在减弱，但也许一种更重要的解冻正在开始——对数据库的思考将变得更长久、更深入。

通过服务器流动JSON数据结构是我最近看到的更多的事情。JSON文档可以直接持久化，可以使用AggregateOrientedDatabase或者一个序列化LOB在关系数据库中。JSON文档也可以直接提供给web浏览器，或用于将数据传输到服务器端页面渲染器。当以这种方式使用JSON时，我听到人们说使用面向对象语言会造成阻碍，因为需要将JSON转换为对象，然后再进行渲染——这是对编程工作的浪费。我同意关于浪费的观点，但我认为这不是对象的问题，而是没有理解封装的问题。

在许多组织中，期望任何持久数据都存储在由中央数据库管理组管理的关系数据库中。这种集中控制有各种各样的原因，通常围绕使用IntegrationDatabases．中央数据组担心屏蔽畸形数据、可能降低重要共享资源速度的查询以及跨企业的一致数据模型。

这些目标可能是值得的，但它们的一个后果是关于存储数据的相当讲究的仪式。我经常听到对更改命令的抱怨，向数据库添加一列需要花费数周的时间。对于习惯于短周期进化设计的现代应用程序开发人员来说，这样的仪式太慢了，更不用说太烦人了。

所以应用程序开发小组告诉我使用NoSQL数据库绕过dba进行终端运行。他们在这里使用的是“单纯的数据存储”，而不是“适当的数据库”，这是有帮助的。通过这种方式，dba可以被排除在循环之外，通常不被告知或乐于不关心。

当我们开始工作的时候Nosql蒸馏我们面临着一个棘手的难题——我们要写什么?NoSQL数据库到底是什么?现在还没有明确的概念定义，没有商标，没有标准的团体，甚至没有一个宣言。

2006年，我的同事尼尔·福特(Neal Ford)创造了这个术语通晓多种语言的编程，以表达应该用混合语言编写应用程序的想法，以利用不同的语言适合处理不同的问题这一事实。复杂的应用程序组合了不同类型的问题，因此为工作选择正确的语言可能比试图将所有方面都放到一种语言中更有成效。

在过去的几年里，人们对新语言的兴趣激增，特别是函数式语言，我经常想花些时间钻研Clojure、Scala、Erlang或类似的语言。但我的时间有限，我将优先考虑另一个更重要的转变，那就是DatabaseThaw．第一批资金已经从客户和其他联系人那里获得，前景非常诱人。我可以自信地说，如果您开始一个新的战略企业应用程序，您不应该再假设您的持久性应该是关系的。关系选项可能是正确的选项——但是您应该认真地考虑其他选项。