全栈工程师修炼指南
熊燚(四火)
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
收起评论
3
返回
顶部