随着互联网大潮的到来,越来越多网站,应用系统需要海量数据的支撑,高并发、低延迟、高可用、高扩展等要求在传统的关系型数据库中已经得不到满足,或者说关系型数据库应对这些需求已经显得力不从心了。关系型数据库经过几十年的发展已经很成熟,强大的sql语句支持,完美的ACID属性的支持,使得关系型数据库广泛应用于各种各样的应用系统中,但是应用的场景广泛并非意味着完美。

- 由于关系型数据库是按行进行存储的,在某些只统计一列的需求场景下,也需要把整行读入内存,导致了一个小小的统计需求高IO的缺点

- 关系型数据库无法存储数据结构,比如:一个商品可以从属于多个分类,业务上的从属关系体现到存储上是一个列表而已,但是关系型数据库需要把这些关系存储为多行,无法直接存储为一个列表。

- 关系型数据库中的存储单位表的架构是强约束,操作不存在的列会报出异常,而且添加、更新、删除列必须执行DDL语句,如果表的现存数据量比较大,会出现长时间锁表的现象。

- 关系型数据库全文搜索功能普通比较弱,用like去匹配关键词的时候,数据量比较大的情况下会出现慢查询的现象。

- 关系型数据库基于表格的关系模型使得很难添加新的或不同种类的关联信息。

由于以上这些诸多问题,便诞生了以“NOSQL”为口号的很多解决方案。在某些关系型数据库不擅长的领域,Nosql表现的很出色。上天是公平的,给你打开了一扇窗户,必会给你关上半扇门,NoSql是以牺牲ACID某个或者某些特性为代价的。

NoSQL并不是银弹,更多的时候是关系型数据库一个有力补充,或者是特定场景下优于关系型数据库的一种解决方案

NoSQL

NoSQL,泛指非关系型的数据库。现在大家更喜欢翻译成:not only sql

根据NoSQL的存储等特性,大体可以分为以下几类

- 键值(Key-Value)存储数据库。相关的产品:Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached。主要解决关系数据库无法存储数据结构的问题。

- 列存储数据库。相关产品:BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS。解决关系数据库大数据场景下的 I/O 问题

- 文档数据库。相关产品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit。解决关系数据库强 schema 约束的问题。

- 图形数据库。相关产品:Neo4J、OrientDB、InfoGrid、GraphDB。主要解决大量复杂、互连接、低结构化的图结构场合,如社交网络、推荐系统等

- 全文搜索引擎。相关产品:Elasticsearch。主要解决关系数据库的全文搜索性能问题。

由此可见,没有哪一种NoSql是完美的,每一种Nosql都有自己擅长的领域,这也是我们做系统架构中要考虑的重要因素。

场景1

电商的商品设计过程中,每种商品的属性都不同,属性数目不同,属性名不同,同一个商品有可能会属于多个分类,而且随着业务的发展,很多商品会增加新的属性,而且最令程序员头疼莫过于每种属性都有可能有搜索的可能性(当然搜索可以利用搜索引擎来实现)。遇到这样的需求场景,如果利用关系型数据库来存储的话,表的字段会非常多,而且字段的定义非常令人头疼。

这样的场景非常适合NOsql中的文档型数据库,比如MongoDB。文档型数据库新增字段非常简单,不像关系型数据库需要先执行DDL来增加字段,直接可以利用程序来进行读写,历史数据就算是没有相应的字段也不会有异常的情况发生。最重要的一点,文档型数据库很擅长存储复杂结构的数据,一般情况下业务上可以利用表现能力很强的json数据结构。

{
    "Id":1,
    "ProductName":"杜蕾斯加强版",
    "Price":100,
    "Type":[
        1,
        2,
        4
    ],
    "Length":20,
    "Height":2 }

如果所有商品信息都用mongodb来存储的话,有的场景并不是十分完美。比如商品被成功购买之后扣库存的问题,联合查询的问题,由于Nosql天生对ACID支持不足的原因,一个事务性的操作很难在Nosql中实现,所以设计系统的时候在很多情况下是关系数据库+Nosql 来共同实现业务。

场景2

