常见数据库场景分析
2016-08-07 22:00
330 查看
常见数据库场景分析 2
一 关系型数据库 2
1.关系型数据简介 2
2.常用的概念 2
4.特点 3
5.常见关系型数据库 3
二 常见非关系型数据库(NoSQL)场景分析 3
1、NoSQL的特性 3
2、根据需求进行分类 4
2.1满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare 4
2.2 满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB 7
2.3满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort 9
关系型数据库,是指采用了关系模型来组织数据的数据库。 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
2.常用的概念
关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名 ·
元组:可以理解为二维表中的一行,在数据库中经常被称为记录
属性:可以理解为二维表中的一列,在数据库中经常被称为字段
域:属性的取值范围,也就是数据库中某一列的取值限制
· 关键字:一组可以唯一标识元组的属性,数据库中常称为主键,由一个或多个列组成
· 关系模式:指对关系的描述。其格式为:关系名(属性1,属性2,... ,属性N),在数据库中成为表结构
3.优点
· 容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解
· 使用方便:通用的SQL语言使得操作关系型数据库非常方便
易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了
2)数据库的写实时性和读实时性需求
3)对复杂的SQL查询,特别是多表关联查询的需求(join)
4)常见的关系型数据库
2)Huge Storage – 对海量数据的高效率存储和访问的需求
3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
机制:很像memcached(memcached是一套分布式的高速缓存系统),整个数据库统 统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。
特色:
1)纯内存操作
2)性能非常出色
3)10万次读写操作/秒
4)性能最快的Key-Value DB
5)单个value的最大限制为1GB
6)支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作
Eg:从 List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一 个功能加强版的memcached来用。
缺点:
1)数据库容量受到物理内存的限制,不能用作海量数据的高性能读
2)没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写。
适合的场景:
主要局限在较小数据量的高性能操作和运算上。
目前使用Redis的网站:github,Engine Yard。
Tokoy Tyrant:是为TC写的网络接口,他支持memcache协议,也可以通过HTTP操作,以下称TT。
TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value 数据库领域最大的热点,现在被广泛的应用在很多很多网站上。
本质:
TC是一个高性能的存储引擎
TT提供了多线程高并发服务器
支持高并发的分布式持久存储系统
特色:
1)4-5万次读写操作/秒。
2)极高的并发读写性能&可靠的数据持久化机制
3)支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作。
4)可以缓存磁盘数据的存储系统
5)支持异步的写入机制
缺点:
1)没有scale的能力,如果单机无法满足要求,只能通过主从复制的方式扩展
2)性能会随着数据量的增加而下降,当数据量 上亿条以后,性能会有比较明显的下降。
3)在32位操作系统下,作为 Tokyo Tyrant 后端存储的 Tokyo Cabinet 数据库单个文件不能超过2G ,而64位操作系统则不受这一限制。所以,如果使用 Tokyo Tyrant,推荐在64位CPU、操作系统上安装运行
备注:http://blog.chinaunix.net/uid-20556054-id-3321331.html
特点:
支持scale能力,他在网络服务端之前添加了一个 node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可以scale,那么可以考虑flare。
缺点:
只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的 key-value数据结构存储。
特点:
1)非关系数据库当中功能最丰富,最像关系数据库。
2)支持的数据结构非常松散,是类似 json的bjson格式,可以存储比较复杂的数据类型。
3)支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能
4)支持对数据建立索引。
5)海量数据的访问效率,官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以上
缺点:
并发读写效率一般,0.5万-1.5万次读写/秒
1)CouchDB是分布式的数据库,他可以把存储系统分布到n台物理的节点上面,并且很好的协调和同步节点之间的数据读写一致性。
CouchDB是面向文档的数据库,存储半结构化的数据,比较类似lucene的index结构,特别适合存储文档,因此很适合CMS,电话本,地址本等应用,在这些应用场合,文档数据库要比关系数据库更加方便,性能更好。
3)CouchDB支持REST API,可以让用户使用JavaScript来操作CouchDB数据库,也可以用JavaScript编写查询语句。
缺点:
仅仅提供了基于HTTP REST的接口并发读写性能不好
2.3.1 Cassandra(卡桑德拉)
Cassandra项目是Facebook在2008年开源出来的。目前除了 Facebook之外,twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到 其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了。
特性:
1)分布式
2)基于column的结构化
3)高伸展性
特点:
1)模式灵活 :使用Cassandra,像文档存储,你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升,特别是在大型部署上。
2)真正的可扩展性 :Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量,可以指向另一台计算机。你不必重启任何进程,改变应用查询,或手动迁移任何数据。
3) 多数据中心识别 :你可以调整你的节点布局来避免某一个数据中心起火,一个备用的数据中心将至少有每条记录的完全复制。
2.3.2 Voldemort(伏地魔)
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Voldemort则来自于Linkedin这个SNS网站。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读 写性能也很不错,每秒超过了1.5万次读写。
Voldemort是一个分布式键-值(Key-value)存储系统,是Amazon's Dynamo的一个开源克隆。
特点:
1)支持自动复制数据到多个服务器上。
2)支持数据自动分割所以每个服务器只包含总数据的一个子集。
3)提供服务器故障透明处理功能。
4)支持可拨插的序化支持,以实现复杂的键-值存储,它能够很好的
5)集成常用的序化框架如:Protocol Buffers、Thrift、Avro和Java Serialization。
6)数据项都被标识版本能够在发生故障时尽量保持数据的完整性而不会影响系统的可用性。
7)每个节点相互独立,互不影响。
8)支持可插拔的数据放置策略。
备注:http://www.360doc.com/content/11/0429/15/2560742_113169460.shtml
一 关系型数据库 2
1.关系型数据简介 2
2.常用的概念 2
4.特点 3
5.常见关系型数据库 3
二 常见非关系型数据库(NoSQL)场景分析 3
1、NoSQL的特性 3
2、根据需求进行分类 4
2.1满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare 4
2.2 满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB 7
2.3满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort 9
常见数据库场景分析
一 关系型数据库
1.关系型数据简介关系型数据库,是指采用了关系模型来组织数据的数据库。 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
2.常用的概念
关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名 ·
元组:可以理解为二维表中的一行,在数据库中经常被称为记录
属性:可以理解为二维表中的一列,在数据库中经常被称为字段
域:属性的取值范围,也就是数据库中某一列的取值限制
· 关键字:一组可以唯一标识元组的属性,数据库中常称为主键,由一个或多个列组成
· 关系模式:指对关系的描述。其格式为:关系名(属性1,属性2,... ,属性N),在数据库中成为表结构
3.优点
· 容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解
· 使用方便:通用的SQL语言使得操作关系型数据库非常方便
易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了
4.特点
1)数据库事务一致性需求2)数据库的写实时性和读实时性需求
3)对复杂的SQL查询,特别是多表关联查询的需求(join)
4)常见的关系型数据库
5.常见关系型数据库
oracle、SQL Server、Sybase、DB2、Access二 常见非关系型数据库(NoSQL)场景分析
1、NoSQL的特性
1)High performance – 对数据库高并发读写的需求2)Huge Storage – 对海量数据的高效率存储和访问的需求
3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
2、根据需求进行分类
2.1满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo Cabinet, Flare,这3个Key-Value DB都是用C编写的。2.1.1 Redis
本质:一个Key-Value类型的内存数据库机制:很像memcached(memcached是一套分布式的高速缓存系统),整个数据库统 统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。
特色:
1)纯内存操作
2)性能非常出色
3)10万次读写操作/秒
4)性能最快的Key-Value DB
5)单个value的最大限制为1GB
6)支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作
Eg:从 List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一 个功能加强版的memcached来用。
缺点:
1)数据库容量受到物理内存的限制,不能用作海量数据的高性能读
2)没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写。
适合的场景:
主要局限在较小数据量的高性能操作和运算上。
目前使用Redis的网站:github,Engine Yard。
2.1.2 Tokyo Cabinet和Tokoy Tyrant
Tokyo Cabinet:一个key-value的DBM数据库,但是没有提供网络接口,以下称TC。Tokoy Tyrant:是为TC写的网络接口,他支持memcache协议,也可以通过HTTP操作,以下称TT。
TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value 数据库领域最大的热点,现在被广泛的应用在很多很多网站上。
本质:
TC是一个高性能的存储引擎
TT提供了多线程高并发服务器
支持高并发的分布式持久存储系统
特色:
1)4-5万次读写操作/秒。
2)极高的并发读写性能&可靠的数据持久化机制
3)支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作。
4)可以缓存磁盘数据的存储系统
5)支持异步的写入机制
缺点:
1)没有scale的能力,如果单机无法满足要求,只能通过主从复制的方式扩展
2)性能会随着数据量的增加而下降,当数据量 上亿条以后,性能会有比较明显的下降。
3)在32位操作系统下,作为 Tokyo Tyrant 后端存储的 Tokyo Cabinet 数据库单个文件不能超过2G ,而64位操作系统则不受这一限制。所以,如果使用 Tokyo Tyrant,推荐在64位CPU、操作系统上安装运行
备注:http://blog.chinaunix.net/uid-20556054-id-3321331.html
2.1.3 Flare
Flare简单的说就是给TC添加了 scale功能。他替换掉了TT部分,自己另外给TC写了网络服务器,特点:
支持scale能力,他在网络服务端之前添加了一个 node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可以scale,那么可以考虑flare。
缺点:
只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的 key-value数据结构存储。
2.2 满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写,而是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而 CouchDB则是Erlang开发的2.2.1 MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品特点:
1)非关系数据库当中功能最丰富,最像关系数据库。
2)支持的数据结构非常松散,是类似 json的bjson格式,可以存储比较复杂的数据类型。
3)支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能
4)支持对数据建立索引。
5)海量数据的访问效率,官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以上
缺点:
并发读写效率一般,0.5万-1.5万次读写/秒
2.2.2 CouchDB
特点:1)CouchDB是分布式的数据库,他可以把存储系统分布到n台物理的节点上面,并且很好的协调和同步节点之间的数据读写一致性。
CouchDB是面向文档的数据库,存储半结构化的数据,比较类似lucene的index结构,特别适合存储文档,因此很适合CMS,电话本,地址本等应用,在这些应用场合,文档数据库要比关系数据库更加方便,性能更好。
3)CouchDB支持REST API,可以让用户使用JavaScript来操作CouchDB数据库,也可以用JavaScript编写查询语句。
缺点:
仅仅提供了基于HTTP REST的接口并发读写性能不好
2.3满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样,它首先必须是一个分布式的数据库系统,由分布在不同节点上面的数据库共同 构成一个数据库服务系统,并且根据这种分布式架构来提供online的,具有弹性的可扩展能力,例如可以不停机的添加更多数据节点,删除数据节点等等。因 此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的:2.3.1 Cassandra(卡桑德拉)
Cassandra项目是Facebook在2008年开源出来的。目前除了 Facebook之外,twitter和digg.com都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到 其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了。
特性:
1)分布式
2)基于column的结构化
3)高伸展性
特点:
1)模式灵活 :使用Cassandra,像文档存储,你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升,特别是在大型部署上。
2)真正的可扩展性 :Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量,可以指向另一台计算机。你不必重启任何进程,改变应用查询,或手动迁移任何数据。
3) 多数据中心识别 :你可以调整你的节点布局来避免某一个数据中心起火,一个备用的数据中心将至少有每条记录的完全复制。
2.3.2 Voldemort(伏地魔)
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Voldemort则来自于Linkedin这个SNS网站。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读 写性能也很不错,每秒超过了1.5万次读写。
Voldemort是一个分布式键-值(Key-value)存储系统,是Amazon's Dynamo的一个开源克隆。
特点:
1)支持自动复制数据到多个服务器上。
2)支持数据自动分割所以每个服务器只包含总数据的一个子集。
3)提供服务器故障透明处理功能。
4)支持可拨插的序化支持,以实现复杂的键-值存储,它能够很好的
5)集成常用的序化框架如:Protocol Buffers、Thrift、Avro和Java Serialization。
6)数据项都被标识版本能够在发生故障时尽量保持数据的完整性而不会影响系统的可用性。
7)每个节点相互独立,互不影响。
8)支持可插拔的数据放置策略。
备注:http://www.360doc.com/content/11/0429/15/2560742_113169460.shtml
相关文章推荐
- 一个常见数据库操作错误的分析(三)
- 一个常见数据库操作错误的分析(五)
- 常见PHP数据库解决方案分析介绍
- 数据库--使用索引的注意事项及常见场景
- 单例模式常见的应用场景分析
- 一个常见数据库操作错误的分析(一)
- Python SQLite3数据库日期与时间常见函数用法分析
- 数据库安全测评常见问题的分析与对策
- Loadrunner脚本回放 场景运行过程中常见错误分析
- 常见数据库的分析
- 一个常见数据库操作错误的分析(六)
- 常见NoSQL系统使用场景分析
- Loadrunner 脚本回放 场景运行过程中 常见错误分析
- 常见PHP数据库解决方案分析介绍
- Hadoop MapReduce两种常见的容错场景分析
- 一个常见数据库操作错误的分析(四)
- 常见NoSQL系统使用场景分析
- 常见的NoSql系统使用场景分析--转载
- 常见的数据分析图表类型以及各自的使用场景!