Java业务开发常见错误100例
朱晔
贝壳金服资深架构师
立即订阅
5295 人已学习
课程目录
已更新 32 讲 / 共 38 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 业务代码真的会有这么多坑?
免费
代码篇 (20讲)
01 | 使用了并发工具类库,线程安全就高枕无忧了吗?
02 | 代码加锁:不要让“锁”事成为烦心事
03 | 线程池:业务代码最常用也最容易犯错的组件
04 | 连接池:别让连接池帮了倒忙
05 | HTTP调用:你考虑到超时、重试、并发了吗?
06 | 20%的业务代码的Spring声明式事务,可能都没处理正确
07 | 数据库索引:索引并不是万能药
08 | 判等问题:程序里如何确定你就是你?
09 | 数值计算:注意精度、舍入和溢出问题
10 | 集合类:坑满地的List列表操作
11 | 空值处理:分不清楚的null和恼人的空指针
12 | 异常处理:别让自己在出问题的时候变为瞎子
13 | 日志:日志记录真没你想象的那么简单
14 | 文件IO:实现高效正确的文件读写并非易事
15 | 序列化:一来一回你还是原来的你吗?
16 | 用好Java 8的日期时间类,少踩一些“老三样”的坑
17 | 别以为“自动挡”就不可能出现OOM
18 | 当反射、注解和泛型遇到OOP时,会有哪些坑?
19 | Spring框架:IoC和AOP是扩展的核心
20 | Spring框架:框架帮我们做了很多工作也带来了复杂度
设计篇 (6讲)
21 | 代码重复:搞定代码重复的三个绝招
22 | 接口设计:系统间对话的语言,一定要统一
23 | 缓存设计:缓存可以锦上添花也可以落井下石
24 | 业务代码写完,就意味着生产就绪了?
25 | 异步处理好用,但非常容易用错
26 | 数据存储:NoSQL与RDBMS如何取长补短、相辅相成?
不定期加餐 (5讲)
加餐1 | 带你吃透课程中Java 8的那些重要知识点(上)
加餐2 | 带你吃透课程中Java 8的那些重要知识点(下)
加餐3 | 定位应用问题,排错套路很重要
加餐4 | 分析定位Java问题,一定要用好这些工具(一)
加餐5 | 分析定位Java问题,一定要用好这些工具(二)
Java业务开发常见错误100例
15
15
1.0x
00:00/00:00
登录|注册

26 | 数据存储:NoSQL与RDBMS如何取长补短、相辅相成?

朱晔 2020-05-14
你好,我是朱晔。今天,我来和你聊聊数据存储的常见错误。
近几年,各种非关系型数据库,也就是 NoSQL 发展迅猛,在项目中也非常常见。其中不乏一些使用上的极端情况,比如直接把关系型数据库(RDBMS)全部替换为 NoSQL,或是在不合适的场景下错误地使用 NoSQL。
其实,每种 NoSQL 的特点不同,都有其要着重解决的某一方面的问题。因此,我们在使用 NoSQL 的时候,要尽量让它去处理擅长的场景,否则不但发挥不出它的功能和优势,还可能会导致性能问题。
NoSQL 一般可以分为缓存数据库、时间序列数据库、全文搜索数据库、文档数据库、图数据库等。今天,我会以缓存数据库 Redis、时间序列数据库 InfluxDB、全文搜索数据库 ElasticSearch 为例,通过一些测试案例,和你聊聊这些常见 NoSQL 的特点,以及它们擅长和不擅长的地方。最后,我也还会和你说说 NoSQL 如何与 RDBMS 相辅相成,来构成一套可以应对高并发的复合数据库体系。

取长补短之 Redis vs MySQL