很多具体的业务中都有记录数据然后进行统计的需求场景,比如那些统计uv,pv的系统。日志型的数据量非常大,而且还有可能有峰值的出现,如果用关系型数据库来存储,很有可能在IO上会出现瓶颈,而且有可能会影响其他正常的业务,更不幸的是当执行统计语句的时候,性能更是差强人意。这样的日志型统计业务很适合HBase这样的列式Nosql,业务上要统计一天的uv,pv数据,HBase很适合统计某一列数据的场景,因为只需要把对应的列进行统计即可,不像关系型数据库那样需要把所有行都加载进内存,而且列式存储一般比行式存储拥有更大的压缩比例,占用的磁盘空间会更少。

列式存储的应用场景有一定的限制,一般用于统计和大数据的分析中。

场景3

在多数高并发系统中都存在缓存的设计,而缓存的一般数据结构都是K-V结构。缓存是一种提高系统性能的有效手段,因其需要提供快速访问的特性,一般缓存都放置于内存当中。比如现在我们要设计一个用户管理系统,每个用户信息可以做缓存以便提供高速的访问,由于很多系统都采用分布式的部署方式,所以采用进程内的缓存方式并不可取,这个时候就需要有一种高速的外部存储来提供这种业务,这正是kv型Nosql的典型应用场景之一。其中以redis为代表,具体的业务中可以以用户id为key,用户的信息为value存储在redis中,而且redis在3.0之后可以做集群了,在高可用和扩展上更能助力业务方。redis支持的数据类型很多,在不同的场景下选择不同的数据类型。

场景4

当一个系统有搜索的业务时候,如果搜索的条件是一些简单的类型搜索,关系型数据库还可以满足,但是如果有全文搜索,就是我们平时sql写的like ‘%xx%’这样的搜索,关系型数据库可能并不是最好的选择,全文搜索引擎类型的Nosql也许是一个更好的解决方案,其中以Elasticsearch 为代表。全文搜索引擎的搜索的条件可以随意排列组合,并且可以实现关系型数据库like方式的模糊匹配。

全文搜索引擎的技术原理称为“倒排索引”(inverted index),是一种索引方法,其基本原理是建立单词到文档的索引。与之相对是,是“正排索引”,其基本原理是建立文档到单词的索引。

场景5

在社交系统中最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好,其查询复杂、缓慢、超出预期,而图形数据库的独特设计恰恰弥补了这个缺陷,解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。其中以Neo4j为代表。想深入研究的同学请移步百度。

无论是关系型数据库还是nosql数据库都不是银弹,每一种事物都有它最善长的领域。设计一个好的系统,需要综合考虑各种因素,根据具体的业务场景来选择最合适的解决方案。

领取福利

记得微信扫码识别,领取技术书籍哦

程序员修神之路--用NOSql给高并发系统加速(送书)的更多相关文章

  1. 程序员修神之路--kubernetes是微服务发展的必然产物

    菜菜哥,我昨天又请假出去面试了 战况如何呀? 多数面试题回答的还行,但是最后让我介绍微服务和kubernetes的时候,挂了 话说微服务和kubernetes内容确实挺多的 那你给我大体介绍一下呗 可 ...

  2. 程序员修神之路--redis做分布式锁可能不那么简单

    菜菜哥,复联四上映了,要不要一起去看看? 又想骗我电影票,对不对? 呵呵,想去看了叫我呀 看来你工作不饱和呀 哪有,这两天我刚基于redis写了一个分布式锁,很简单 不管你基于什么做分布式锁,你觉得很 ...

  3. 程序员修神之路--🤠分布式高并发下Actor模型如此优秀🤠

    写在开始 一般来说有两种策略用来在并发线程中进行通信:共享数据和消息传递.使用共享数据方式的并发编程面临的最大的一个问题就是数据条件竞争.处理各种锁的问题是让人十分头痛的一件事. 传统多数流行的语言并 ...

  4. 程序员修神之路--设计一套RPC框架并非易事

    菜菜哥,我最近终于把Socket通信调通了 这么底层的东西你现在都会了,恭喜你离涨薪又进一步呀 http协议不也是利用的Socket吗 可以这么说,http协议是基于TCP协议的,底层的数据传输可以说 ...

  5. 程序员修神之路--为什么有了SOA,我们还用微服务?

    菜菜哥,我最近需要做一个项目,老大让我用微服务的方式来做 那挺好呀,微服务现在的确很流行 我以前在别的公司都是以SOA的方式,SOA也是面向服务的方式呀 的确,微服务和SOA有相同之处 面向服务的架构 ...

  6. 程序员修神之路--打通Docker镜像发布容器运行流程

    菜菜哥,我看了一下docker相关的内容,但是还是有点迷糊 还有哪不明白呢? 如果我想用docker实现所谓的云原生,我的项目该怎么发布呢? 这还是要详细介绍一下docker了 Docker 是一个开 ...

  7. 程序员修仙之路--优雅快速的统计千万级别uv(留言送书)

    菜菜,咱们网站现在有多少PV和UV了? Y总,咱们没有统计pv和uv的系统,预估大约有一千万uv吧 写一个统计uv和pv的系统吧 网上有现成的,直接接入一个不行吗? 别人的不太放心,毕竟自己写的,自己 ...

  8. 程序员修仙之路--优雅快速的统计千万级别uv

    菜菜,咱们网站现在有多少PV和UV了? Y总,咱们没有统计pv和uv的系统,预估大约有一千万uv吧 写一个统计uv和pv的系统吧 网上有现成的,直接接入一个不行吗? 别人的不太放心,毕竟自己写的,自己 ...

  9. 程序员修仙之路- CXO让我做一个计算器!!

    菜菜呀,个税最近改革了,我得重新计算你的工资呀,我需要个计算器,你开发一个吧 CEO,CTO,CFO于一身的CXO X总,咱不会买一个吗? 菜菜 那不得花钱吗,一块钱也是钱呀··这个计算器支持加减乘除 ...

