网站维护是事务最多的事情负荷

多数Web数据库都有人们称之为ldquo;高度事务型rdquo;的事情负荷，你也可能听说过这称为OLTP(在线事务处置)。这名字有点误导，由于这通常并不意味着正在运行金融事务，在SOL意义上甚至也不意味着是数据库事务。通常只是意味着应用程序做一些夹杂着读写一些行或一些行集的事情而已。许多互联网应用都匹配下面的模式。

● 应用程序读得多，读对写的比率局限从读五次写一次到读十次写一次不等，甚至一起飙升到读几百次オ写一次。

● 一次读一行和一次读多行是夹杂泛起的。

● 一样平常来说，写每次只影响一行。



这就是许多人称之为的ldquo;事务型rdquo;负荷。这看起来很正常，但不要假设每个人的负荷都这样。例如，剖析负荷通常都是批量插入，很少或没有更新，以及每次都涉及到整个表的大量读。许多数据库都设计为能很好地处置这种负荷，由于需要剖析数据的营业往往都有海量的数据，而且在特别为数据剖析做过优化的专有数据库上花了大笔的钱。

事务型负荷意味着，除非应用程序设计得很精巧，否则无法只做读取操作(这样设计是个好主意，但这是一个差别的话题)。从运维的角度来说，与一直在线的特点一样，这种事务型负荷也缩小了你的选择空间。

一个相关的方面是数据与查询的简单性。由于基础的数据模型通常都不庞大，以是多数Web应用都天生前述的事务型负荷。若是将典型Web应用的数据模型做上

一些处于中央位置的表通常少于10个。许多这种表都市存储类的数据，如用户，这些数据通常都是以一次一行的方式存取的。

网站的流量很大程度上决议了数据库的流量。用户浏览网站，就会在用户表中对该用户的那行纪录举行读写。浏览网站一样平常都市导致应用程序读取数据集或数据区域来填充页面浏览也会潜在地显示一些统计数据，如你社会网络中的密友数，而要天生这些统计数据，就要做汇总或群集查询。以是，查询通常会知足下面的模式:

● 读写用户表，一次一行。

● 以区域或聚集方式读取用户自己的数据。以区域或聚集方式读取其他用户的数据。

● 从该用户与其他用户的关联表中读取区域行(ranges of rows)。对该用户和其他用户的数据举行汇总与计数。

行的区域与聚集通常是由某些条件将效果限制为前N个(topN)的SQL查询，如最新纪录。这些效果常常是分页的，以是查询条件会是一个偏移量和一个纪录条数的组合。差别的网站建设数据库会用差别的方式来做这样的查询，以是我就不展示详细的查询例子了。p分页题目e

(责任编辑：网络)