NoSQL的必要性和效率、成本分析

NoSQL的必要性和效率、成本分析背景前段时间国内外对NoSQL的讨论非常热烈，Digg和Reddit使用Cassandra，Facebook经过一些变化后依然对NoSQL进行测评，NoSQL取代SQL的呼声高涨，因为互联网行业使用MySQL的概率非常高，加之Oracle收购的消息，一时间似乎MySQL将成为NoSQL数据库的牺牲品，一场轰轰烈烈的技术革命就要到来了。之所以有如此动向是因为基于MySQL+sharding+cache的构架随着数据量爆炸式增长，重构的人力成本太高，换用扩展性更好的NoSQL数据库，以达到控制人力成本的目的，从而减少总体成本。几个月过去了，NoSQL并没有像大家所想象的那样席卷全球，很多人设想中的MySQL与NoSQL的战争也仅存于设想中，国内不要说使用了，测评NoSQL的机构也是寥寥，究其原因，笔者认为：MySQL与NoSQL是两种不通性质的技术，它们代表的是两种完全不通的技术思想，均有其适应的土壤，究竟孰优孰劣，取决于诸多因素，而它们是否适用的根本因素，是“人”与“物”的成本变化。什么是NoSQL在“NoSQL”一词，实际上是一个叫Racker的人创造的，当约翰埃文斯埃里克要组织一次活动来讨论开源的分布式数据库。这个名称和概念都由此而来。有些人反对NoSQL术语，因为它听起来像我们定义自己是什么.在一定程度，但长期仍然是有价值的，因为当一个关系数据库是唯一的工具，你知道，每一个问题，看起来像一个大拇指。NoSQL是让人们知道有其他选择哪里。但我们并不反对关系数据库，因为当这确实是工作的最佳工具.一个与NoSQL名称真正关注的是，它是一个很大的帐篷，有非常不同的设计空间。如果这不是在讨论清楚的，它在各种产品混乱的结果。因此，我要建议沿着三个轴的思考很多数据库选项：可扩展性，数据和查询模型和持久性的设计。前所未有的数据量正推动企业关注传统的关系数据库技术，已服务了30多年良好替代品。总的来说，这些替代品已被称作“NoSQL数据库。”最根本的问题是关系数据库不能处理很多数据量。有三个具体的问题：扩大向像Digg新闻评论网站的(3TB绿色徽章)或Facebook的(50TB收件箱中的搜索)或EBay(整体2PB)，并支持每个服务器性能和严格的架构设计。像许多关注这一领域的人一样，我不喜欢从本质上将SQL与NoSQL这一术语对立起来。同时我对该术语现有的解释”NotOnlySQL”也不甚满意。对我来说，我们这里所讨论的并非是是否使用SQL。(相反的是，我们仍然可以选择类似SQL这样的查询接口(缺少对join等的支持)来与这些数据库交互，使用现有的资源和技术来管理开发伸缩性和可维护性。)这一运动是要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油。因此，我认为’NonRelationalDatabase’(非关系型数据库)能够更好的表达这一思想。无论采用哪个名字，“非关系型数据库”这一范围所传达出来的“囊括所有”类型的意味，使得这一概念比较模糊(并且它还是否定型的)。这又使得人们(特别是企业中的决策者)对于哪些是属于这个范围，哪些不是，更重要的是，对他们来说这到底意味着什么，感到非常迷惑。为了解答这些疑问，我尝试通过以下几点特征的描述，来刻画“非关系型数据库”的内在本质。所谓“非关系型数据库”指的是使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模(Map，列，文档，图表等)，而不是使用固定的关系模式元组来构建数据模型。以遵循于CAP定理(能保证在一致性，可用性和分区容忍性三者中中达到任意两个)的跨多节点数据分布模型而设计，支持水平伸缩。这意味着对于多数据中心和动态供应(在生产集群中透明地加入/删除节点)的必要支持，也即弹性(Elasticity)。拥有在磁盘或内存中，或者在这两者中都有的，对数据持久化的能力，有时候还可以使用可热插拔的定制存储。支持多种的’Non-SQL’接口(通常多于一种)来进行数据访问。围绕着图中四个特征的(数据持久性、逻辑数据模型、数据分布模型和接口)“非关系型数据库”的各种变形，在最近的一些文章中有详尽的描述，并且在因特网上有着广泛的传播。所以我就不做过多繁复的描述，而是通过一些例子对关键的方向进行总结，供快速参考：接口——REST(HBase，CouchDB，Riak等)，MapReduce(HBase，CouchDB，MongoDB，Hypertable等)，Get/Put(Voldemort，Scalaris等)，Thrift(HBase，Hypertable，Cassandra等)，语言特定的API(MongoDB)。逻辑数据模型——面向键值对的(Voldemort，Dynomite等)，面向ColumnFamily的(BigTable，HBase，Hypertable等)，面向文档的(CouchDB，MongoDB等)，面向图的(Neo4j，Infogrid等)数据分布模型——一致性和可用性(HBase，Hypertable，MongoDB等)，可用性和可分区性(Cassandra等)。一致性和可分区性的组合会导致一些非额定的节点产生可用性的损失。有趣的是目前还没有一个“非关系型数据库”支持这一组合。数据持久性——基于内存的(如Redis，Scalaris，Terrastore)，基于磁盘的(如MongoDB，Riak等)，或内存及磁盘二者的结合(如HBase，Hypertable，Cassandra)。存储的类型有助于我们辨别该解决方案适用于哪种类型。然而，在大多数情况下人们发现基于组合方案的解决方案是最佳的选择。既能通过内存数据存储支持高性能，又能在写入足够多的数据后存储到磁盘来保证持续性。随着网站的持续发展，NOSQL成为大网站发展的必然性选择随着数据量和访问量的增长，网站构架大致有这么几个发展阶段(以PHP+MySQL+Memcached为例)：1:PHP+MySQL2:PHP+MySQL(Master+Slaves)3:PHP+MySQL(Master+Slaves)+Memcached(Middleware)4:PHP+MySQL(Sharding+Master+Slaves)+Memcached(Middleware)5:PHP+MySQL(Sharding+Master+Slaves)+Memcached(Middleware)+NoSQL从上面的发展历程可以看出，随着复杂度的增加，开发难度和复杂性也随之提升，数据量增加之后每次重构需要的人力成本急剧增加，因此为了控制成本，增长重构的周期，将一些数据量庞大，增长快速的业务迁移至NoSQL上存储。因此大家不必要言必NoSQL，NoSQL也不会取代MySQL，不同的业务有它最适合的低成本存储方式，最终选择什么数据库是由系统成本决定的。MySQL的优势在此不再赘述，其最大的特点是尽可能的压榨机器的性能，在上世纪末互联网泡沫破灭时，压缩成本的意识就已经深入每一个互联网公司的血液，MySQL顺应时代的需求，为幸存的互联网公司尽可能的节约着每一分资金，不知有多少互联网故事都有以下的开头“XX年，几个刚毕业的大学生用两台服务器创办了XXX”，那时，无论是在美国，还是在中国，硬件的成本相比人力资源，都是比较高的，特别是在中国，一台中等配置服务器的价格，几乎相当于一个技术新手一年甚至更多的薪水。虽然SQL型数据库在扩展的时候有诸多不便，业务重构、代码重写、压力测试、上线，意味着网站开发、运维人员无数个不眠之夜，但人力成本较之买服务器的成本来说，可能当时绝大部分互联网公司都会选择前者。再看十几年后的今天，网站的数据量比过去更大，用户更多，应用更复杂，业务的变化更加快速，人力资源的成本不断上涨，即便是金融危机之后的美国，一个普通MySQLDBA的工资依然在十几万美元以上，至于高级开发，架构师的成本更是以数十万美元计，而硬件的成本却大大降低，NoSQL虽然在执行效率上远低于SQL型数据库，但其扩展的便利性导致不需要投入更多的人力来对系统和应用进行重构与改写，间接的降低了人员的成本，对于许多已经有成百上千台服务器和上百万用户的美国互联网公司来说，节约下的人力成本，足够买上百台服务器来弥补NoSQL效率上的缺陷，这样的好事，当然许多公司都是希望进行尝试的。如何将其与企业IT融合如今的企业中，并非所有用例都直观地倾向于使用关系型数据库，或者都需要严格的ACID属性(特别是一致性和隔离性)。在80年代及90年代，绝大部分存储在企业数据库里的数据都是结构化的业务事务的“记录”，必须用受控的方式来生成或访问，而如今它已一去不复返了。无可争辩的是，仍有这一类型的数据在那里，并将继续也应该通过关系型数据库来建模，存储和访问。但对于过去15年以来，随着Web的发展，电子商务和社交计算的兴起所引起的企业里不受控的非结构化并且面向信息的数据大爆炸，该如何应对呢?企业确实不需要关系型数据库来管理这些数据，因为关系型数据库的特点决定了它不适用于这些数据的性质和使用方式。上图总结了现今以web为中心的企业中信息管理的新兴模式。而“非关系型数据库”是处理这些趋势的最佳选择(较之关系型数据库来说)，提供了对非结构化数据的支持，拥有支持分区的水平伸缩性，支持高可用性等等。以下是支持这一观点的一些实际应用场景：日志挖掘——集群里的多个节点都会产生服务器日志、应用程序日志和用户活动日志等。对于解决生产环境中的问题，日志挖掘工具非常有用，它能访问跨服务器的日志记录，将它们关联起来并进行分析。使用“非关系型数据库”来定制这样的解决方案将会非常容易。分析社交计算——许多企业如今都为用户(内部用户、客户和合作伙伴)提供通过消息论坛，博客等方式来进行社交计算的能力。挖掘这些非结构化的数据对于获得用户的喜好偏向以及进一步提升服务有着至关重要的作用。使用“非关系型数据库”可以很好的解决这一需求。外部数据feed聚合——许多情况下企业需要消费来自合作伙伴的数据。显然，就算经过了多轮的讨论和协商，企业对于来自合作伙伴的数据的格式仍然没有发言权。同时，许多情况下，基于合作伙伴业务的变更，这些数据格式也频繁的发生变化。通过“非关系型数据库”来开发或定制一个ETL解决方案能够非常成功的解决这一问题。高容量的EAI系统——许多企业的EAI系统都有高容量传输流(不管是基于产品的还是定制开发的)。出于可靠性和审计的目的，这些通过EAI系统的消息流通常都需要持久化。对于这一场景，“非关系型数据库”再次体现出它十分适用于底层的数据存储，只要能给定环境中源系统和目标系统的数据结构更改和所需的容量。前端订单处理系统——随着电子商务的膨胀，通过不同渠道流经零售商、银行和保险供应商、娱乐服务供应商、物流供应商等等的订单、应用、服务请求的容量十分巨大。同时，由于不同渠道的所关联的行为模式的限制，每种情况下系统所使用的信息结构都有所差异，需要加上不同的规则类型。在此之上，绝大部分数据不需要即时的处理和后端对帐。所需要的是，当终端用户想要从任何地方推送这些数据时，这些请求都能够被捕获并且不会被打断。随后，通常会有一个对帐系统将其更新到真正的后端源系统并更新终端用户的订单状态。这又是一个可以应用“非关系型数据库”的场景，可用于初期存储终端用户的输入。这一场景是体现“非关系型数据库”的应用的极佳例子，它具有高容量，异构的输入数据类型和对帐的”最终一致性”等等特点。企业内容管理服务——出于各种各样的目的，内容管理在企业内部得到了广泛的应用，横跨多个不同的功能部门比如销售、市场、零售和人力资源等。企业大多数时间所面临的挑战是用一个公共的内容管理服务平台，将不同部门的需求整合到一起，而它们的元数据是各不相同的。这又是“非关系型数据库”发挥作用的地方。合并和收购——企业在合并与收购中面临巨大的挑战，因为他们需要将适应于相同功能的系统整合起来。“非关系型数据库”可解决这一问题，不管是快速地组成一个临时的公共数据存储，或者是架构一个未来的数据存储来调和合并的公司之间现有公共