NoSQL数据库
NoSQL概述
⾃关系型数据库诞⽣40年以来，从理论产⽣发展到现实产品，例如：⼤家最常见的MySQL和Oracle，逐渐在数据库领域⾥上升到了霸主地位，形成每年⾼达数百亿美元的庞⼤产业市场。
但随着互联⽹web2.0⽹站的兴起，传统的关系型数据库在应付web2.0⽹站，特别是对于规模⽇益扩⼤的海量数据，超⼤规模和⾼并发的微博，，SNS类型的web2.0纯动态⽹站已经显得⼒不从⼼，暴露了很多难以克服的问题，例如：传统的关系型数据库IO瓶颈，性能瓶颈都难以有效突破，于是开始出现了⼤批针对特定场景，以⾼性能和使⽤便利为⽬的功能特异化的数据库产品，NoSQL（⾮关系型）类的数据库就是在这样的情境中诞⽣并得到了⾮常迅速的发展。
请注意，NoSQL的本意是“Not Only SQL”指的是⾮关系型数据库，⽽不是“No SQL”的意思（没有SQL语句？）。因此，NoSQL的产⽣并不是要彻底地否定关系型数据库，⽽是作为传统关系型数据库的⼀个有效补充。NoSQL数据库在特定的场景下可以发挥出难以想象的⾼效率和⾼性能。
重点记忆
专注于key-value查询的：redis，memcached，ttserver；
⾯向⽂档的数据库：Mongodb（地图类公司，可以放图⽚）
⾯向列的数据库hbase和cassandra（超⼤型公司）
⾯向图的数据库Neo4J等等（特殊部门，3D图形游戏）
这些NoSQL数据库的共同特点是
1，去除⼀切和⾼性能⽆关的功能。
2，追求⾼并发，⾼性能。
3，在扩展上⽀持集甚⾄分布式。
NoSQL现在正在被越来越多的公司使⽤者所接受并投⼊实际⽣产环境，包括超⼤型著名公司
Facebook和360使⽤cassandra来存储海量社交数据
Twitter在其url抓取系统⾥综合运⽤了Cassandra，Memcached
Google使⽤BigTable
Amazon使⽤Dynamo
新浪微博使⽤Redis，memcached来提⾼⾼并发⾼性能。
淘宝使⽤hbase，并改进研制出⾃⼰品牌的NoSQL产品Oceanbase。
⾖瓣也⾃⼰研发了NoSQL数据库BeansDB
对于常规内容的存储，中⼩企业也会去⽤mongodb
Mongodb被⼴泛⽤于存储⾮结构化数据
在电信运营商的数据分析项⽬中，使⽤hbase承载从交换机上采集下来的⾼速数据流。
熟悉NoSQL的原理，熟知每种产品的特性和适⽤场景进⾏技术选型，熟练地实施和管理集，这些都是新⼀代系统管理者，DBA和架构师们需要掌握的知识。NoSQL课程是⼀门IT课程，特别适合已经有⼀定关系型数据库（Oracle，MySQL等等）⼯作经验或知识基础，从事数据库管理，系统运维，数据分析，架构设计师等⼯作，想对NoSQL进⾏⼀定的了解，以⽅便⽇后进⾏技术选型和补充知识的朋友，为⾃⼰增加附加值，增强竞争⼒，适应新时代的变化。
NoSQL数据库可以解决哪些问题？
我们为什么要使⽤NoSQL这样⾮关系型数据库呢？在前⾯的描述中我们已经给了⼀个简单的答案了。
随着互联⽹web2.0⽹站的兴起，传统的关系型数据库在应付web2.0⽹站，特别是超⼤规模和⾼并发的SNS类型的web2.0纯动态⽹站已经显得⼒不从⼼，暴露了很多难以克服的问题，例如：传统的关系型IO瓶颈，性能瓶颈都难以有效突破，于是开始出现了⼤批针对特定场景，以⾼性能和使⽤便利为⽬的的功能特异化的数据库产品，NoSQL（⾮关系型）类的数据库就是在这样的情景中诞⽣并得到了⾮常迅速的发展。NoSQL数据库可以⽐较好的解决如下⼏个传统关系型数据库难以解决的问题：
（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 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项⽬的名字上看不出什么相同之处：Hadoop，Voldemort，Dynomite，还有其他很多。
NoSQL数据库适⽤场景⼩结
总结NoSQL数据库在以下的这⼏种情况下⽐较适⽤
1.数据模型⽐较简单；
2.需要灵活性更强的IT系统；
3.对数据库性能要求较⾼；
4.不需要⾼度的数据⼀致性；
5.对于给定key，⽐较容易映射复杂值的环境。
NoSQL主流软件分类与特点
键值（Key-Value）存储数据库
键值数据库就像在传统语⾔中使⽤的哈希表。可以通过key来添加，查询或者删除数据，因为使⽤主键访问，所以会获得不错的性能及扩展性。
键值（Key-Value）数据库主要是使⽤⼀个哈希表，这个表中有⼀个特定的键和⼀个指针指向特定的数据。Key／Value模型对于IT系统来说的优势在于简单，易部署。
相关产品及其场景如下
1. 数据库产品 Redis，MemcacheDB，Berkeley DB，memcached等
2.
3. 典型应⽤内容缓存，适合混合⼯作负载并扩展⼤的数据集
4.
5. 数据模型⼀系列键值对
6.
7. 优势快速查询redis是nosql数据库吗
8.
9. 劣势存储的数据缺少结构化
10.
11. 适⽤的场景存储⽤户信息，⽐如会话，配置⽂件，参数，购物车等等。这些信息⼀般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择
12.
13. 不适⽤场景 1.不通过键查询，⽽是通过值来查询；Key-Value数据库没有通过值查询的途径；2.需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据；3.事务
⽀持。在Key-Value数据库中故障产⽣时不可以进⾏回滚
14.
15. 企业应⽤
Github（Riak），BestBuy（Riak），Twitter（Redis和Memcached），StackOverFlow（Redis），I
nstagram（Redis），Youtube（Memcached），sina（redis），baidu（Memcached）
列存储（Column-oriented）数据库
列存储数据库将数据存储在列族（column family）中，⼀个列蔟存储经常被⼀起查询的相关数据。举个例⼦，如果我们有⼀个Person类，我们通常会⼀起查询他们的姓名和年龄⽽不是薪资。这种情况下，姓名和年龄就会被放⼊⼀个列蔟中，⽽薪资则在另⼀个列蔟中。
这部分数据库通常是⽤来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。
1. 数据库产品 Cassandra，HBase，Riak
2.
3. 典型应⽤内容缓存，适合混合⼯作负载并扩展⼤的数据集
4.
5. 数据模型以列簇式存储，将同⼀列数据存在⼀起
6.
7. 优势查速度快，可扩展性强，更容易进⾏分布式扩展
8.
9. 劣势功能相对局限
10.
11. 适⽤场景⽇志：因为我们可以将数据存储在不同的列中，每个应⽤程序可以将信息写⼊⾃⼰的列族中。博客平台：我们储存每个信息到不同的列族中。举个例⼦，标签可以储存在⼀个，类
别可以在⼀个，⽽⽂章则在另⼀个。
12.
13. 不适⽤场景 1，事务 2，原型设计
14.
15. 企业应⽤ Ebay（Cassandra），Instagram（Cassandra），NASA（Cassandra），Twitter（Cassandra and HBase），Facebook（HBase），Yahoo！
（HBase），taobao（HBase），360（Cassandra）
⾯向⽂档（Document-Oriented）数据库
⽂档型数据库的灵感是来⾃于Lotus Notes办公软件的，⽽且它同第⼀种键值存储相类似。该类型的数据模版是版本化的⽂档，半结构化的⽂档以特定的格式存储，⽐如JSON。⽂档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。⽽且⽂档型数据库⽐键值数据库的查询效率更⾼。
⾯向⽂档数据库会将数据以⽂档的形式储存。每个⽂档都是⾃包含的数据单元，是⼀系列数据项的集合。每个数据项都有⼀个名称与对应的值，值既可以是简单的数据类型，如字符串，数字和⽇期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最⼩单位是⽂档，同⼀个表中存储的⽂档属性可以是不同的，数据可以使⽤XML，JSON或者JSONB等多种形式存储。
相关产品及其场景如下
1. 数据库产品 CouchDB，MongoDB，RavenDB
2.
3. 典型应⽤ Web应⽤
4.
5. 数据模型数据结构要求不严格
6.
7. 劣势查询性能不⾼，⽽且缺乏统⼀的查询语法
8.
9. 适⽤场景⽇志：企业环境下，每个应⽤程序都有不同的⽇志信息
10.
11. 不适⽤场景事务
12.
13. 企业应⽤案例 SAP（mongoDB），Codecademy（MongoDB），Foursquare（MongoDB），NBC News（RavenDB）
图形（Graph）数据库
图形数据库允许我们将数据以图的⽅式存储。实体会被作为顶点，⽽实体之间的关系则会被作为边。⽐如我们有三个实体，Steve jobs，Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve jobs。
图形结构的数据库同其他⾏列以及刚性结构的SQL数据库不同，它是使⽤灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语句（SQL），因此进⾏数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接⼝或者查询API。
相关产品及其场景如下
1. 数据库产品 Neo4J，InfoGrid，Infinite，Graph，OrientDB
2.
3. 典型应⽤社交⽹络，推荐系统等。专注于构建关系图谱
4.
5. 数据模型图结构
6.
7. 强项利⽤图结构相关算法
8.
9. 弱项需要对整个图做计算才能得出结果，不容易做分布式的集⽅案
10.
11. 适⽤的场景在⼀些关系性强的数据中，推荐引擎。如果我们将数据以图的形式表现，那么将会⾮常有益于推荐的制定
12.
13. 不适⽤场景不适合的数据模型。图数据库的适⽤范围很⼩，因为很少有操作涉及到整个图
14.
15. 企业应⽤ Adobe（Neo4J），Cisco（Neo4J），T-Mobile（Neo4J）
常⽤NoSQL数据库详细介绍
Memcached（key-value）
Memcached是⼀个开源的，⾼性能的，具有分布式内存对象的缓存系统。通过它可以减轻数据库负载加速动态Web应⽤，最初版本由LiveJournal的Brad Fitzpatrick在2003年开发完成。⽬前全世界很多⽤户都在使⽤它来构建⾃⼰的⼤负载⽹站或提⾼⾃⼰的⾼访问⽹站的响应速度。Memcache是这个项⽬的名称，⽽Memcached是服务器端的主程序⽂件名。
缓存⼀般⽤来保存⼀些经常被存取的对象或数据（例如，浏览器会把经常访问的⽹页缓存起来），通过缓存来存取对象或数据要⽐磁盘存取快很多。
Memcache是⼀种内存缓存，把经常存取的对象或数据缓存在内存中，内存中缓存的这些数据通过API的⽅式被存取，数据就像⼀张⼤的HASH表，以key-value对的⽅式存在。Memcache通过缓存经常被存取的对象或数据，减轻数据库的压⼒，提⾼⽹站的响应速度，构建出速度更快的可扩展的Web应⽤。Memcached的特点
1.部署极其简单。
2.⽀持⾼并发，⾼性能(⽐redis快)
3.通过程序或者负载均衡可以实现分布式。
4.仅为内存缓存，重启服务数据丢失（缺点）
MemcacheDB（key-value）
Memcached是新浪⽹基于Memcached开发的⼀个开源项⽬。通过为Memcached增加BerkeleyDB的持久化存储机制和异步主辅复制机制，使Memcached 具备了事务恢复能⼒，持久化能⼒和分布式复制能⼒，⾮常适合需要超⾼性能读写速度，持久化保存的应⽤场景。例如：memcachedb被应⽤在新浪博客上。如果对Memcached有持久化需求，可以考虑使⽤memcachedb。
memcached⽤于数据库内存缓存，问题：进程退出，数据全丢，这样就算缓存启动了，内存⾥没有数据，因此⽤户会瞬时访问数据库，造成数据库撑不住。
通过脚本或者程序，从数据库⾥把数据读出来存到memcached缓存⾥，然后前端才能开启对外访问。
Memcacheddb持久化的缓存系统，不但可以像memcached⼀样提供内存缓存，还可以把内存的数据存放到磁盘。数据量的多少和NOSQL软件的机制决定了，重新把数据加载到内存需要多久。
Memcachedb特点
1.⾼性能读写基于key-value的对象
2.基于事务的⾼效存储
3.基于同步的⾼可⽤存储
4.Memcache兼容协议（兼容memcache代码）
Redis（key-value）
redis是⼀个key-value存储系统。和Memcached类似，它⽀持存储的value类型想对更多，包括string（字符串），list（链表），set（集合）和zset（有序集合）。这些数据类型都⽀持push/pop，add/remove及取交集并集和差集及更丰富的操作，⽽且这些操作都是原⼦性的。在此基础上，redis⽀持各种不同⽅式的排序。与memcached⼀样，为了保证效率。数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写⼊磁盘或者把修改操作写⼊追加的记录⽂件，并且在此基础上实现了master-slave（主从）同步。
Redis是⼀个⾼性能的key-value数据库。redis的出现，很⼤程度补偿了memcached这类key/value存
储的不⾜，在部分场合可以对关系数据库起到很好的补充作⽤。它提供了Python，Ruby，Erlang，PHP客户端，使⽤很⽅便。
redis特点
1.⽀持内存缓存，相当于memcached；
2.持久化，相当于memcachedb，ttserver；
3.数据类型更丰富；
4.⽀持集，分布式。
代码从读取memcached更改读取redis
Tokyo Tyrant 介绍（key-value）ttserver
Tokyo Cabinet介绍
Tokyo Cabinet是⽇本⼈Mikio Hirabayashi（平林⼲雄）开发的⼀款DBM数据库（注：⼤名⿍⿍的DBM数据库qdbm就是他开发的），该数据库读写⾮常快。写⼊100万数据只需要0.4秒。读取100万数据只
需要0.33秒。是BerkeleyDB等DBM的很多倍。
Tokyo Tyrant是提供dbm数据库Tokyo Cabinet的⽹络接⼝。它使⽤简单的基于TCP／IP的简单⼆进制协议进⾏通信。同时它拥有Memcached兼容协议并且可以⽤HTTP／1.1协议进⾏数据交换。所以实现了跨平台，跨语⾔使⽤Tokyo Tyrant。同时Tokyo Tyrant采⽤热备份，更新⽇志记录，复制
（replication）来实现⾼可⽤性和⾼可靠性。到⽬前为⽌，Tokyo Tyrant可以运⾏在Linux，FreeBSD，Mac OS X，Solaris。
Tokyo Tyrant加上Tokyo Cabinet，构成了⼀款⽀持⾼并发的分布式持久化存储系统，对任何原有Memcached客户端来讲，可以将Tokyo Tyrant Server看成是⼀个Memcached，但是，它的数据是可以持久存储的。这⼀点和Memcachedb性质⼀样。
Tokyo Tyrant兼容Memcached协议，⽀持主从同步，故障转移，⾼并发的分布式key-value持久化存储系统。
Tokyo Tyrant优势
相⽐Memcached及Memcachedb⽽⾔，Tokyo Tyrant具有以下优势
1.Tokyo Tyrant 不但⽀持内存缓存，⽽且还可以持久化存储。
2.故障转移：Tokyo Tyrant ⽀持主从模式，也⽀持双机互为主辅模式，主辅库均可读写，⽽Memcachedb⽬前⽀持类似MySQL主辅库同步的⽅式实
现读写分离，⽀持“主服务器可读写，辅助服务器只读”模式。
(3)5千万条数据级别内的访问相当快。
4.兼容Memcached协议，客户端不需要更改任何代码。
MongoDB（Document-oriented）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。