全栈工程师修炼指南
熊燚（四火）
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后，你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看，为什么你应该成为全栈工程师？
免费
学习路径 | 怎样成为一名优秀的全栈工程师？
导读 | 如何学习这个专栏？
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天：HTTP 协议的演化
02 | 为HTTP穿上盔甲：HTTPS
03 | 换个角度解决问题：服务端推送技术
04 | 工整与自由的风格之争：SOAP和REST
05 | 权衡的艺术：漫谈Web API的设计
06 | 特别放送：北美大厂如何招聘全栈工程师？
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题：MVC框架的发展
08 | MVC架构解析：模型（Model）篇
09 | MVC架构解析：视图（View）篇
10 | MVC架构解析：控制器（Controller）篇
11 | 剑走偏锋：面向切面编程
12 | 唯有套路得人心：谈谈Java EE的那些模式
13 | 特别放送：选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天：从后端到前端
15 | 重剑无锋，大巧不工：JavaScript面向对象
16 | 百花齐放，百家争鸣：前端MVC框架
17 | 不一样的体验：交互设计和页面布局
18 | 千言万语不及一幅画：谈谈数据可视化
19 | 打开潘多拉盒子：JavaScript异步编程
20 | 特别放送：全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑：缓存（上）
22 | 赫赫有名的双刃剑：缓存（下）
23 | 知其然，知其所以然：数据的持久化和一致性
24 | 尺有所短，寸有所长：CAP和数据存储技术选择
25 | 设计数据持久层（上）：理论分析
26 | 设计数据持久层（下）：案例介绍
27 | 特别放送：聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一：配置管理
29 | Ops三部曲之二：集群部署
30 | Ops三部曲之三：测试和发布
31 | 防人之心不可无：网站安全问题窥视
32 | 和搜索引擎的对话：SEO的原理和基础
33 | 特别放送：聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化（上）
35 | 网站性能优化（下）
36 | 全栈开发中的算法（上）
37 | 全栈开发中的算法（下）
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化：让全栈意味着更多
全栈工程师修炼指南
登录|注册
26 | 设计数据持久层（下）：案例介绍
四火 2019-11-08
你好，我是四火。
本章我们已经学习了不少持久化，特别是有关存储的技术。那在实际业务中，复杂的问题是一个接着一个的，面对这些琳琅满目的具体技术，我们该怎样运用自己所掌握的知识，做出合理的选择呢？今天我们就来接触一些典型的系统，看看对于它们来说，该做出怎样的持久化设计和技术选型。我相信我们实际接触的系统也有相当程度的类比性，可以带来应用的参考意义。
搜索引擎
小到 BBS 网站的帖子搜索，大到互联网数据搜索引擎，搜索引擎可以说是我们日常接触的几大系统之一。可是，搜索数据的存储该怎么设计呢？
有一些反应迅速的程序员朋友，也许会设想这样的存储结构，利用关系数据库，创建这样一个存储文本（文章）的关系数据库表 ARTICLES：
那么，假如现在的搜索关键字是“存储”，我们就可以利用字符串匹配的方式来对 CONTENT 列进行匹配查询：
select * from ARTICLES where CONTENT like '%存储%';
这很容易就实现了搜索功能。但是，这样的方式有着明显的问题，即使用 % 来进行字符串匹配是非常低效的，因此这样的查询需要遍历整个表（全表扫描）。几篇、几十篇文章的时候，还不是什么问题，但是如果有几十万、几百万的文章，这种方式是完全不可行的。且不说单独的关系数据库表就不能容纳那么大的数据了，就是能够容纳，要扫描一遍，这里的时间代价是难以想象的，就算我们的系统愿意做，用户可都不愿意等啊。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(3)
Mandalorian类似微信的聊天系统，需要考虑用户关系，消息的从属关系（发送者、接受者、是否群发等等），序列（时间），状态等；
- 首先，聊天中涉及到的图片和文件、视频等内容，肯定时使用文档数据库、对象数据库进行存储；对应的key存放到消息所在的数据表中
- 上面提到的各种关系、对象，其实都有明确的schema；可以使用关系数据库，对关键的字段加索引；在用户数量和消息数量上来之后，可以通过集群分库分表的方式来应对；
- 消息本身保证最终一致性即可，对于公共的消息、群聊的消息等热点数据，可以通过Redis等键值数据库来存储，一方面做读消息的缓存，一方面做写消息的缓冲，异步存储到关系数据库
考虑的还是不够完善，希望开放题目，老师能给出参照答案。作者回复: 其实你提到的部分，分析的内容，将数据分类并应用不同的存储技术这方面，已经说得很好了。没有标准答案，但是在思考这样的设计的时候，可以再尝试进一步，比如你讲的第三点，还是颇为模糊，细化的时候就会发现更多问题需要考虑，比如用户是怎么读写的，你说用关系数据库，那这个关系数据库的 schema 怎么设计，使用缓存的话如果掉电消息丢失怎么解决。
2019-11-13
靠人品去赢其实类似微信的通讯工具，他会在你本地有个类似NoSQL的东西，搜个关键字什么的都支持，但是你发现你要找更久的，他会弹出一个框，你可以设置日期其实这个最后要走的关系型数据库去查询。毕竟大家都把NoSQL作为自己的中间件，提高响应缓冲服务器压力之类的，到最后数据还是要乖乖的存在MySQL这些关系型数据库。2019-11-08
leslie关于老师今天的题目给出两种答案：
一种是文档型数据库mongodb。虽然是NOSQL阵营，但是其支持类SQL且用的是JSON，而现在mysql5.7开始的版本用sql，但是支持JSON；主要是文档型数据库适合这种场景；
另外一种方式就是redis+MySQL：其原因不言而喻了，太多类似方式了2019-11-08
收起评论