大话NoSql

之前看过一本名叫<<大数据挑战的书>>,里面主要讲了NOSQL的内容,感觉讲得确实不错,今天来重新温习一下,我们大话NOSQL。说道NOSQL,我们肯定联想到的内容就是BigData大数据了,不错,当今的时代就是大数据的时代了。如果放在前几年,互联网还没有这么发达的情况下,也许谁也不会听过这个名词。在讲正题的时候,我做了张图来看看一般服务端架构在面对业务发展的需要时候,一般的演变趋势:

所以如果公司的数据量发展到一定规模的话,可以采用NoSql.好了终于引出了NoSql这个今天的主题了。NoSql可以理解为”Not Only Sql”,主要指的是非关系型,分布式,不提供ACID的数据库设计模式,强调的是类似于Map的“键值存储”,和”文档存储“。面对海量数据,NoSql 采用了一种弱类型的数据,采用更加简单的数据模型,一般都是用字符串表示所有的数据类型。但是他可能不会像关系型数据库一样有那么好的强一致性,应该nosql是一种最终一致性。NoSql也避免了许多诸如联表查询等复杂操作,基本就是简单的赋值,取值等,

可以实现比较难高的吞吐量。现在的数据库系统可谓是五彩缤纷,来张图看看:

在介绍nosql之前,要知道的一些海量数据的理论性知识,CAP理论,C,(Consistency)强一致性,A(Available)可用性,P(Partition Tolerance)分区容忍性,可以理解为系统在存在网络分区的情况下仍然可以接受请求。自然这让我们联系到了另一个理论ACID,A(Atomic)原子性,C(Consistent)一致性, I(Isolation)隔离性, D(Durablitity)持续性。还有一个比较重要的协议2PC两阶段提交协议,许多分布式关系数据库采用此协议来完成分布式事务。下面我们来真正了解一下具体的NOSQL。

K-V数据库

首先我们来了解是Redis,Redis是一个开源的,高级key-value的数据库。他的value不仅支持String类型,而且还有list,set等结构,Redis采用的是内存进行数据存储,等数据到达一定规模后,在持久化到文件或磁盘中。基于Redis的特点,新浪微博采用的就是Redis,对于微博这样的结构清晰,数据规模庞大的应用来说,Redis当然最适合不过了。

Column-Oriented列式数据库

说到列式数据库,我们不得不提到他的始祖,Bigtable数据库,在后来衍射出的很多数据库都能看到他的影子,列式数据库强调的是一种面向列的稀疏存储,还有一个列族的概念,跟关系型数据库的单行单列,不一样,比较典型的Hadoop采用的HBase数据库。

文档型数据库

文档型数据,我这里说的有2种,MongoDB,还有一个CouchDB,两者有很多共同点存储的都是JSON类型数据类型,在文档数据库中文档成为了数据存储的一个基本单位,因此,所存储的数据,甚至可以要求是无结构的,文档可长,可短,每一个都以类似于”{“”id”: 200, “msg”:”haha”}这样的json格式保存在数据库中。我们重点关注一下MongoDB,在MongoDB中存在着类似于SQL查询语句的操作,但是又不是跟SQL语句完全相同,比如db,user,find(),MongoDB支持Map/Reduce模型,CouchDB具体RestFul API,可以实现用Http请求实现操作。二者数据库都借助了Map/Reduce,技术提高了数据处理的效率,这对于与存储非结构化,和半结构化的数据都有很大的帮助。

图存数据库

图存数据库我刚刚听说这个名词的时候,也是觉得难以理解,官方给出的定义:图存数据库使用基础的数据结构,来存储代表一个图形的数据,能够通过非常方便的方式优雅的呈现任何类型的数据。图存数据库现在一般有3类,Neo4j数据库,GraphDB图存数据库,OrientDB,图存数据库的查询会模仿图的遍历实现查找,通过朋友找到朋友的朋友,最终找到目标。

NoSql就是分为上述的4种类型,突然心血来潮,相到一个比较重要的知识点,数据处理,数据处理平常也总是有人在提起,我就提提,我说的数据处理指的是传统的压缩算法的实现,一般有2种,一个哈弗曼编码,学过计算机的,数据结构都上过的吧,另一个L.Z算法系列的,现在应该已经很多版本了吧,是基于窗口互动的,核心思想就是复用相同的字符串,如果后面的字符串出现了前面重复,用一个标记代替,可以大大节省压缩数量。

好了,花了1000多字,理了理思路,也起到了复习的效果了。

时间: 2024-12-25 08:58:10

大话NoSql的相关文章

【大话NoSQL】——什么是NoSQL?

