16 | 高性能NoSQL
李运华
该思维导图由 AI 生成，仅供参考
关系数据库经过几十年的发展后已经非常成熟，强大的 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/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
NoSQL技术作为关系型数据库的有力补充，弥补了其在特定场景下的不足。本文介绍了列式数据库和全文搜索引擎作为NoSQL方案的两个典型代表。列式数据库以其高效的多列读写操作和存储压缩比，适用于大数据分析和统计场景，但在频繁更新多个列的场景下表现不佳。全文搜索引擎通过倒排索引技术解决了关系型数据库无法满足的全文搜索需求，能够灵活处理各种搜索条件的排列组合，但需要将关系型数据转换为文档数据进行索引。总的来说，NoSQL技术为特定场景下的数据存储和检索提供了更灵活、高效的解决方案，但在选择时需根据业务特性和要求进行权衡。读者可以通过本文了解到NoSQL技术的优势和局限性，以及其在特定场景下的应用价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学架构》，新⼈⾸单¥68
《从 0 开始学架构》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(105)
- 最新
- 精选
鹅米豆发关于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-0430333
约书亚看过一些资料，RDB当年（比我还大好多）也是在数据库大战的血雨腥风中一条血路杀出来的。现在回魂的document db当前也是RDB对手之一。如果真有这么多问题，怎么还能脱颖而出，主宰软件开发领域这么久。只能说现互联网和物联网的兴起使得应用场景向海量数据，线下上分析，读多写也多这些情况偏移了，这些场景对ACID的要求很低。 但现在大多数应用的也许还是直接面对用户，要求数据有一定可靠性，数据总量和并发量并没那么高。RDB技术成熟，人才易得，声明式SQL语法让开发者忽略底层实现，关系型的模型也符合人的思考模式。而且现在大多数一流的RDB都集成了基本的文档存储和索引，空间存储，全文检索，数据分析等功能。在没达到一定规模和深度前，完全可以用个RDB来做MVP，甚至搞定中小型也许场景。 从码农的角度看，我还是更崇拜关系型数据库，因为其底层实现里包罗了算法，系统，网络，分布式，数学统计学各种绝世武功。 前几年在NoSQL炒起来没多久，NewSQL的概念又被提出了。现在各路牛人都投入到D RDB的研发中，成型的也有不少。虽然不太可能完全取代现在的各种NoSQL，但也许能收复不少失地。 历史就是个循环，天下大势分久必合合久必分...作者回复: RDB的功能是最强大的
2018-06-0239
姜戈华仔，我们公司刚起步的时候有2个应用，数据库用的mysql, 日志也存储在mysql, 用户增长很快，没有专职架构师，现在准备重构以适应业务增长，考虑jhipster on kubernetes , 昨天同事之间交流了一下方案: gateway + registry + k8s traefik ingress, 通过k8s 实现hipster技术栈的高可用，所有微服务容器化， 第一阶段准备拆成5个service, 在gateway做路由规则和鉴权，日志部分用mongodb, mysql暂时不分库，订单rocketMQ队列化, 这样合理吗？有什么更好的建议?作者回复: 我感觉你们一下子引入这么多对你们来说是新的技术，风险有点大。
2018-06-02428
彬哥我认为，行式数据库读取的时候，用sql可以指定关心的列，无需读取所有。 所以，这一段是不是笔者笔误？求赐教作者回复: 数据库返回你需要的列给你，但是数据库将数据从磁盘读入内存的时候，是整行读取的，事实上是读取行所在的整页数据
2018-06-28825
孙振超本章最大的收获是了解了nosql数据库的四种类型以及特点、使用场景和关系型数据库的区别，比如redis中的list结构的强大之处、列式存储为什么压缩比会高很多，这也是作者比较强的地方。作为存储数据的系统，肯定有共同的地方，但既然能单独拎出来又说明有不同之处，掌握了相同之处可以快速理解系统能力，了解了不同之处可以明白其使用范围，并且对自己以后的架构设计方案选择提供基础。 自己之前总觉得要掌握一个系统要从看源代码开始，但后来发现这种方式太过耗时，效率过低，就开始转变为了解这个系统主要的能力是什么，然后根据能力去进行拆解，看那些是自己已经掌握了解的，那些是陌生的，对于陌生的部分了解其实现思路是怎么样的，对于实现思路的主要细节看下代码了解，这样有针对性的看效率得到了比较大的提升。 对于本篇的问题，在文章中其实已经说明白了，关系型数据库是不可替代的，比如事务能力、强管控、经常性读取多列的场景都需要关系型数据库。作者回复: 这种方法叫做“比较学习法”，对比学习，效果最明显
2018-06-18325
9527老师您好，问个题外话😂 如今各种新技术层出不穷，像那种底层的大块头之类的书籍，比如深入理解计算机系统，编译原理这样的，还有必要深入学习吗？ 像深入理解计算机系里面的反汇编分析在实际工作中确是是用不到，更别提开发个编译器了 面对这些看似不错的书籍，但又觉得里面的内容无法运用到实际中，有些迷茫，望老师指点作者回复: 请到聊聊架构公众号搜索《当我们聊技术实力的时候，我们到底在聊什么》，我写了一篇文章来回答你这个问题
2018-06-05517
铃兰Neko认真的看到现在，有两点疑问。 1.es和lucene这种，一般当做搜索引擎，也划在nosql里面合适吗? 2.能否给一些常见nosql性能和数据量的数据， 网上搜不大到，唯一知道的都是从ppt里面扣的 另外，nosql那个图原图应该在reddit上，地址是 http://i.imgur.com/lkG9Vm8.jpg作者回复: 1. 只要是为了弥补关系数据库的缺陷的方案，都可算nosql 2. 量级一般都是上万，但和测试硬件测试用例相关，如果要用，最好自己测试
2018-06-0416
小喵喵跨库操作如何做事物呢？看到这期了还是没有答案吗？作者回复: 跨库操作不建议事物，效率低，容易出错，用最终一致性
2018-06-03314
明翼文档数据库和es有何区别，es我看也是对scheme不敏感的啊作者回复: 文档数据库定位于存储和访问，es定位于搜索，但目前差别并不是很大，因为系统边界的扩充，就像mongodb也要支持ACID，mysql也要支持文档存储
2018-06-1411
func关系数据库就是行式存储，从硬盘读到内存的时候，是整行读取，实际上还是整页读取的。不明白这个整页指的是？这个整页指的是 包括很多行数据吗？这个整页的数据都是我需要的吗？作者回复: 为了存储高效，文件存储在磁盘上是分页存储的，每页包含很多行，不一定都是你要的，更多信息可以参考innodb得文档
2018-09-299
收起评论