Redis 是一款设计简洁的缓存数据库,数据都保存在内存中,所以读写单一 Key 的性能非常高。
我们来做一个简单测试,分别填充 10 万条数据到 Redis 和 MySQL 中。MySQL 中的 name 字段做了索引,相当于 Redis 的 Key,data 字段为 100 字节的数据,相当于 Redis 的 Value:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java业务开发常见错误100例》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • 那时刻
    我说说个人对于MongoDB的理解,它的优势:
    1.schema free,不需要额外定义列名,每个文档的key需要一致。
    2.对于json结构存储和读取方便,比如取json某个key的value比较方便。相对于mysql存储json需要序列化和反序列化操作。
    3.查询来看,3.0之后的mongo采用了B+树和LSM两种方式,来优化读多写少和写多读少情况。

    劣势:
    1. schema free,是双刃剑,如果某个字段并不是所有文档里存在,查询是个麻烦事。
    2.不支持事务
    3.为了向RDBMS靠拢,通过冗余字段来实现。实践起来不是很方便。
    2020-05-14
    2
    1
  • kyl
    说一下我对mongodb的理解,望老师指正。mongodb因为是文档型数据库以json格式存储,所以可以很方便的存储各种类型的数据,同时mongodb横向扩展只需增加分片比MySQL更加方便,数据量很大的场景下感觉性能优于MySQL。但是mongodb对事务支持比较差,虽然4.0引入了事务,但是可能有坑,另外mongodb不支持表的关联查询,所以还是要根据实际业务场景进行选择。

    作者回复: 基本没错的 mongodb建议用于非重要业务初始数据保存

    2020-05-14
  • 似曾相识
    老师 Infludb,和es 这些数据库做辅助数据库,需要保存全量数据吗?还是根据业务保存部分字段?

    作者回复: es一般是保存全量数据,甚至是超全量数据,意思就是比mysql保存的数据还要全。influxdb作为时间序列数据库只能保存加工后的业务或系统指标数据,无法保存实际的业务数据。

    2020-05-14
  • 汝林外史
    又是干货满满,很多新接触的东西,感谢老师。
    对于Mysql擅长的地方的第二点不是很理解:
       1.不是不建议设置外键吗?
       2.专门弄个索引表放主键与外键的关联关系,那岂不是每张表都要配这么一个索引表,这不浪费内存吗?
       3.主键跟关联表是一对多的关系,那这个索引表相对数据表的数据量岂不是几倍的关系,性能能好了吗?
    还请老师指教。

    作者回复: 1. 我是指逻辑含义上这个字段是外键的作用,不是指要外键关系的绑定
    2. 这个方案是一套针对大数据高并发的系统(比如订单系统的)的复合数据引擎方案,不是说普通的业务表都要这么做
    3. 不是几倍的关系,索引表的字段是全量字段的子集,索引表不会做Sharding,这点你没有我的意思,可以再详细看一下文中的说明:

    对二级索引进行查询得到主键,只需要查询一棵 B+ 树,效率同样很高。但索引的值不宜过大,比如对 varchar(1000) 进行索引不太合适,而索引外键(一般是 int 或 bigint 类型)性能就会比较好。因此,我们可以在 MySQL 中建立一张“索引表”,除了保存主键外,主要是保存各种关联表的外键,以及尽可能少的 varchar 类型的字段。这张索引表的大部分列都可以建上二级索引,用于进行简单搜索,搜索的结果是主键的列表,而不是完整的数据。由于索引表字段轻量并且数量不多(一般控制在 10 个以内),所以即便索引表没有进行 Sharding 拆分,问题也不会很大。

    2020-05-14
  • 那时刻
    请问老师,文章提到的多数据库系统例子里,redis写入是怎么实现的呢?

    作者回复: 取决于缓存的使用策略,比如Cache aside, Read through, Write through,可以根据你需要的方案把写入redis的操作落到读服务或同步写服务去实现。

    2020-05-14
  • fly12580
    redis还可以用来做分布式并发锁。
    2020-05-14
  • Demon.Lee
    现在公司的业务对ACID没有那么高的要求,已经全部换成了NoSQL,主要就是MongoDB+Redis+ES,自从用了MongoDB,我感觉解脱了,再也不用去设计一堆关联的表了,字段的扩充或变化都没有什么影响,字段取值的检验全部在应用程序中解决,有点不爽是,写各种复杂查询和统计时没有写rdms的sql那么溜。另外就是,我们使用了Keys去redis查询所有相关的数据,一般数据量不大,但是我一直想优化下,今天老师又提了,必须优化了。
    2020-05-14
收起评论
7
返回
顶部