开始之前,先说说写这篇博文的背景,本来是想写MongoDB的内容,但是MongoDB又是非关系型数据库中最火的一个.我还是本着自己一直习惯的学习步骤,先有全局观,再着眼于微观,所以有必要先了解一下非关系数据库的发展历史,再开始学习MongoDB.否则,我们学习再多的MongoDB也只能是手中的一把沙,抓的越紧,剩下的越少. 整理的博文内容大部分都来自于网络,也有自己一点点见解吧,废话少说,下面进入我们今天的话题: 概念 NoSQL(NoSQL=Not Only SQL),意即"不仅仅是SQL&q

【大话存储II】学习笔记(15章),NoSQL

互联网运营商(NSP)的数据中心是数据最集中的地方,也正是因为海量的数据存储与访问,传统的存储架构已经无法满足了现有的需求. 比如每秒几十万次的随机IOPS.每秒10GB的流量,一般都需要使用高端存储,当然价格将不便宜.而且扩展性不好,扩容成本高. 业务的不断增加,导致互联网运营商逐步使用分布式系统来构建底层文件系统及数据库,比如Google的GFS+Bigtable 我们先来看一下为了应对大并发.大流量下,架构的逐步的变化,最后引入NoSQL. 传统数据库架构的演进 使用缓存技术 随着访问量的

我心中的核心组件(可插拔的AOP)~大话开篇及目录

我心中的核心组件(可插拔的AOP)~大话开篇及目录 http://www.cnblogs.com/lori/p/3247905.html 回到占占推荐博客索引 核心组件 我心中的核心组件,核心组件就是我认为在项目中比较常用的功能,如日志,异常处理,消息,邮件,队列服务,调度,缓存,持久化,分布式文件存储,NoSQL存储,IoC容器,方法拦截等等. 对于以上内容可以说即是一个大餐,又是一个挑战,就让我带着大家去迎接这份挑战吧,呵呵! 可插拔的AOP AOP即面向切面的编程,是指将一个公用的与领域无

【转】大话程序猿眼里的高并发架构

原文: http://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/?from=sf 前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等.为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的

【转】大话程序猿眼里的高并发

原文: http://blog.thankbabe.com/2016/04/01/high-concurrency/ 大话程序猿眼里的高并发 2016-04-01 YYQ 高并发 高并发  负载均衡  并发  锁  事务  集群 高并发是指在同一个时间点,有很多用户同时的访问URL地址,比如:淘宝的双11,双12,就会产生高并发,如贴吧的爆吧,就是恶意的高并发请求,也就是DDOS攻击,再屌丝点的说法就像玩撸啊撸被ADC暴击了一样,那伤害你懂得(如果你看懂了,这个说法说明是正在奔向人生巅峰的屌丝.

大话程序猿眼里的高并发(下)

大话程序猿眼里的高并发(下) 前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家. 服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务.

大话程序猿眼里的高并发(上)

大话程序猿眼里的高并发(上) 高并发是指在同一个时间点,有很多用户同时的访问URL地址,比如:淘宝的双11,双12,就会产生高并发,如贴吧的爆吧,就是恶意的高并发请求,也就是DDOS攻击,再屌丝点的说法就像玩撸啊撸被ADC暴击了一样,那伤害你懂得(如果你看懂了,这个说法说明是正在奔向人生巅峰的屌丝. 高并发会来带的后果 服务端: 导致站点服务器/DB服务器资源被占满崩溃,数据的存储和更新结果和理想的设计是不一样的,比如:出现重复的数据记录,多次添加了用户积分等. 用户角度: 尼玛,这么卡,老子来

SQL SERVER大话存储结构(5)

阅读目录(Content) 1 基本介绍 2 对数据库启动的影响 3 日志文件添加方式 4 物理结构 5 延迟日志截断原因 6 管理事务日志 本系列上一篇博文链接:SQL SERVER大话存储结构(4)_复合索引与包含索引 回到顶部(go to top) 1 基本介绍 每个数据库都具有事务日志,用于记录所有事物以及每个事物对数据库所作的操作. 日志的记录形式需要根据数据库的恢复模式来确定,数据库恢复模式有三种: 完整模式,完全记录事物日志,需要定期进行日志备份. 大容量日志模式,适用于批量操作的

云计算背后的秘密:NoSQL诞生的原因和优缺点

转载收藏一篇对nosql讲解的比较全面的文章:http://blog.csdn.net/xlgen157387/article/details/47908797 这篇文章将和大家聊聊为什么NoSQL会在关系型数据库已经非常普及的情况下异军突起? 诞生的原因 随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求,主要体现在下面这四个方面: 1. 低延迟的读写速度:应用快速地反应能极大地提升用户的满意度; 2. 支撑海量的数据和流量:对于搜索这样大型应用而