这次的NoSQL专栏系列将先整体介绍NoSQL,然后介绍如何把NoSQL运用到自己的项目中合适的场景中,还会适当地分析一些成功案例,希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。
在网站制作、成都网站设计过程中,需要针对客户的行业特点、产品特性、目标受众和市场情况进行定位分析,以确定网站的风格、色彩、版式、交互等方面的设计方向。创新互联还需要根据客户的需求进行功能模块的开发和设计,包括内容管理、前台展示、用户权限管理、数据统计和安全保护等功能。
NoSQL概念随着web2.0的快速发展,非关系型、分布式数据存储得到了快速的发展,它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”,“Not Only SQL”也被很多人接受。(“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。)
NoSQL被我们用得最多的当数key-value存储,当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前,这些数据库就被用于各种系统当中,但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能,高稳定型,久经历史考验,而且使用简单,功能强大,同时也积累了大量的成功案例。在互联网领域,MySQL成为了绝对靠前的王者,毫不夸张的说,MySQL为互联网的发展做出了卓越的贡献。
在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。在那个时候,更多的都是静态网页,动态交互类型的网站不多。
到了最近10年,网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期,论坛的流量其实也不大,如果你接触网络比较早,你可能还记得那个时候还有文本型存储的论坛程序,可以想象一般的论坛的流量有多大。
Memcached+MySQL
后来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached就自然的成为一个非常时尚的技术产品。
Memcached作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时,如果你去面试,你说你有Memcached经验,肯定会加分的。
Mysql主从读写分离
由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
分表分库随着web2.0的继续高速发展,在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候,MySQL推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群,但是由于在互联网几乎没有成功案例,性能也不能满足互联网的要求,只是在高可靠性上提供了非常大的保证。
MySQL的扩展性瓶颈
在互联网,大部分的MySQL都应该是IO密集型的,事实上,如果你的MySQL是个CPU密集型的话,那么很可能你的MySQL设计得有性能问题,需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂,也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性,但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更,可能又需要一种新的分库方式。
MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。
关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。
NOSQL的优势易扩展NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
大数据量,高性能
NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。
总结NoSQL数据库的出现,弥补了关系数据(比如MySQL)在某些方面的不足,在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。
而传统的关系数据库在应付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,也得到了广泛认同。
特点:
它们可以处理超大量的数据。
它们运行在便宜的PC服务器集群上。
PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
它们击碎了性能瓶颈。
NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。
“SQL并非适用于所有的程序代码,” 对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。
没有过多的操作。
虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,他们同时也表示,企业的具体需求可能没有那么多。
Bootstrap支持
因为NoSQL项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持。
优点:
易扩展
NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
大数据量,高性能
NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的 Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用
NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。
主要应用:
Apache HBase
这个大数据管理平台建立在谷歌强大的BigTable管理引擎基础上。作为具有开源、Java编码、分布式多个优势的数据库,Hbase最初被设计应用于Hadoop平台,而这一强大的数据管理工具,也被Facebook采用,用于管理消息平台的庞大数据。
Apache Storm
用于处理高速、大型数据流的分布式实时计算系统。Storm为Apache Hadoop添加了可靠的实时数据处理功能,同时还增加了低延迟的仪表板、安全警报,改进了原有的操作方式,帮助企业更有效率地捕获商业机会、发展新业务。
Apache Spark
该技术采用内存计算,从多迭代批量处理出发,允许将数据载入内存做反复查询,此外还融合数据仓库、流处理和图计算等多种计算范式,Spark用Scala语言实现,构建在HDFS上,能与Hadoop很好的结合,而且运行速度比MapReduce快100倍。
Apache Hadoop
该技术迅速成为了大数据管理标准之一。当它被用来管理大型数据集时,对于复杂的分布式应用,Hadoop体现出了非常好的性能,平台的灵活性使它可以运行在商用硬件系统,它还可以轻松地集成结构化、半结构化和甚至非结构化数据集。
Apache Drill
你有多大的数据集?其实无论你有多大的数据集,Drill都能轻松应对。通过支持HBase、Cassandra和MongoDB,Drill建立了交互式分析平台,允许大规模数据吞吐,而且能很快得出结果。
Apache Sqoop
也许你的数据现在还被锁定于旧系统中,Sqoop可以帮你解决这个问题。这一平台采用并发连接,可以将数据从关系数据库系统方便地转移到Hadoop中,可以自定义数据类型以及元数据传播的映射。事实上,你还可以将数据(如新的数据)导入到HDFS、Hive和Hbase中。
Apache Giraph
这是功能强大的图形处理平台,具有很好可扩展性和可用性。该技术已经被Facebook采用,Giraph可以运行在Hadoop环境中,可以将它直接部署到现有的Hadoop系统中。通过这种方式,你可以得到强大的分布式作图能力,同时还能利用上现有的大数据处理引擎。
Cloudera Impala
Impala模型也可以部署在你现有的Hadoop群集上,监视所有的查询。该技术和MapReduce一样,具有强大的批处理能力,而且Impala对于实时的SQL查询也有很好的效果,通过高效的SQL查询,你可以很快的了解到大数据平台上的数据。
Gephi
它可以用来对信息进行关联和量化处理,通过为数据创建功能强大的可视化效果,你可以从数据中得到不一样的洞察力。Gephi已经支持多个图表类型,而且可以在具有上百万个节点的大型网络上运行。Gephi具有活跃的用户社区,Gephi还提供了大量的插件,可以和现有系统完美的集成到一起,它还可以对复杂的IT连接、分布式系统中各个节点、数据流等信息进行可视化分析。
MongoDB
这个坚实的平台一直被很多组织推崇,它在大数据管理上有极好的性能。MongoDB最初是由DoubleClick公司的员工创建,现在该技术已经被广泛的应用于大数据管理。MongoDB是一个应用开源技术开发的NoSQL数据库,可以用于在JSON这样的平台上存储和处理数据。目前,纽约时报、Craigslist以及众多企业都采用了MongoDB,帮助他们管理大型数据集。(Couchbase服务器也作为一个参考)。
十大顶尖公司:
Amazon Web Services
Forrester将AWS称为“云霸主”,谈到云计算领域的大数据,那就不得不提到亚马逊。该公司的Hadoop产品被称为EMR(Elastic Map Reduce),AWS解释这款产品采用了Hadoop技术来提供大数据管理服务,但它不是纯开源Hadoop,经过修改后现在被专门用在AWS云上。
Forrester称EMR有很好的市场前景。很多公司基于EMR为客户提供服务,有一些公司将EMR应用于数据查询、建模、集成和管理。而且AWS还在创新,Forrester称未来EMR可以基于工作量的需要自动缩放调整大小。亚马逊计划为其产品和服务提供更强大的EMR支持,包括它的RedShift数据仓库、新公布的Kenesis实时处理引擎以及计划中的NoSQL数据库和商业智能工具。不过AWS还没有自己的Hadoop发行版。
Cloudera
Cloudera有开源Hadoop的发行版,这个发行版采用了Apache Hadoop开源项目的很多技术,不过基于这些技术的发行版也有很大的进步。Cloudera为它的Hadoop发行版开发了很多功能,包括Cloudera管理器,用于管理和监控,以及名为Impala的SQL引擎等。Cloudera的Hadoop发行版基于开源Hadoop,但也不是纯开源的产品。当Cloudera的客户需要Hadoop不具备的某些功能时,Cloudera的工程师们就会实现这些功能,或者找一个拥有这项技术的合作伙伴。Forrester表示:“Cloudera的创新方法忠于核心Hadoop,但因为其可实现快速创新并积极满足客户需求,这一点使它不同于其他那些供应商。”目前,Cloudera的平台已经拥有200多个付费客户,一些客户在Cloudera的技术支持下已经可以跨1000多个节点实现对PB级数据的有效管理。
Hortonworks
和Cloudera一样,Hortonworks是一个纯粹的Hadoop技术公司。与Cloudera不同的是,Hortonworks坚信开源Hadoop比任何其他供应商的Hadoop发行版都要强大。Hortonworks的目标是建立Hadoop生态圈和Hadoop用户社区,推进开源项目的发展。Hortonworks平台和开源Hadoop联系紧密,公司管理人员表示这会给用户带来好处,因为它可以防止被供应商套牢(如果Hortonworks的客户想要离开这个平台,他们可以轻松转向其他开源平台)。这并不是说Hortonworks完全依赖开源Hadoop技术,而是因为该公司将其所有开发的成果回报给了开源社区,比如Ambari,这个工具就是由Hortonworks开发而成,用来填充集群管理项目漏洞。Hortonworks的方案已经得到了Teradata、Microsoft、Red Hat和SAP这些供应商的支持。
IBM
当企业考虑一些大的IT项目时,很多人首先会想到IBM。IBM是Hadoop项目的主要参与者之一,Forrester称IBM已有100多个Hadoop部署,它的很多客户都有PB级的数据。IBM在网格计算、全球数据中心和企业大数据项目实施等众多领域有着丰富的经验。“IBM计划继续整合SPSS分析、高性能计算、BI工具、数据管理和建模、应对高性能计算的工作负载管理等众多技术。”
Intel
和AWS类似,英特尔不断改进和优化Hadoop使其运行在自己的硬件上,具体来说,就是让Hadoop运行在其至强芯片上,帮助用户打破Hadoop系统的一些限制,使软件和硬件结合的更好,英特尔的Hadoop发行版在上述方面做得比较好。Forrester指出英特尔在最近才推出这个产品,所以公司在未来还有很多改进的可能,英特尔和微软都被认为是Hadoop市场上的潜力股。
MapR Technologies
MapR的Hadoop发行版目前为止也许是最好的了,不过很多人可能都没有听说过。Forrester对Hadoop用户的调查显示,MapR的评级最高,其发行版在架构和数据处理能力上都获得了最高分。MapR已将一套特殊功能融入其Hadoop发行版中。例如网络文件系统(NFS)、灾难恢复以及高可用性功能。Forrester说MapR在Hadoop市场上没有Cloudera和Hortonworks那样的知名度,MapR要成为一个真正的大企业,还需要加强伙伴关系和市场营销。
文档数据库
源起:受Lotus Notes启发。
数据模型:包含了key-value的文档集合
例子:CouchDB, MongoDB
优点:数据模型自然,编程友好,快速开发,web友好,CRUD。
图数据库
源起: 欧拉和图理论。
数据模型:节点和关系,也可处理键值对。
例子:AllegroGraph, InfoGrid, Neo4j
优点:解决复杂的图问题。
关系数据库
源起: E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的
数据模型:各种关系
例子:VoltDB, Clustrix, MySQL
优点:高性能、可扩展的OLTP,支持SQL,物化视图,支持事务,编程友好。
对象数据库
源起:图数据库研究
数据模型:对象
例子:Objectivity, Gemstone
优点:复杂对象模型,快速键值访问,键功能访问,以及图数据库的优点。
Key-Value数据库
源起:Amazon的论文 Dynamo 和 Distributed HashTables。
数据模型:键值对
例子:Membase, Riak
优点:处理大量数据,快速处理大量读写请求。编程友好。
BigTable类型数据库
源起:Google的论文 BigTable。
数据模型:列簇,每一行在理论上都是不同的
例子:HBase, Hypertable, Cassandra
优点:处理大量数据,应对极高写负载,高可用,支持跨数据中心, MapReduce。
数据结构服务
源起: ?
数据模型:字典操作,lists, sets和字符串值
例子:Redis
优点:不同于以前的任何数据库
网格数据库
源起:数据网格和元组空间研究。
数据模型:基于空间的架构
例子:GigaSpaces, Coherence
优点:适于事务处理的高性能和高扩展性
因为速度快。你上亿级数据的情况下NOSQL是比普通SQL效率更高,哪怕有索引。毕竟NOSQL的存储空间使用是普通SQL三倍多。基本都用在索引方面了。
如果是全文搜索关键字,左右模糊等就更甩SQL几条街了
因为关系数据库运行的慢
处理大数据的大多数情况是nosql比较高效
但是nosql也没法完全取代关系数据库
nosql不能处理复杂的逻辑
但是很多情况下只是简单的mapping,汇总,
在目前互联网大数据的环境下nosql会越来越普及