在大数据时代，“多种架构支持多类应用”成为数据库行业应对大数据的基本思路，数据库行业出现互为补充的三大阵营，适用于事务处理应用的OldSQL、适用于数据分析应用的NewSQL和适用于互联网应用的NoSQL。但在一些复杂的应用场景中，单一数据库架构都不能完全满足应用场景对海量结构化和非结构化数据的存储管理、复杂分析、关联查询、实时性处理和控制建设成本等多方面的需要，因此不同架构数据库混合部署应用成为满足复杂应用的必然选择。不同架构数据库混合使用的模式可以概括为：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三种主要模式。下面通过三个案例对不同架构数据库的混合应用部署进行介绍。
创新互联来电联系：18980820575，为您提供成都网站建设网页设计及定制高端网站建设服务，创新互联网页制作领域10多年，包括搬家公司等多个方面拥有丰富建站经验，选择创新互联，为企业保驾护航！
OldSQL+NewSQL 在数据中心类应用中混合部署
采用OldSQL+NewSQL模式构建数据中心，在充分发挥OldSQL数据库的事务处理能力的同时，借助NewSQL在实时性、复杂分析、即席查询等方面的独特优势，以及面对海量数据时较强的扩展能力，满足数据中心对当前“热”数据事务型处理和海量历史“冷”数据分析两方面的需求。OldSQL+NewSQL模式在数据中心类应用中的互补作用体现在，OldSQL弥补了NewSQL不适合事务处理的不足，NewSQL弥补了OldSQL在海量数据存储能力和处理性能方面的缺陷。
商业银行数据中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL数据库满足各业务系统数据的归档备份和事务型应用，NewSQL MPP数据库集群对即席查询、多维分析等应用提供高性能支持，并且通过MPP集群架构实现应对海量数据存储的扩展能力。
商业银行数据中心存储架构
与传统的OldSQL模式相比，商业银行数据中心采用OldSQL+NewSQL混合搭建模式，数据加载性能提升3倍以上，即席查询和统计分析性能提升6倍以上。NewSQL MPP的高可扩展性能够应对新的业务需求，可随着数据量的增长采用集群方式构建存储容量更大的数据中心。
OldSQL+NoSQL 在互联网大数据应用中混合部署
在互联网大数据应用中采用OldSQL+NoSQL混合模式，能够很好的解决互联网大数据应用对海量结构化和非结构化数据进行存储和快速处理的需求。在诸如大型电子商务平台、大型SNS平台等互联网大数据应用场景中，OldSQL在应用中负责高价值密度结构化数据的存储和事务型处理，NoSQL在应用中负责存储和处理海量非结构化的数据和低价值密度结构化数据。OldSQL+NoSQL模式在互联网大数据应用中的互补作用体现在，OldSQL弥补了NoSQL在ACID特性和复杂关联运算方面的不足，NoSQL弥补了OldSQL在海量数据存储和非结构化数据处理方面的缺陷。
数据魔方是淘宝网的一款数据产品，主要提供行业数据分析、店铺数据分析。淘宝数据产品在存储层采用OldSQL+NoSQL混合模式，由基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom组成。由于OldSQL强大的语义和关系表达能力，在应用中仍然占据着重要地位，目前存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上。另一方面，NoSQL作为SQL的有益补充，解决了OldSQL数据库无法解决的全属性选择器等问题。
淘宝海量数据产品技术架构
基于OldSQL+NoSQL混合架构的特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，支持每天4000万的查询请求，平均响应时间在28毫秒，足以满足未来一段时间内的业务增长需求。
NewSQL+NoSQL 在行业大数据应用中混合部署
行业大数据与互联网大数据的区别在于行业大数据的价值密度更高，并且对结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等都比互联网大数据有更高的要求。行业大数据应用场景主要是分析类应用，如：电信、金融、政务、能源等行业的决策辅助、预测预警、统计分析、经营分析等。
在行业大数据应用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在结构化数据分析处理方面的优势，以及NoSQL在非结构数据处理方面的优势，实现NewSQL与NoSQL的功能互补，解决行业大数据应用对高价值结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等要求，以及对海量非结构化数据存储和精确查询的要求。在应用中，NewSQL承担高价值密度结构化数据的存储和分析处理工作，NoSQL承担存储和处理海量非结构化数据和不需要关联分析、Ad-hoc查询较少的低价值密度结构化数据的工作。
当前电信运营商在集中化BI系统建设过程中面临着数据规模大、数据处理类型多等问题，并且需要应对大量的固定应用，以及占统计总数80%以上的突发性临时统计(ad-hoc)需求。在集中化BI系统的建设中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在复杂分析、即席查询等方面处理性能的优势，及NoSQL在非结构化数据处理和海量数据存储方面的优势，实现高效低成本。
集中化BI系统数据存储架构
集中化BI系统按照数据类型和处理方式的不同，将结构化数据和非结构化数据分别存储在不同的系统中：非结构化数据在Hadoop平台上存储与处理;结构化、不需要关联分析、Ad-hoc查询较少的数据保存在NoSQL数据库或Hadoop平台;结构化、需要关联分析或经常ad-hoc查询的数据，保存在NewSQL MPP数据库中，短期高价值数据放在高性能平台，中长期放在低成本产品中。
结语
当前信息化应用的多样性、复杂性，以及三种数据库架构各自所具有的优势和局限性，造成任何一种架构的数据库都不能完全满足应用需求，因此不同架构数据库混合使用，从而弥补其他架构的不足成为必然选择。根据应用场景采用不同架构数据库进行组合搭配，充分发挥每种架构数据库的特点和优势，并且与其他架构数据库形成互补，完全涵盖应用需求，保证数据资源的最优化利用，将成为未来一段时期内信息化应用主要采用的解决方式。
目前在国内市场上，OldSQL主要为Oracle、IBM等国外数据库厂商所垄断，达梦、金仓等国产厂商仍处于追赶状态;南大通用凭借国产新型数据库GBase 8a异军突起，与EMC的Greenplum和HP的Vertica跻身NewSQL市场三强;NoSQL方面用户则大多采用Hadoop开源方案。
数据库一体机与大数据技术区别何在
作为近期信息管理领域最为热门的两项技术，数据库一体机与大数据技术的硬件架构基本相同，但软件体系有着本质的区别，这也导致了两者拥有不同的特征表现。
随着企业数据量的快速增长，以及用户对服务水平要求的不断提高，相当长的一段时间以来，传统关系数据库技术在生产实践中表现出明显的能力不足。如何以合理的成本获得海量数据的高可用性已经成为现代IT领域的重大挑战。为了应对这一挑战，近年来，IT市场中相继出现了许多新的技术手段，其中最为引人注目的便是由主流数据库厂商主导的数据库一体机（例如Oracle ExaData以及IBM Netezza等），以及以开源力量为主的大数据技术。
不过，虽然数据库一体机与大数据技术都是当今的热门话题，并都已经被广泛应用，但却有相当一部分用户仍然无法深入了解两者之间的本质区别与关系。同时，很多用户也在为如何在企业内部对这两者进行正确定位而感到困惑。为此，本文特别对数据库一体机（也可称新一代主流关系型数据库）和大数据技术（例如Hadoop，主要指MapReduce与NoSQL）的相关技术特点进行对比。
硬件与软件
从本质上来讲，数据库一体机与大数据技术的硬件架构基本相同，同样是采用x86服务器集群的分布式并行模式，以应对大规模的数据与计算。但是，数据库一体机的卖家们通常会对其产品的硬件体系进行面向产品化的、系统性的整体调优，同时也会有各自的特色手段。比方说Oracle ExaData的Infiniband、Flash Cache，IBM Nettezza的FPGA（现场可编程逻辑门阵）等。[page] 数据库一体机与大数据技术最为核心的区别是在软件体系上。数据库一体机的核心是SQL体系，这不只是指SQL解析，更重要的是指包括SQL优化引擎、索引、锁、事务、日志、安全以及管理等在内的完整而庞大的技术体系。这一体系是成熟的、面向产品的。
大数据技术软件体系中的MapReduce则提供了一个面向海量数据处理的分布式编程框架，使用者需要自行编制所需要的计算逻辑。MapReduce对数据的读写是批量连续的，而不是随机的。而大数据技术的另一体系NoSQL则大都只是提供了海量数据的分布式存储，以及基于索引的快速读取机制，为使用者提供的大多是编程API（虽然也有类SQL的语言，但其本质并不是完整的SQL体系）。
由于SQL体系的复杂性与处理逻辑的整体关联性，导致数据库一体机在扩展性上远不及大数据技术体系，虽然前者已经在很大程度上改善了传统关系数据库垂直扩展的瓶颈。MapReduce与NoSQL的单个集群往往可以扩展到数千个节点，而数据库一体机如果在硬件上扩展到这个规模，从软件上来讲，已经是没有意义的了。
特征与本质
基于软件体系的不同，导致了数据库一体机和大数据技术有着不同的特征表现。数据库一体机往往适合于存储关系复杂的数据模型（例如企业核心业务数据），并且需要限制为基于二维表的关系模型。同时，数据库一体机适合进行一致性与事务性要求高的计算，以及复杂的BI计算。
大数据技术则更适合于存储较简单的数据模型，并且可以不受模式的约束。因而其可存储管理的数据类型更加丰富。大数据技术还适合进行一致性与事务性要求不高的计算（主要是指NoSQL的查询操作），以及对超大规模海量数据的、批量的分布式并行计算（基于MapReduce）。
需要注意的是，NoSQL数据库由于摆脱了繁琐的SQL体系约束，其查询与插入的效率比数据库一体机更高。大数据技术比数据库一体机所能处理的数据量也相对大些，这主要是因为其集群可以扩展得更大。
从本质上讲，MapReduce是对海量数据分布式计算领域的一个重要创新，但也只是在适合于并行处理的大规模批量处理问题上更占优势，而对一些复杂操作，则不一定具有优势。NoSQL则可以看作是对传统关系数据库进行简化的结果。由于NoSQL数据库的设计思想只是提取出关系型数据库的索引机制，并加了上分布式存储，把SQL体系中那些对“某些特殊问题”而言并不需要的东西统统删去，由此实现了更优秀的效率、扩展性与灵活性。[page] 因此，我们可以明显地看到，在实践中，有很多问题（特别是流行的大数据问题），关系数据库中的许多设计并不需要，这才是NoSQL发展壮大的根本立足点。
关系与协作
通过前面的分析，我们不难得出这样的结论：大数据技术与数据库一体机应该是相辅相成，并非互相替代的。它们针对不同的应用场景设计，并相互补充与合作。具体来说，大数据技术可以实现：
■处理企业内海量的、模型简单、类型多样的非结构化与半结构化数据（例如社会化数据、各种日志甚至图片、视频等），其处理结果可以被直接使用；
■以上处理结果也同时可以被当成是新的输入存储到企业级数据仓库中，这时大数据机相当于是面向大数据源的、新的ETL（提取-转换-加载）手段；
■面向海量数据的、不太适合SQL的存储或计算。
而数据库一体机则应该还是作为企业数据仓库的主流技术，至少在很长一段时间内应该是这样。它负责存储与计算最主要的、有重大价值的企业关键业务数据。
现存的误区
有些人认为，虽然大数据技术的原始开源状态还不适合充当企业级数据仓库主平台的要求，但经过开发、补充，应该是可以的。其实这个观点没有错。但实际上，对开源的大数据技术进行补充开发，所要补充的正是大数据技术在原始设计上就去除了的、那些本属于关系型数据库体系的东西。
如果进行这样的补充开发，企业不仅会面临庞大的、难于估计的开发工作量，同时也难以像专业数据库厂商那样实现这些工作的理论化、产品化与体系化。虽然从纯技术的角度上讲，开发什么都有可能。但是如果企业真的准备这样做，是要开发另一个商业化的关系数据库吗？很明显，这违背了大数据技术的设计初衷。
而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。
Nosql全称是Not Only SQL，是一种不同于关系型数据库的数据库管理系统设计方式。对NoSQL最普遍的解释是“非关系型的”，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS
NewSQL是对一类现代关系型数据库的统称，这类数据库对于一般的OLTP读写请求提供可横向扩展的性能，同时支持事务的ACID保证。这些系统既拥有NoSQL数据库的扩展性，又保持传统数据库的事务特性。NewSQL重新将“应用程序逻辑与数据操作逻辑应该分离”的理念带回到现代数据库的世界，这也验证了历史的发展总是呈现出螺旋上升的形式。
在21世纪00年代中，出现了许多数据仓库系统 (如 Vertica，Greeplum 和AsterData)，这些以处理OLAP 请求为设计目标的系统并不在本文定义的NewSQL范围内。OLAP 数据库更关注针对海量数据的大型、复杂、只读的查询，查询时间可能持续秒级、分钟级甚至更长。
NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型，因此NoSQL运动的核心就是放弃事务强一致性以及关系模型，拥抱最终一致性和其它数据模型 (如 key/value，graphs 和Documents)。
两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo，由于二者都未开源，其它组织就开始推出类似的开源替代项目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些创业公司也加入到这场NoSQL运动中，它们不一定是受BigTable和Dynamo的启发，但都响应了NoSQL的哲学，其中最出名的就是MongoDB。
在21世纪00年代末，市面上已经有许多供用户选择的分布式数据库产品。使用NoSQL的优势在于应用开发者可以更关注应用逻辑本身，而非数据库的扩展性问题；但与此同时许多应用，如金融系统、订单处理系统，由于无法放弃事务的一致性要求被拒之门外。
一些组织，如Google，已经发现他们的许多工程师将过多的精力放在处理数据一致性上，这既暴露了数据库的抽象、又提高了代码的复杂度，这时候要么选择回到传统DBMS时代，用更高的机器配置纵向扩容，要么选择回到中间件时代，开发支持分布式事务的中间件。这两种方案成本都很高，于是NewSQL运动开始酝酿。
NewSQL数据库设计针对的读写事务有以下特点：
1、耗时短。
2、使用索引查询，涉及少量数据。
3、重复度高，通常使用相同的查询语句和不同的查询参考。
也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库。所有我们认为是NewSQL的数据库系统确实都有这样的特点。