秋色园QBlog技术原理解析:性能优化篇:读写分离与文本数据库(十八)

简介:
上节回顾:
 
秋色园 QBlog  对于频繁产生更新操作的访问计数器(用户表及文章表),进行了另一种优化方案处理,使得原来并发进行的操作,变成了定时的单个队列式顺序更新操作,有效的解决了计数器引发的并发的问题。
 
本节概要:
 
虽然减压方案频繁出招,可是依旧没能阻挡住access黄金4K的绝杀。
在压力之下,梦幻潜能再次被激发。
于是,新的绝招再次出世:一个失传已久的招数:文本数据库
 
本节内容:
 
1:分析寻找优化点:
 
通过  CYQ.Data  的 AppDebug(即将发布的V4.5.5版本包含此类),打印出页面的SQL语句:
 
 
PS:关于打印页面SQL语句的优化,可见之前的文章:秋色园QBlog技术原理解析:性能优化篇:全局的SQL语句优化(十三)
 
首先观察页面这些语句,我们看到这里涉及到几条语句:
1:第一次的表架构获取语句,即where 1=2的语句
2:博客用户的信息读取语句
3:友情链接的语句
PS:如果没有缓存,当然还有很多和文章列表相关的语句,文章的下节重点再讲。
 
然后我对着这些语句寻思了很久时间,最后得出结论,得把这些语句消灭掉。
 
2:步步分析并对可优化点进行优化:
 
2.1:消灭表架构读取SQL语句
这个其实关系不大,因为一个表仅读一次,而且之后全局默认缓存30分钟,所以出现频繁非常低,不过了为追求首页0语句,我还是比较严肃的把它给消灭了,怎么消灭的?
消灭其实还是很好解决的,只要首次读取时,把表架构外置到文本中即可,于是架构的读取顺序就变成了:缓存->文本->数据库。
 
下面给一张表架构外置文本和架构外置架构示例图:
 
2.2:消灭用户信息的读取SQL语句
其实用户表是个大问题,经常也会出现的4K,因为有太多的语句,可涉及到用户表的读取。
为此,虽然说用户信息每次读取完后也会进行缓存,但是,用户数量比较多,搜索引擎来来回回,啥用户也会扯到,所以总体来来回回就变的读取相当相当的频繁,为此,我想了一想,把它给消灭了,怎么消灭的?
同理,第一次读取时,我把用户信息外置到文本了,然后用户后台更新数据的时候,也刷新文本。
然后读取自然的顺序就变成了:缓存->文本->数据库。
于是当然的,秋色园现在4000多的用户,就产生了4000多个文本了,看似规模很庞大!
难免有人要发出感叹,要是你100万用户,不就产生100万个文本了?我想说,求之不得啊!
 
下面给一张用户信息文本及用户信息以json格式存储的示例图:
 
2.3:消灭友情链接的读取SQL语句
用户的友情链接,比起用户信息来说,不算重点,不过你会发现,用户的每个页面可都是也有友情链接的。
所以,我打算把它也给灭了,怎么消灭的?
有了上面两步的经验,这步实施起来太easy了,同理,首次把用户的友情链接转存到文件中,然后读取就是文本读取了,后台修改的时候,也是读的文本的,不过写的时候,先写数据库,再写文本。
于是,4000多用户,也会产生4000多的友情链接的文本。
 
下面给一张友情链接的文本及友情链接列表以json格式存储的示例图:
 
2.4:文章列表的SQL语句呢?
这里必须严肃的说一下,大量的文章列表的SQL语句,并没有使用文本的方式进行消灭。
为啥没有呢?
原因也很简单,因为文章列表涉及到查询及排序还有分组等复杂语句,文本不太好操作这些事情。
那文章列表是如何进行的优化,这是个大工程,当时我在外散步连续思考了3天,也是秋色园 QBlog 至今为止的最后一次优化,这么大工程,具体下节详细介绍了。
 
总结:
 
秋色园 QBlog 通过借助于文本,将大量的读取数据库转移到文本读取中,有效的降低了数据库的压力,同时网站运行也顺畅了很多。
经过一场应用之后,对文本有了第一印象:
优点:速度快,小数据量(10万或10M上下)简单的存储与读取非常方便。
缺点:删除,更新,查询,分页,排序及并发控制等操作复杂,而且数据量也不适合太多。
 
另外据网上搜索“文本数据库”的结果看来:
文本数据库以前在php界很流行,多数论坛都采用文本数据库,而且抗并发能力相当强,当然这背后相信有一定的技术手段在处理,然后后来的后来,php基本都统一mysql了。
至于.net界,文本数据库却从没流行过,这是为什么呢?
 
