从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

16 | 高性能NoSQL

李运华 2018-06-02
关系数据库经过几十年的发展后已经非常成熟,强大的 SQL 功能和 ACID 的属性,使得关系数据库广泛应用于各式各样的系统中,但这并不意味着关系数据库是完美的,关系数据库存在如下缺点。
关系数据库存储的是行记录,无法存储数据结构
以微博的关注关系为例,“我关注的人”是一个用户 ID 列表,使用关系数据库存储只能将列表拆成多行,然后再查询出来组装,无法直接存储一个列表。
关系数据库的 schema 扩展很不方便
关系数据库的表结构 schema 是强约束,操作不存在的列会报错,业务变化时扩充列也比较麻烦,需要执行 DDL(data definition language,如 CREATE、ALTER、DROP 等)语句修改,而且修改时可能会长时间锁表(例如,MySQL 可能将表锁住 1 个小时)。
关系数据库在大数据场景下 I/O 较高
如果对一些大量数据的表进行统计之类的运算,关系数据库的 I/O 会很高,因为即使只针对其中某一列进行运算,关系数据库也会将整行数据从存储设备读入内存。
关系数据库的全文搜索功能比较弱
关系数据库的全文搜索只能使用 like 进行整表扫描匹配,性能非常低,在互联网这种搜索复杂的场景下无法满足业务要求。
针对上述问题,分别诞生了不同的 NoSQL 解决方案,这些方案与关系数据库相比,在某些应用场景下表现更好。但世上没有免费的午餐,NoSQL 方案带来的优势,本质上是牺牲 ACID 中的某个或者某几个特性,因此我们不能盲目地迷信 NoSQL 是银弹,而应该将 NoSQL 作为 SQL 的一个有力补充,NoSQL != No SQL,而是 NoSQL = Not Only SQL。
常见的 NoSQL 方案分为 4 类。
K-V 存储:解决关系数据库无法存储数据结构的问题,以 Redis 为代表。
文档数据库:解决关系数据库强 schema 约束的问题,以 MongoDB 为代表。
列式数据库:解决关系数据库大数据场景下的 I/O 问题,以 HBase 为代表。
全文搜索引擎:解决关系数据库的全文搜索性能问题,以 Elasticsearch 为代表。
今天,我来介绍一下各种高性能 NoSQL 方案的典型特征和应用场景。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(76)

  • 鹅米豆发
    关于NoSQL,看过一张图,挺形象:“1970,We have no SQL”->“1980,Know SQL”->“2000,NoSQL”->“2005,Not only SQL”->“2015,No,SQL”。目前,一些新型数据库,同时具备了NoSQL的扩展性和关系型数据库的很多特性。
           关系型和NoSQL数据库的选型。考虑几个指标,数据量、并发量、实时性、一致性要求、读写分布和类型、安全性、运维性等。根据这些指标,软件系统可分成几类。
           1.管理型系统,如运营类系统,首选关系型。
           2.大流量系统,如电商单品页的某个服务,后台选关系型,前台选内存型。
           3.日志型系统,原始数据选列式,日志搜索选倒排索引。
           4.搜索型系统,指站内搜索,非通用搜索,如商品搜索,后台选关系型,前台选倒排索引。
           5.事务型系统,如库存、交易、记账,选关系型+缓存+一致性协议,或新型关系数据库。
           6.离线计算,如大量数据分析,首选列式,关系型也可以。
           7.实时计算,如实时监控,可以选时序数据库,或列式数据库。

    作者回复: 求原图😃

    2018-06-04
    130
  • Snway
    No SQL并非银弹,如ACID方面就无法跟关系型数据库相比,实际运用中,需要根据业务场景来分析,比较好的做法是,No SQL+关系型数据库结合使用,取长补短。如我们之前的做法是将商品/订单/库存等相关基本信息放在关系型数据库中(如MySQL,业务操作上支持事务,保证逻辑正确性),缓存可以用Redis(减少DB压力),搜索可以用Elasticsearch(提升搜索性能,可通过定时任务定期将DB中的信息刷到ES中)。
    2018-06-03
    20
  • 公号-代码荣耀
    需求驱动架构,无论选用RDB/NoSQL/DRDB,一定是以需求为导向,最终的数据存储方案也必然是各种权衡的设计妥协。
    没有银弹,因为不同的应用需求对数据的要求也各不相同。当前我们不可能找到一个存储方案能满足所有的应用需求,但是我们可以通过认识到各种存储方案的优点与缺点(陷阱),在实际应用中,根据应用场景的不同要求(比如对可用性、一致性、易用性、支持事务、响应延迟、伸缩性等),按照上述特性要求的优先级排序,找到最合适的方案并“混合搭配”使用各种数据存储方案。
    多种方案搭配混用必然会增加应用的复杂性与增加运维成本,但同时也带来了系统更多的灵活性。
    举例:传统/互联网金融领域目前就不可能离开RDB。
    2018-06-03
    15
  • 约书亚
    看过一些资料,RDB当年(比我还大好多)也是在数据库大战的血雨腥风中一条血路杀出来的。现在回魂的document db当前也是RDB对手之一。如果真有这么多问题,怎么还能脱颖而出,主宰软件开发领域这么久。只能说现互联网和物联网的兴起使得应用场景向海量数据,线下上分析,读多写也多这些情况偏移了,这些场景对ACID的要求很低。
    但现在大多数应用的也许还是直接面对用户,要求数据有一定可靠性,数据总量和并发量并没那么高。RDB技术成熟,人才易得,声明式SQL语法让开发者忽略底层实现,关系型的模型也符合人的思考模式。而且现在大多数一流的RDB都集成了基本的文档存储和索引,空间存储,全文检索,数据分析等功能。在没达到一定规模和深度前,完全可以用个RDB来做MVP,甚至搞定中小型也许场景。
    从码农的角度看,我还是更崇拜关系型数据库,因为其底层实现里包罗了算法,系统,网络,分布式,数学统计学各种绝世武功。
    前几年在NoSQL炒起来没多久,NewSQL的概念又被提出了。现在各路牛人都投入到D RDB的研发中,成型的也有不少。虽然不太可能完全取代现在的各种NoSQL,但也许能收复不少失地。
    历史就是个循环,天下大势分久必合合久必分...

    作者回复: RDB的功能是最强大的

    2018-06-02
    15
  • 铃兰Neko
    认真的看到现在,有两点疑问。
    1.es和lucene这种,一般当做搜索引擎,也划在nosql里面合适吗?
    2.能否给一些常见nosql性能和数据量的数据,
    网上搜不大到,唯一知道的都是从ppt里面扣的

    另外,nosql那个图原图应该在reddit上,地址是
     http://i.imgur.com/lkG9Vm8.jpg

    作者回复: 1. 只要是为了弥补关系数据库的缺陷的方案,都可算nosql
    2. 量级一般都是上万,但和测试硬件测试用例相关,如果要用,最好自己测试

    2018-06-04
    10
  • 空档滑行
    NoSQL出现的原因是针对解决某一特定问题,这个问题用关系型数据库无法很好的解决。所以就注定了NO SQL不会是个大而全的东西,虽然这几年特性不断增加,使得部分业务场景可以完全不依赖关系数据库,但是关系数据库仍然是最容易理解,适用场景最广泛的数据库。就像OLAP无法完全代替离线计算,HTAP无法完全代替OLAP+OLTP一样,NOSQL是很好的补充,不是为了代替
    2018-06-02
    8
  • 姜戈
    华仔,我们公司刚起步的时候有2个应用,数据库用的mysql, 日志也存储在mysql, 用户增长很快,没有专职架构师,现在准备重构以适应业务增长,考虑jhipster on kubernetes , 昨天同事之间交流了一下方案: gateway + registry + k8s traefik ingress, 通过k8s 实现hipster技术栈的高可用,所有微服务容器化, 第一阶段准备拆成5个service, 在gateway做路由规则和鉴权,日志部分用mongodb, mysql暂时不分库,订单rocketMQ队列化, 这样合理吗?有什么更好的建议?

    作者回复: 我感觉你们一下子引入这么多对你们来说是新的技术,风险有点大。

    2018-06-02
    8
  • 小喵喵
    跨库操作如何做事物呢?看到这期了还是没有答案吗?

    作者回复: 跨库操作不建议事物,效率低,容易出错,用最终一致性

    2018-06-03
    7
  • 孙振超
    本章最大的收获是了解了nosql数据库的四种类型以及特点、使用场景和关系型数据库的区别,比如redis中的list结构的强大之处、列式存储为什么压缩比会高很多,这也是作者比较强的地方。作为存储数据的系统,肯定有共同的地方,但既然能单独拎出来又说明有不同之处,掌握了相同之处可以快速理解系统能力,了解了不同之处可以明白其使用范围,并且对自己以后的架构设计方案选择提供基础。
    自己之前总觉得要掌握一个系统要从看源代码开始,但后来发现这种方式太过耗时,效率过低,就开始转变为了解这个系统主要的能力是什么,然后根据能力去进行拆解,看那些是自己已经掌握了解的,那些是陌生的,对于陌生的部分了解其实现思路是怎么样的,对于实现思路的主要细节看下代码了解,这样有针对性的看效率得到了比较大的提升。

    对于本篇的问题,在文章中其实已经说明白了,关系型数据库是不可替代的,比如事务能力、强管控、经常性读取多列的场景都需要关系型数据库。

    作者回复: 这种方法叫做“比较学习法”,对比学习,效果最明显

    2018-06-18
    6
  • 明翼
    文档数据库和es有何区别,es我看也是对scheme不敏感的啊

    作者回复: 文档数据库定位于存储和访问,es定位于搜索,但目前差别并不是很大,因为系统边界的扩充,就像mongodb也要支持ACID,mysql也要支持文档存储

    2018-06-14
    5
  • Michael
    老师您好,问个题外话😂
    如今各种新技术层出不穷,像那种底层的大块头之类的书籍,比如深入理解计算机系统,编译原理这样的,还有必要深入学习吗?
    像深入理解计算机系里面的反汇编分析在实际工作中确是是用不到,更别提开发个编译器了
    面对这些看似不错的书籍,但又觉得里面的内容无法运用到实际中,有些迷茫,望老师指点

    作者回复: 请到聊聊架构公众号搜索《当我们聊技术实力的时候,我们到底在聊什么》,我写了一篇文章来回答你这个问题

    2018-06-05
    5
  • 幻影霸者
    mongodb4.0不是支持acid事务吗?

    作者回复: 官方宣称会实现事务,但需要看最终实现,实现事务不是完全没有代价的,要么性能降低,要么灵活性降低

    2018-06-03
    5
  • Otto
    你好,我有找到一张 history of nosql图档,分享给您。
    https://www.reddit.com/r/ProgrammerHumor/comments/2mk8sb/history_of_nosql/
    2018-06-11
    4
  • monkay
    有个商品搜索的需求,怎么评估elasticsearch和solr哪个更合适?

    作者回复: 功能上其实都可以,关键看实时性和性能,如果都满足,按照简单原则,你熟悉哪个就用哪个

    2018-06-02
    4
  • func
    关系数据库就是行式存储,从硬盘读到内存的时候,是整行读取,实际上还是整页读取的。不明白这个整页指的是?这个整页指的是 包括很多行数据吗?这个整页的数据都是我需要的吗?

    作者回复: 为了存储高效,文件存储在磁盘上是分页存储的,每页包含很多行,不一定都是你要的,更多信息可以参考innodb得文档

    2018-09-29
    3
  • 朱彬
    我认为,行式数据库读取的时候,用sql可以指定关心的列,无需读取所有。

    所以,这一段是不是笔者笔误?求赐教

    作者回复: 数据库返回你需要的列给你,但是数据库将数据从磁盘读入内存的时候,是整行读取的,事实上是读取行所在的整页数据

    2018-06-28
    3
  • ZYCHD(子玉)
    保险行业用的关系型数据库多些,No SQL少些。保险行业一个重要的要求是数据不能丢失!

    作者回复: 主要还是保险行业技术不够开放😄,保险行业数据和支付宝相比一下就知道了

    2018-06-18
    1
    3
  • allen.huang
    华哥,我想问下,我之前在做电商时,将商品全部存到redis中以hash结构存储,同时商品下面有个库存也存在其下面,库存在做减操作时,我用hincrby来进行,并发小的时候问题不大,库存不会超。
    并发大了以后会不会数据库一样超了?

    作者回复: redis本身不存在并发访问,因为是单进程的,但你的业务代码很可能会有问题,例如先get然后判断后再hincrby就会出现并发问题

    2018-12-27
    1
    2
  • caison
    redis的操作应该是原子性的吧,因为redis的单线程的

    作者回复: 是的

    2018-07-25
    2
  • 轩辕十四
    mongo4 开始支持事务了吧

    作者回复: 我不敢用,我相信MySQL😊

    2018-06-27
    2
收起评论
76
返回
顶部