随机推荐

  1. 5.秋招复习简单整理之请介绍一下List和ArrayList的区别,arrayList和HashSet区别?

    第一问:List是接口,ArrayList是List的实现类. 第二问:ArrayList是List的实现类,HashSet是Set的实现类,List和Set都实现了Collection接口. Arr ...

  2. 记一次linux服务器入侵应急响应

    近日接到客户求助,他们收到托管电信机房的信息,通知检测到他们的一台服务器有对外发送攻击流量的行为.希望我们能协助排查问题. 一.确认安全事件 情况紧急,首先要确认安全事件的真实性.经过和服务器运维人员 ...

  3. MyBatis 多数据库支持

    From<MyBatis从入门到精通> <!-- 4.6 多数据库支持 简单的看了一下,没有深入研究~~~ -->

  4. 【最小生成树之Kruskal例题-建设电力系统】-C++

    前置知识点Kruskal最短路算法,如果没掌握的请先去掌握! 描述 小明所在的城市由于下暴雪的原因,电力系统严重受损.许多电力线路被破坏,因此许多村庄与主电网失去了联系.政府想尽快重建电力系统,所以, ...

  5. [HAOI2006]聪明的猴子 题解

    题意: 在一个热带雨林中生存着一群猴子,它们以树上的果子为生.昨天下了一场大雨,现在雨过天晴,但整个雨林的地表还是被大水淹没着,部分植物的树冠露在水面上.猴子不会游泳,但跳跃能力比较强,它们仍然可以在 ...

  6. Appium+python自动化(二十二)- 三个臭皮匠顶个诸葛亮-控件坐标获取(超详解)

    简介 有些小伙伴或者是童鞋可能会好奇会问上一篇中的那个monkey脚本里的坐标点是如何获取的,不是自己随便蒙的猜的,或者是自己用目光或者是尺子量出来的吧,答案当然是:NO.获取控件坐标点的方式这里宏哥 ...

  7. C语言入门6-选择结构--f语句-switch

    一.     什么是选择结构? 选择结构,也称为分支结构!! 选择结构就是根据    给定的判定条件,判断结果, 并根据  判断的结果   来控制程序的流程 (流程图中,   菱形框 是有来判断的 , ...

  8. [leetcode] 51. N-Queens (递归)

    递归,经典的八皇后问题. 利用一位数组存储棋盘状态,索引表示行,值为-1表示空,否则表示列数. 对行进行搜索,对每一行的不同列数进行判断,如果可以摆放符合规则,则摆放,同时遍历下一行. 遍历过程中,若 ...

  9. vue.js 中组件的使用

    Vue中组件的使用 方式一 1.使用Vue.extend创建组件 var com1 = Vue.extend({ template: '<h3>这是使用 Vue.extend 创建的组件& ...

  10. CentOS 7.2配置LAMP环境——yum版

    环境:CentOS 7.2 采用putty连接 方法:采用yum安装方法 目的:搭建Apache+MySQL+PHP环境 1.安装Apache yum install httpd //默认情况下,选择 ...