nosql最佳实战,nosql应用实例

newsql和nosql的区别和联系

在大数据时代,“多种架构支持多类应用”成为数据库行业应对大数据的基本思路,数据库行业出现互为补充的三大阵营,适用于事务处理应用的OldSQL、适用于数据分析应用的NewSQL和适用于互联网应用的NoSQL。但在一些复杂的应用场景中,单一数据库架构都不能完全满足应用场景对海量结构化和非结构化数据的存储管理、复杂分析、关联查询、实时性处理和控制建设成本等多方面的需要,因此不同架构数据库混合部署应用成为满足复杂应用的必然选择。不同架构数据库混合使用的模式可以概括为:OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三种主要模式。下面通过三个案例对不同架构数据库的混合应用部署进行介绍。

公司主营业务:成都网站制作、网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联公司推出颍上免费做网站回馈大家。

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开源方案。

NoSQL会取代完全取代关系型数据库吗?

对此,前Google工程师,Milo(本地商店搜索引擎)创始人Ted Dziuba最近发表标题惊人的博客“I Can't Wait for NoSQL to Die”,对NoSQL的适用范围进行了分析。他认为, NoSQL也会带来一连串的新问题,并不会成为主流,无法取代关系型数据库。 他的理由是:Cassandra等NoSQL数据库在使用上并不方便,比如,修改column family定义时就需要重启。而且NoSQL更适合Google那样的规模,而一般的互联网公司都不是Google,早早地去考虑Google那样的规模的可扩展性,纯粹是浪费时间,存在巨大的商业风险。 他还透露,即使在Google,AdWords这样的关键产品也是基于MySQL实现的。 他在文中最后表示,NoSQL当然死不了,但是 它最终会被边缘化,就像Rails被NoSQL边缘化一样 Dziuba的文章因为言辞激烈,在社区里引起了强烈反应。 SQL数据库阵营赞同者大有人在。craigslist工程师、著名的MySQL专家Jeremy Zawodny表示,在读此文的时候,不时会心一笑。他说, NoSQL运动只是软件不断进化进程中的正常现象 。关系型数据库也会继续发展,MySQL社区不断推出的XtraDB或InnoDB插件, PBXT, Drizzle都是证据。各种技术竞争的结果是,我们获得了更多解决问题的选择。 drizzle项目开发者Eric Day也表示,NoSQL有很多值得学习的,但是目前大部分实际项目的最佳选择还是关系型数据库。 NoSQL阵营当然不会坐视不理,Cassandra项目组的Eric Evans表示,Dziuba提到Cassandra修改column family定义的问题其实很容易解决。而且,NoSQL并不是要取代MySQL,事实上Twitter仍然在用MySQL。如果关系型数据库能够承担负荷,那就用好了;如果不行,请考虑NoSQL。 而德国知名博客Code Monkeyism则嘲笑Dziuba看起来并没有用MySQL做过真实项目,因为MySQL如果没有memcache,基本上无法应付网站项目。他认为,NoSQL将使SQL数据库边缘化,而且一个重要理由恰恰是可以节省DBA的开销。 digg的前任首席架构师现在也在创业的Joe Stump说,自己现在的创业项目就是用NoSQL,而且列举了一系列问题挑战SQL阵营。

学途无忧 redis3+spring分布式nosql实战 怎么样

还行,刚起步的网站,课程都是最新的,目前主打课程有scala、sorl、C++、物联网和Java课程


新闻名称:nosql最佳实战,nosql应用实例
文章网址:http://myzitong.com/article/hoosjj.html