Nosql企业之道
http://www.infoq.com/articles/nosql-in-the-enterprise
介绍
作为一个企业架构师的好处，就是我一直在找一些新的有希望的概念或想法，能够帮助我的企业用户处理不同垂直行业之间的问题。甚至在NoSQL这个词被杜撰（错误的杜撰？此处作者认为NoSQL这个词并不恰当，后面会提到）出来之前，因为上述的原因我曾持续关注了一段时间。在Amazon发表了Dynamo的论文之后，Google发布了BigTable的架构，成为了震撼作为最流行的解决方案的关系型数据库的基石。大概一年左右时间，NoSQL领域呈现爆炸式的增长，超过25项产品/解决方案延伸至行业的不同角落。因此，最近我想深入研究一下NoSQL运动究竟能给我的客户带来些什么好处。并且我还想知道是不是企业应该开始认真考虑对于该领域的研究与运用了。
NoSQL究竟是什么
和很多专注于该领域的人一样，我不喜欢NoSQL这个词，带有与SQL从根本上对立的感觉。我也不喜欢现在改进后的名称“Not Only SQL”。对于我来说我们讨论的并非是不是需要用SQL了。（相反的，有人可能仍然决定将SQL作为查询接口（但不支持join操作等方式）作用于这些数据库，这样能在保持现有资源技能的情况下管理开发的可扩展性和可维护性）。NoSQL更主要是帮助我们发现对于数据的存储和查询，是否还有其他更有效的方案来防止我们盲目的将关系型数据管理系统（RDBMS）应用在所有问题上。对我而言，“Non Relational Database”是对于这个想法更合适的描述。
不论名字是什么，“Non Relational Database”的范围有点过于广泛（名字有些否定向），有种能够包含“所有”的类型。这让人们（特别是企业决策者）对它到底包含和不包含什么感到疑惑，更重要的是为什么对人们是有意义的。
请记住，我要通过下面提到的特征为您展示“Non Relational Database”的核心精神。
“Non Relational Database”是：
1. 逻辑模型数据使用使用松散的数据结构(Map, Column Family, Document, Graph 等)代替固定关系结构。
2. 根据CAP原则（即保证一致性、有效性和可分离性中有两个可以实现），可以通过数据分布式模型来访问多个节点达到水平扩展的目的。可以用于构建多数据中心和动态部署（可以显式的从产品集群中增删节点），弹性结构。
3. 可以将数据持久化与磁盘或内存中，或者两者兼有；并且支持自定义的存储方式。
4. 支持多种“Non-SQL”的数据访问接口方式（通常多于一种）。
这些基本囊括了网络上最近关于“Non Relational Database”的四个特征（数据逻辑模型, 数据分布模型, 数据持久化 和 接口），我就不一一重复介绍了，按照关键特征及相关实例做一个介绍-
接口（Interface）- REST (HBase, CouchDB, Riak等), MapReduce (HBase, CouchDB, MongoDB, Hypertable等), Get/Put (Voldemort, Scalaris等), Thrift (HBase, Hypertable, Cassandra等), Language Specific APIs (MongoDB)
接口主要是用于通信交互。
数据逻辑模型（Logical Data Models）–Key-Value oriented (Voldemort, Dynomite 等), Column Familiy oriented (BigTable, HBase, Hypertable 等), Document oriented (Couch DB, MongoDB 等), Graph oriented (Neo4j, Infogrid 等)
数据逻辑模型（Logical Data Models）–Key-Value oriented (Voldemort, Dynomite 等), Column Familiy oriented (BigTable, HBase, Hypertable 等), Document oriented (Couch DB, MongoDB 等), Graph oriented (Neo4j, Infogrid 等)
数据分布模型(Data Distribution Model)–一致性与有效性(HBase, Hypertable, MongoDB等), 有效性与可分离性 (Cassandra等.). 当某些附属节点天然缺失一致性是，有效性与可分离性应当是以组合的形式出现。但有趣的是目前还有没有一款“Non Relational Database”产品支持这样的组合。
数据持久化(DataPersistence)-基于内存（Redis, Scalaris, Terrastore），基于磁盘（MongoDB, Riak等），基于两者的组合（HBase, Hypertable, Cassandra）。存储的类型很好的展示了其适用的解决方案。但在大部分情况中，人们都认为组合方式是最好的。为了高效率可以将数据存储在内存中，当写入到一定程度之后可以写入到磁盘中以保证其持久性。
如何适用与企业IT环境
在今天，企业并非所有的情景都直接使用关系型数据管理系统，他们也并不需要严格遵守ACID的原则（特别是一致性与隔离性）。已经不同于八九十年代，我们将数据保存在结构化有组织的数据库中，通过有控制的方式来生成和访问，在企业事务中以“记录” 的形式存在。不容置疑的，这样的数据在当前和以后都还将存在，并一直使用关系型数据管理系统进行建模、存储和访问。但是在最近15年来，在网页，电子商务，社交网络等方面爆炸式的出现了海量的非受控、非结构化、面向信息的数据我们该如何处理？企业不需要使用关系型数据管理系统来存储和查询这些数据，并且关系型数据管理系统的核心特征并不适用于这类数据。
上述的内容概括了在如今的以网页为中心的企业在信息管理中的新兴模式。“Non Relational Database”则是对应这种趋势的一个很好的选择（相对应关系型数据管理系统而言），能够提供对于非结构化数据的支持，通过分布实现水平扩展，高可用性支持等。
下面有一些使用环境的示例 –
日志挖掘 – 服务器日志，应用程序日志，用户活动日志会在一个集群中的多个节点生成。日志挖掘工具能够便利的访问多服务器的日志，关联并分析，从而解决产品问题。使用“Non Relational Database”能够很容易的建立个性化的解决方案。
社会调查 - 今日的很多企业提供用户（内部用户，客户，合作伙伴）通过信息论坛，博客等进行社会调查的服务。通过挖掘那些非结构化的数据，他们找到的最重要的就是日后能够用于提高自身服务的用户实际想法。“Non Relational Database”能够完美的实现这样的需求。
外部数据整合 – 很多情况下，企业需要处理一些来自合作伙伴的数据。显然，在多次讨论和谈判之后，企业能够在需要处理的数据结构上稍加控制。但很多情况下格式因为伙伴的业务变化的非常频繁。当在开发或定制一个ETL系统时，“Non Relational Database”也是很有帮助的。
海量企业应用集成 – 大部分企业的EAI系统数据流量都十分巨大（无论是产品还是定制开发）。出于对于可靠性和审查的目的，这些数据通常会被保存。“Non Relational Database”能够很好的适应这样基础数据存储的场景，了解目标和源的数据结构却不确定数据量。
前端订单处理系统 – 电子商务的爆炸式发展产生了海量的订单，应用，服务请求，通过不同的渠道给零售商，银行业，保险业，娱乐服务业，后勤保障带来了巨大的压力。并且，由于不同渠道的限制与行为模式的区别，信息传输在不同的情景中往往使用不同的格式与规则。并且，大部分请求数据不需要立即在终端处理并调整。真正需要的是无论合适用户希望将请求发送至世界任意地方，该请求都能被捕获并且不受到任何影响。稍后调节系统会将请求转发至实际终端系统，并更新用户端的定单状态。在这个场景中，“Non Relational Database”能够用于在开始存储用户端输入数据。这个场景在调节过程中完美的应用了“Non Relational Database”的海量数据，不同来源数据格式不限制，“最终一致”的可接受性的属性。
企业内容管理服务 – 在企业中，内容管理在不同的职能部门如销售、市场、零售、人力资源等都起到了不同的作用。大多数企业面临的挑战就是将不同部门不同元数据结构整合在一个通用的内容管理服务平台之上。“Non Relational Database”同样能够很好的解决这个问题。
合并与收购 – 企业在合并与收购时面临着巨大的挑战，他们需要强化系统以适应相同的功能。“Non Relational Database”同样能够用于解决该类问题，迅速整合一个临时通用数据存储，甚至是未来数据存储的架构，来适应合并公司目前已经存在的通用应用的结构。
但是我们如何来明确的表达使用“Non Relational Database”的好处远远超过了传统的关系型数据管理系统？根据一些“Non Relational Database”特性中的关键优势，通过企业IT决定的核心参数 – 缩减开支，周期缩短，优秀的质量。
商业灵活性 – 更短的周期
“Non Relational Database”能够从两个基础方面建立企业灵活性。
l 宽松的数据逻辑模型能够使得业务挑战在最快时间内完成，并且对现有应用和功能的影响降低到最小。大多数情况，你不需要为变更做任何工作。
l 内在的水平扩展的能力能够很好的支持越来越多的客户请求，可能是周期性的变化，或者是使用模式的突然变化。面向水平扩展的架构也是向以SLA为基础的建设（如云系统）的第一步，这样能够在本质上保证业务在不同应用场景中的连续性。
更好的用户满意度 – 优秀的质量
时至今日，企业的IT应用的质量评判标准主要还是用户的满意度。出现最频繁并难以把握的就是用户紧密关注的需求，“Non Relational Database”能够帮助你很好的定位它。
l “Non Relational Database”带来了大幅提高应用性能的机会。分布式数据的核心在于保证磁盘读写（检索速度）不在是应用性能的瓶颈所在。传输速度才是限制性能的主要因素。在此基础上，很多解决方案支持不同的新兴高效计算的算法，如MapReduce, Sorted Columns, Bloom Filter, Appended only BTree, Memtable等。
l 用户的满意度的另一个重要方面是针对有效性。用户希望能够随时访问应用，并在他任何有时间的时候执行工作。所以我们应当以任何代价来避免服务异常。大部分“Non Relational Database”都通过严格最终一致性来支持有效性的要求。
更加节省开支
现在的市场竞争中，企业IT的花费一直被严格的审查，使用适当的开支达到期望的质量就是真理。“Non Relational Database”跳出了传统数据库达到了一个更加大的范围，特别是针对需要保存和处理海量数据时。
l 以水平扩展为基本前提，使得它甚至能够运行在普通机器上。这项节省不光只是硬件，还包括操作支出，如电力、维护等。未来还可以使用下一代更低成本的基础架构如云，垂直数据中心等。
l 在长期运行中，可操作性会与可维护性成反比。当一个关系型数据管理系统存储了海量数据就是这样。将存储了海量数据的关系型数据管理系统调整的更加快速是一门艺术，并且需要特殊的技能，从而也增加了开支。与之相比“Non Relational Database”即便是在数据飞速增长的情况下，也能够提供快速的访问与响应。索引和缓存工作方式相同。开发者无需担心硬件，磁盘，索引重建，文件布局等。从而能够将时间使用在应用编程上。
企业进行建设时面临的挑战
抛开这些长期的好处，能够很好的建设“Non Relational Database”确实是对企业的一个挑战。
且不提高层因为固有观念和缺乏信心造成的阻力，还存在许多整体策略的挑战，如：
为“Non Relational Database”识别正确的应用场景
尽管从理论上来讲，并非所有的企业数据都需要一个基于关系型和ACID的数据系统，但是多年来企业与关系型数据库管理系统之间的捆绑使得数据向松散的非关系型数据库转换的决定变得异常艰难。很多时候IT经理（及其他层级对于应用有责任的人）对于将要失去的东西没有一个清晰的概念，这些顾虑使得他们无法抛弃关系型数据库管理系统。对于企业IT来讲数据是最重要的资产。所以做出使用一个没有那么清晰了解及广泛应用的解决方案的决定，不但需要不同的思维模式，还需要高层管理的支持。
我们如何挑选最适合我们的产品/解决方案
下一个挑战就是挑选一个合适的产品来提供“Non Relational Database”功能。前文有提到，目前有不同的4种规模超过25种产品。每种产品在4个方面都有不同的特点，所以通常很难找到一款能够正好满足我们所有需求的产品。有时甚至会需要在不同的企业群组中使用多种不同的非关系型数据库，使得最终人们为了统一标准重新转向了关系型数据库。
我们如何在规模节省成本
这个想法本质上起源与前面提到的。假如一个组织需要使用多个非关系型数据库方案，确保在技能（开发人员、管理员、支持人员）、基础设施（硬件、软件许可、支持、咨询）和组件（通用组件和服务）的规模方面的节省就是一个大问题。当组织以公开服务的模式运行他们的数据存储时，在这方面与传统关系型数据库管理系统进行比较就显得很有意义了。
我们如何保证方案的可移植性
我们有理由相信，在接下来的时间里，“Non Relational Database”领域将会在供应商整合、功能特性增强及标准化方面发生很多变化。所以企业的策略就是，不要将赌注全部压在某一个产品之上，从而今后还能够方便迁移到其他更好的产品上。在当前的非关系型产品的产品中，大部分是以专有方式在运行，专有性将是IT管理人员在“Non Relational Database”领域开始冒险前必须考虑的重要问题。为了保护他们的投资，这是完全必要的。
我们如何获得正确的产品支持
目前并没有多少“Non Relational Database”有着完善的技术支持。就算有，也无法与Oracle、IBM和微软等巨头相比。特别是在数据恢复、备份和数据修复方面，一直是企业管理人员思考的大问题，但大部分“Non Relational Database”方案都无法提供健壮简单的解决机制。
我们如何对全局花费进行预算
相对关系型数据库管理系统，“Non Relational Database”在性能与扩展性方面能够提供的数据很少。目前还没有如mini TPC（事务处理性能委员会Transaction Processing Performance Council）或相同相同地位的机构给出任何基准数据。这使得企业无从知晓他们将会需要在硬件、软件、基础设施及支持上投入多少。这是进行预算的一个阻碍因素。因此，很多时候我们选择关系型数据库管理系统是因为我们对它的了解。
有时尽管提供了有效的数据说明，但使用一个TCO模型来进行非关系型与关系型数据库的在全局花费的对比仍然是不够充分的。常常我们需要进行将硬件（包括软件与支持）的垂直扩展（硬件增强）与水平扩展的花费相比较能够让人们更加清晰，除非基于TCO模型的全局比较已经很有说服性了。
在如何建设方面的我的愚见
所以综上所述，企业是不是此时最好按兵不动，等着观察NoSQL的走势呢？也不是。企业对于“Non Relational Database”的建设目前确实处在开始阶段，但是“Non Relational Database”对于企业未来发展能够产生的潜力是绝对不该错过的。并且考虑到很快企业就将面对的是海量的半结构化或非结构化，并且仅要求最终一致性的数据，而不是少量的、紧凑结构化的、遵守ACID原则的数据。所以现在就开始培养核心关键人物的对于使用“Non Relational Database”处理数据的需求的想法。在此过程中，对企业的关键环节（技术、人员和过程）采用递增的方式转向“Non Relational Database”才是合理的。这样才能够慢却稳妥的完成我们之前识别出来的挑战。
采用一项产品/方案
在市场中对于“Non Relational Database”方案，不同规模不同方式的产品有很多。同时企业的应用场景可能需要多种不同的特性。但是针对不同的场景使用不同的方案对于对于企业规模预算的前景来说是不可行的。所以应当根据目标应用选择一个。大部分方案支持的功能，其他方案可能支持或未来打算支持。大部分的产品成熟后，能够通过配置来形成不同的解决方案。所以一旦一个方案满足了大部分需求，就可以将它作为开始的备选项了。
选择产品的建议：
l 仔细考察对于需求中的数据逻辑模型的支持。这基本从本质上决定了产品能否很好的适应现在及今后的业务需求。
l 调研产品能够支持的物理数据模型，以确认是否能够根据需求进行水平扩展，并保持有效性、一致性及可分离性。还有备份与恢复机制。
l 产品提供的接口必须与企业的标准操作环境保持一致。提供多种支持接口的产品更容易被处理。
l 产品提供了水平扩展之后，存储模型的选择就不是那么重要了
下面是一个“Non Relational Database”简短的比较列表。这些对于认真考虑建设的企业来说是一个很好的起点。为了对于企业显得更加合理，这个列表是从超过25个选择中精简而来，过来的标准主要如下：
1. 大部分的企业应用都必须能支持合理的复杂数据结构。不然应用程序则需要对复杂性管理担起巨大的责任。所以我认为这种结构应当在键值对存储和关系型结构之间。所以我去掉了Voldemort, Tokyo Cabinet等产品。
2. 必须能够以较低的代价来进行支持海量数据的水平扩展。若缺失这项则与任何关系型数据库管理系统无异了。因此我去除了Neo4J， Redis, CouchDB。
3. 在最后一个标准中，在应用于企业之前我比较关注是否有商业性的支持。否则产品出现问题时我该向谁求助。因此我去除了Cassandra（尽管很可能Rackspace及 Cloudera将会为其提供某些支持，而且他也再Twitter、Digg、Facebook中使用了）。
经过筛选之后保留了4款产品，MongoDB, Riak, Hypertable and HBase。下面的表格总结了4款产品的一些关键特性的对比。企业可以根据自身需求，选择最适用的产品。
| 功能特性 | MongoDB | Riak | HyperTable | HBase |
| 数据逻辑模型 | 支持嵌套文档的富文档模型 | 富文档 | 基于列 | 基于列 |
| CAP支持 | CA | AP | CA | CA |
| 动态增删节点 | 支持 | 支持 | 支持 | 支持 |
| 多数据中心支持（datacenter） | 支持 | 不支持 | 支持 | 支持 |
| 接口 | 多种语言自定接口(Java, Python, Perl, C# etc.) | JSON（ HTTP访问） | REST, Thrift, Java | C++, Thrift |
| 持久化模型 | 磁盘 | 磁盘 | 内存 + 磁盘 (可调整) | 内存 + 磁盘 (可调整) |
| 性能对比 | 不错(C++) | 很好 (Erlang) | 不错 (C++) | 还行 (Written in Java) |
| 商业支持 | 10gen.com | Basho Technologies | Hypertable Inc | Cloudera |
构建数据访问的抽象层
为“Non Relational Database”建立一个分离的抽象数据层是必须的。这样有多项优势。首先，开发者能够完全从底层细节中脱离出来。减少需要掌握的技能。也便于以后改变底层实现。并且能够将多个应用使用统一标准访问方式（如不包含Join和GroupBy等复杂功能的SQL）。
为性能与可扩展性建立模型
无论选择什么样的方案，使用统一的标准技术为性能与可扩展性建模是推荐的（如队列网络模型，分层队列网络等）。为基础服务规模与拓扑，以及软件许可管理等提供了必要的数据支持。这些都为预算提供了重要的数据，也能够帮助我们做出决定。
建立冗余服务器
为了防止数据丢失，从备份服务器上复制数据是唯一的途径。尽管很多“Non Relational Database”提供了自动复制，但还是存在主节点单点故障的可能性。所以最好准备一套备用备份的方案以及一系列脚本来支持数据恢复和自动修复。所以了解数据物理结构模型还是很有必要的，识别可能的恢复机制的备选方案，并且考察这些备选方案是否符合企业需求及实践。
建立公用数据服务平台
就像关系型数据库管理系统的公用服务，“Non Relational Database”的公用数据服务能够缩减基础设施和支持的开支。对于今后的升级或变更也更有利。这应当是我们能够达到成熟等级的中长期最终目标。总之，在开始就能有良好的全局远景视角能够帮助我们做出正确呃决定。
组织企业的力量
每个组织都有一些人对学习新的非传统的东西有热情。可以组建一个由挑选出来的人员组成的组织，负责了解领域内的动态、了解问题和挑战、关于下一代的考虑，能够为使用这些技术的项目提供方向。这样的组织也能够帮助管理层澄清事实，提供可信的数据。
发展产品社区
在选定一个产品之后，理应持续关注整个产品社区的关联发展以帮助相互发展。“Non Relational Database”大部分的社区都是很有活力的，大家都有互相帮助的热情。企业和社区之间的联系能够帮助大家达到一个双赢的局面。了解问题和解决方案对企业在某些特性或版本等作出决定有所帮助。企业能够通过某些特性影响产品的发展路径，就像一般的社区一样。另一方面，社区也能够了解产品真实的需求，从而使得产品更健壮并且功能丰富。大企业的成功经验能够使得他们在整个过程中保持领先。
进行迭代
考虑到“Non Relational Database”的成熟程度，应当采取相应的风险最小的迭代开发的方法。为“Non Relational Database”建立通用的标准数据访问抽象层并非一蹴而就的工作。迭代和重构是一个更好的工作方式。在使用这种未完全成熟的技术过程中，中途改变方案也是不常见的做法。以敏捷的视角来观察，能够帮助管理者及实现者建立修订的习惯。
要带着问题去进行迭代，制定一些用于决定的标准是非常重要的。比如，指导方针（及示例），应用的对象模型是适合关系型数据库还是非关系型，基础设施规模情况，必须遵守的测试用例清单等。
最后的注意点
企业建立“Non Relational Database”过程中，最大的挑战就是改变企业管理人员的思维模式 – 让他们相信并非所有数据/对象都适合于关系型数据管理系统。最好的方式就是展示当“Non Relational Database”正确使用时，它比关系型数据管理系统更加强大有效。选择一些“非业务核心”（但是可见的）并且能很好使用 “Non Relational Database”的项目。这些项目的成功（甚至失败）都能够改变现有的思维模式，并且能使得我们更好的建设“Non Relational Database”环境。在企业用“Non Relational Database”技术来改造他们的信息管理环境时，这些步骤都是必要的。
About the Author
Sourav Mazumder, currently works as Principal Technology Architect for Infosys Technologies Limited and has more than 14 years of experience in Information Technology domain. As a key member of Technology Consultancy group of Infosys, Sourav has worked for key clients of Infosys in USA, Europe, Australia and Japan in various domains like Insurance, Telecom, Banking, Retail, Security, Transport, and Architecture/Engineering/Construction industry. He was involved in Technical architecture and Roadmap defnition for Web Based applications, SoA strategy implementaion, Internationalization strategy definition, UI Componentization and Performance Modeling & Scalability Analysis, Unstructured Data management. Sourav's association with Infosys' own Core Banking product, Finacle, provided him with an extensive product development experience also. Sourav was also involved in developing reusable framework for J2EE applications in Infosys and defining Infosys' software engineering methodology for architecting and designing custom built applications. Sourav's experience also includes ensuring Architecture Compliance and Governance for development projects.
Sourav is an iCMG certified Software Architect as well as a TOGAF 8 certified practitioner. Sourav recently presented in Berkeley Globalization Conference of LISA. Sourav's latest white paper on SoA has become immensely popular among various reading communities.
Sourav's current interest area includes NoSQL, Web 2.0 Governance, Performance Modeling and Globalization.