历史文章回顾:
1:  秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用
2:  秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程
4:  秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序
5:  秋色园QBlog技术原理解析:Module之页面基类设计(五) --介绍创建基类和自定义生命周期
12: 秋色园QBlog技术原理解析:性能优化篇:字节与缓存与并发(十二) --介绍性能优化:字节,并发及缓存
附章:
 
 


     本文转自cyq1162 51CTO博客,原文链接:http://blog.51cto.com/cyq1162/633035 ,如需转载请自行联系原作者





相关文章
|
12月前
|
存储 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:单机性能优化篇
阿里云PolarDB云原生数据库在TPC-C基准测试中,以20.55亿tpmC的成绩打破性能与性价比世界纪录。此外,国产轻量版PolarDB已上线,提供更具性价比的选择。
|
SQL 数据挖掘 测试技术
南大通用GBase8s数据库:LISTAGG函数的解析
南大通用GBase8s数据库:LISTAGG函数的解析
|
10月前
|
存储 缓存 自然语言处理
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
312 8
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
|
8月前
|
SQL Java 应用服务中间件
数据库连接池详解及性能优化趋势
Sharding-JDBC所构建的Database Mesh与Service Mesh相互独立,协同工作。服务间的交互由Service Mesh Sidecar负责管理,而基于SQL的数据库访问则交由Sharding-JDBC-Sidecar处理。业务应用无需关心物理部署细节,实现真正的零侵入。Sharding-JDBC-Sidecar与宿主机生命周期绑定,非静态IP,确保了动态和弹性。尽管如此,数据运维操作仍可通过启动Sharding-JDBC-Server进程作为静态IP入口,借助命令行或UI客户端轻松完成。
|
9月前
|
存储 关系型数据库 数据库
高性能云盘:一文解析RDS数据库存储架构升级
性能、成本、弹性,是客户实际使用数据库过程中关注的三个重要方面。RDS业界率先推出的高性能云盘(原通用云盘),是PaaS层和IaaS层的深度融合的技术最佳实践,通过使用不同的存储介质,为客户提供同时满足低成本、低延迟、高持久性的体验。
|
12月前
|
存储 关系型数据库 分布式数据库
登顶TPC-C|云原生数据库PolarDB技术揭秘:单机性能优化篇
日前,阿里云PolarDB云原生数据库以超越原记录2.5倍的性能一举登顶TPC-C基准测试排行榜,以每分钟20.55亿笔交易(tpmC)和单位成本0.8元人民币(price/tpmC)的成绩刷新TPC-C性能和性价比双榜的世界纪录。 每一个看似简单的数字背后,都蕴含着无数技术人对数据库性能、性价比和稳定性的极致追求,PolarDB的创新步伐从未止步。「阿里云瑶池数据库」公众号特此推出「PolarDB登顶TPC-C技术揭秘」系列硬核文章,为你讲述“双榜第一”背后的故事,敬请关注!
登顶TPC-C|云原生数据库PolarDB技术揭秘:单机性能优化篇
|
机器学习/深度学习 人工智能 自然语言处理
深度解析Recraft V3:突破文本渲染限制,文生图黑马是怎样炼成的?
Recraft V3模型在文本生成图像(Text-to-Image)领域取得重大突破,通过创新的"Bridging Text Spotting"方法,解决了传统方法中误差累积和性能不佳的问题。该模型采用独立训练的检测器和识别器,并引入Bridge和Adapter机制,确保高质量图像生成。Recraft V3在多个数据集上表现优异,如Total-Text准确率达83.3%,ICDAR 2015达89.5%。其应用前景广泛,涵盖广告设计、教育和娱乐等领域,为文生图技术的实际应用提供了新可能。
596 27
|
机器学习/深度学习 人工智能 自然语言处理
秒级响应 + 99.9%准确率:法律行业文本比对技术解析
本工具基于先进AI技术,采用自然语言处理和语义匹配算法,支持PDF、Word等格式,实现法律文本的智能化比对。具备高精度语义匹配、多格式兼容、高性能架构及智能化标注与可视化等特点,有效解决文本复杂性和法规更新难题,提升法律行业工作效率。
894 9
|
前端开发 UED
React 文本区域组件 Textarea:深入解析与优化
本文介绍了 React 中 Textarea 组件的基础用法、常见问题及优化方法,包括状态绑定、初始值设置、样式自定义、性能优化和跨浏览器兼容性处理,并提供了代码案例。
451 10
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
2031 5

热门文章

最新文章

推荐镜像

更多
  • DNS