26 | 设计数据持久层（下）：案例介绍
四火
该思维导图由 AI 生成，仅供参考
你好，我是四火。
本章我们已经学习了不少持久化，特别是有关存储的技术。那在实际业务中，复杂的问题是一个接着一个的，面对这些琳琅满目的具体技术，我们该怎样运用自己所掌握的知识，做出合理的选择呢？今天我们就来接触一些典型的系统，看看对于它们来说，该做出怎样的持久化设计和技术选型。我相信我们实际接触的系统也有相当程度的类比性，可以带来应用的参考意义。
搜索引擎
小到 BBS 网站的帖子搜索，大到互联网数据搜索引擎，搜索引擎可以说是我们日常接触的几大系统之一。可是，搜索数据的存储该怎么设计呢？
有一些反应迅速的程序员朋友，也许会设想这样的存储结构，利用关系数据库，创建这样一个存储文本（文章）的关系数据库表 ARTICLES：
那么，假如现在的搜索关键字是“存储”，我们就可以利用字符串匹配的方式来对 CONTENT 列进行匹配查询：
这很容易就实现了搜索功能。但是，这样的方式有着明显的问题，即使用 % 来进行字符串匹配是非常低效的，因此这样的查询需要遍历整个表（全表扫描）。几篇、几十篇文章的时候，还不是什么问题，但是如果有几十万、几百万的文章，这种方式是完全不可行的。且不说单独的关系数据库表就不能容纳那么大的数据了，就是能够容纳，要扫描一遍，这里的时间代价是难以想象的，就算我们的系统愿意做，用户可都不愿意等啊。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文通过具体案例深入浅出地介绍了持久化设计和技术选型的实际应用。首先，通过搜索引擎和倒排索引技术的案例，阐述了如何解决关键字搜索效率低下的问题，并介绍了Elasticsearch在大数据量情况下的应用。其次，通过地理信息系统的案例，讲解了如何利用索引和GeoHash技术来优化地理位置搜索的效率。文章强调了在选择技术时，需要针对每一类数据选择“一组”技术，而不是笼统地选择“一项”技术。此外，文章还提出了选择SQL或NoSQL数据库的原则，包括数据分类和数据规模等方面的考量。总的来说，本文通过具体案例和技术原则，为读者提供了在面对复杂问题时进行持久化设计和技术选型的实用指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《全栈工程师修炼指南》，新⼈⾸单¥59
《全栈工程师修炼指南》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
💢 星星💢老师提到了二点前提数据规模和分类 首先微信属于网络通信的一种应用。作为java的化，应该选用netty作为网络通信部分 持久层 对于普通的聊天文字，可采用关系型数据库存储。可能有必要做一下缓存处理，例如查看最 近的聊天记录，可能会采用缓存的数据库 对于图形视频等数据采用文档型数据库存储比较好 对于好友关系，老师上一讲提到图形数据库是不是好？会不会大材小用？作者回复: 是不是"大材小用"要从需求和解决方案两个方面去比较着判断，好友关系的存储可以使用SQL也可以使用 NoSQL来实现，图形数据库确实是NoSQL中常见的一种。
2020-03-17
四喜类似微信的聊天系统，需要考虑用户关系，消息的从属关系（发送者、接受者、是否群发等等），序列（时间），状态等； - 首先，聊天中涉及到的图片和文件、视频等内容，肯定时使用文档数据库、对象数据库进行存储；对应的key存放到消息所在的数据表中 - 上面提到的各种关系、对象，其实都有明确的schema；可以使用关系数据库，对关键的字段加索引；在用户数量和消息数量上来之后，可以通过集群分库分表的方式来应对； - 消息本身保证最终一致性即可，对于公共的消息、群聊的消息等热点数据，可以通过Redis等键值数据库来存储，一方面做读消息的缓存，一方面做写消息的缓冲，异步存储到关系数据库 考虑的还是不够完善，希望开放题目，老师能给出参照答案。作者回复: 其实你提到的部分，分析的内容，将数据分类并应用不同的存储技术这方面，已经说得很好了。没有标准答案，但是在思考这样的设计的时候，可以再尝试进一步，比如你讲的第三点，还是颇为模糊，细化的时候就会发现更多问题需要考虑，比如用户是怎么读写的，你说用关系数据库，那这个关系数据库的 schema 怎么设计，使用缓存的话如果掉电消息丢失怎么解决。
2019-11-13- Geek_74d3ac设计聊天软件的数据库，可以分几方面方面考虑， 在用户元数据方面，由于非常范式化，可以使用关系型数据 而用户关系数据的话，如果只有好友关系，那么使用关系数据库也未尝不可，但是如果考虑后续复杂的关系扩展，上图数据库或许是一种更好的选择 然后是消息聊天，我认为可以做个划分，比如消息本身的元数据，例如时间，收发方等等可以抽出来利用关系数据库管理，而消息内容的丰富性，则应该用文档，甚至对象数据库管理。 另外，聊天应用中，无论是聊天过程，翻阅最近的聊天记录，如果事事都请求服务端，那就太慢了，客户端必然需要建立自己的本地数据的管理机制，这个时候客户端算力也是一个重要的影响因素，往往只能一个轻量的本地数据库方案做全套，因此我觉得设计更加灵活的 noSQL 可能更优。2020-08-13
靠人品去赢其实类似微信的通讯工具，他会在你本地有个类似NoSQL的东西，搜个关键字什么的都支持，但是你发现你要找更久的，他会弹出一个框，你可以设置日期其实这个最后要走的关系型数据库去查询。毕竟大家都把NoSQL作为自己的中间件，提高响应缓冲服务器压力之类的，到最后数据还是要乖乖的存在MySQL这些关系型数据库。2019-11-08
leslie关于老师今天的题目给出两种答案： 一种是文档型数据库mongodb。虽然是NOSQL阵营，但是其支持类SQL且用的是JSON，而现在mysql5.7开始的版本用sql，但是支持JSON；主要是文档型数据库适合这种场景； 另外一种方式就是redis+MySQL：其原因不言而喻了，太多类似方式了2019-11-08
收起评论
