实时数据库

国产实时数据库真的比洋品牌差吗

Linkman的学习记录 — Fri, 28 Nov 2008 16:35:00 GMT

国产实时数据库真的比洋品牌差吗？我不信。

一个月之前，我们与某公司商谈合作，讨论将我们的实时数据库OEM到他们的MES系统中，这个公司的老总是我多年的老相识，也是多年的老朋友，他这么对我说：老Linkman呀，我们合作吧，在2万点以下这一档次，我们公司全面OEM你们的实时数据库，2万点以上，我们还是准备使用国外的实时数据库产品，毕竟，在2万点以上的系统中，国外的实时数据库产品的性能和稳定性要强于国产实时数据库产品。

听到这些话，我有点欣慰，也有点失落。欣慰的是，曾几何时，一提到实时数据库，大家都只能想到国外的实时数据库产品，铁定只选用国外的实时数据库产品，根本不会考虑国产实时数据库，现在，至少在2万点这一档次上，我们已能与国外的实时数据库产品正面抗衡，很多用户已经认为国产实时数据库是一种很好的选择；失落的是，我们要真正证明自己，还有很长的路要走，即便我们说自己行，那也不一定行。

我当时并没有说任何话，能争取到2万点系统的OEM，对我们来说，已经是一个很大的胜利，只要给我们机会，我们就能更好地证明自己，再多的空话也是多余，先将眼前的事情做好吧，但我有理由相信，最多再过一年，我的那位朋友的观点会改变，我们值得他选择。我有这个自信，因为我熟悉我们产品的每一处细节，知道她的真正情况，也知道他的真实能力，就象了解我的小孩的每一处细节一样。

这一次投标更有意思，国内国外多家实时数据库厂家在客户现场直接PK，由我们与客户一起来做各种功能和性能测试，当我们做完了实验，提交了测试报告之后，客户的一位主管要求我们重做某一项实验。我们很配合地重做了这项实验，最终实验效果比我们第一次做的实验的效果还要好。

下面是这次测试的服务器配置：

数据库服务器硬件配置
名称	型号及说明	配件数量	数量
CPU	四核 Intel xeon x5450 3Ghz	2	1
内存	8G DDR2	1
硬盘	146G 15krpm SAS	1
网卡	千兆	1
数据库服务器软件环境
名称	型号及说明
操作系统	Windows Server 2003中文版
C盘剩余空间	4.12G NTFS
D盘剩余空间	128G NTFS

重做的实验为“以1秒为单位采集及写入数据时，记录服务器的各种负荷”，具体要求为：由客户工程师监护，实时数据库厂家做将采集模拟器放在与服务器不同的客户机上，以1秒为单位模拟采集及写入试验，并记录不同实时数据库容量下，服务器的各种负荷。

操作步骤：

A、启动实时数据库，数据库中已保存需测试的工程测点，总容量为60万点；

B、启动模拟采集器，以1秒为单位产生模拟数据，分别产生30万点、60万点的测试数据；

C、连续运行30分钟；

D、观察数据是否能够在规定的时间内写入，记录每次测试的CPU负荷等；

下面是测试结果：

服务器容量	60万点
工程测点总容量	60万点
数据是否全部保存	是，40万个模拟量，12万个整型量，8万个开关量
失真率是否满足要求	是，模拟量失真度0.5%，其它不失真
数据波形是否符合要求	是，模拟量和整型量以幅度100，周期300秒的正弦，开关量周期60秒
模拟器数据产生频率	1秒
是否能够在规定的时间内写入数据库	能

实时数据库服务器运行状态记录

观察时间	点数 (万)	CPU使用	物理内存使用	最高单核CPU使用	虚拟内存	备注
13:05	30万	6%	446M	38.9%	283M	一个模拟器，同步送30万点
15:48	60万	9%	558M	22.2%	305M	两个模拟器，分别异步送30万点。

下图是以单模拟器1秒同步插入30万点时的CPU负荷图：

800)this.width=800" border=0>
下图是以两个模拟器以1秒为单位异步插入60万点时的CPU负荷图：

800)this.width=800" border=0>

这个实试说明以下几个问题：

A、我们的实时数据库可以轻松地实现单服务器60万点容量（后来我自己又做了单服务器90万点容量的插入实验，性能同样不错）；

B、将模拟器的数据由1个改为两个，通讯方式由同步改为异步时，性能大大提高，终于利用了客户那么高档的多CPU多核计算机的优势，而且，随着模拟器数量的增加和通讯客户端的增加，利用多核的优势越明显；

C、我们的实时数据库性能还有很大提升空间，如果在程序设计中充分考虑多核的并发处理，性能至少可以提高3-4倍。或者，直接运行3-4个实例，那样，我们的单台实时数据库服务器可以轻松地支持200万-300万点。

我能想象得到，这位主管为什么要让我们重做这项实验，因为在这一证明实时数据库性能的实验中，我们的试验数据甚至比国外的实时数据库的性能指标还要高得多，他有理由怀疑，我们是不是在作假，而我们毫不犹豫地配合重新做了这个实验，并愿意在不同环境下重做（不同的计算机、更长的实验时间，不同的网络环境等），更说明我们的自信，只有这样，我们才能得到用户的认可和尊重。

都说国外的实时数据库要比国内的实时数据库强，我一直不服气，相信国产实时数据库能超越那些国外的品牌，不仅仅是某一项指标，而是全面超越，不仅仅是内核，而是整体，不仅仅是性能，而是包括性能、功能和稳定性，我已为这个信念投入了三年的时间，而且以后愿意投入更长更多的时间，相信在不久的将来，我们可以真正得到用户的认可，可以在高端实时数据库市场与国外实时数据库产品全面抗衡，乃至超越，乃至战胜！

实时数据库在大型远程移动监控系统中的应用要点（三）

Linkman的学习记录 — Tue, 18 Nov 2008 16:01:00 GMT

本章讨论“使用分布式实时数据库服务器解决超大容量实时和历史数据访问”的问题。

在开发远程移动监控系统时，一般有两种技术路线，一种是直接开发针对特定行业特定应用的系统，另一种是选用组态软件进行二次开发，这两种技术路线各有优缺点。当管理功能是远程移动监控系统的主要功能点，或者监控对象具有非常独特的行业特性，直接开发应用系统是一种合理的选择。而当监控功能是远程移动监控系统的主要功能点时，选用合适的组态软件，可以减少投入成本，缩短项目周期、提高系统稳定性，减少失败风险。

不管采取以上哪种技术路线，都不可避免地要对一个问题进行决策：如何保存采集到的数据。保存的概念包括三个方面：内存中保存的实时数据，磁盘上保存的历史数据，针对实时数据和历史数据的访问接口。可以选择的方案有五种：

1、组态软件本身的内存和历史数据库（或模块）；
2、自定义的内存和文件格式；
3、关系数据库；
4、实时数据库；
5、关系数据库+实时数据库；

针对以上两种不同的技术路线，可以选择不同的数据保存方案，当需要采集和保存的数据点达到一定的规模时，就需要采用方案4或方案5，在我的上一篇文章《实时数据库与组态软件的市场定位之异同》中，提到了依据工程总点数和需保存的总点数来决定是使用实时数据库还是组态软件，在远程移动监控系统中，当系统的点数规模超出了组态软件能处理的范围时，关系数据库也同样不能处理。

还是以那个重型机械厂的项目为例说明，如果按照每台车辆每10秒向上传送一次数据，每次传送100个数据，车辆总数按50000台计算。
如果采用Oracle关系数据库来存贮实时和历史数据。对数据的保存有两种方式，这两种方式也决定了上层Oracle数据库的数据表设计方案。

第一种方案是每个车辆设备的数据用一条记录来表示，每条记录有100个字段，这样设计的好处是采集服务器操作ORACLE服务器的事务数比较小，平均每秒钟的插入事务数为50000*5/60=4167条。该方式的缺点是，对不同的DTU需要设计不同的数据表；数据不能被压缩，磁盘空间占用非常大，如果每条记录按1K来计算，则一年需占用的磁盘空间为：356*24*60*60/5*50000*1024=293335G，再加上索引等辅助内容，整个系统一年所占用的磁盘空间约为400000G。

第二种方案是每个车辆设备的数据用多条记录来表示，每条记录只记录该DTU中某一个具体的数据点，这样处理，Oracle服务器的事务数达到每秒钟50000*100*5/60=416667次，在这种情况下，对数据可以采取一些压缩处理，系统一年所占用的磁盘空间与第一种方案相比，可以减少到1/10左右，约为40000G。

不管是采用以上的哪一种方案，都存在单位时间的读写次数达到系统处理上限，系统容量超出系统上限等困难，导致系统无法使用。可以通过引入网格数据库，或重新规划需保存的历史数据等方式解决这些难点问题，但都存在缺点，不是价格高，就是不得不损失相应功能。

引入实时数据库，只能部分解决此问题，举例说明，如果使用我们的实时数据库，单台服务器只能处理5000台左右车辆设备的数据采集和保存问题（经过定制改造，如果不改造，单服务器只能处理1000台车辆设备，该问题的瓶颈不在于性能，而在于点数限制，目前我们的标准实时数据库单台服务器只支持126000个数据点），仍不能处理高达50000台车辆设备。

这时，需要使用分布式实时数据库服务器来解决超大容量实时和历史数据访问，如下图所示（图略）。

可以看到，单台服务器处理5千台设备，处理的数据点为50万个，10台实时服务器能处理5万台设备，处理的总数据点为500万个，调度服务器对这10台服务器进行调度，使得10台服务器对外部而言（包括采集服务器和客户端）是透明的，外部只看到一台能处理500万数据点的大型实时数据库。

要实现一个分布式分布式实时数据库服务器，可能做得非常复杂，但对于大型远程移动监控系统中，可以简化处理，当然，这需要实时数据库支持层次点系统、设备模块、在线修改等功能的辅助支持，关于这方面的内容，在下一章中加以说明。

实时数据库的压缩率是怎么算出来的？

Linkman的学习记录 — Tue, 18 Nov 2008 15:59:00 GMT

各个实时数据库厂家，都会在自己产品的宣传手册或说明书中，标明自己的压缩率能达到多少多少，或是“10:1”或是“20:1”，这些数字是怎么算出来的呢？

标准答案是：没法算出来。

压缩率的表示方法“N:1”，隐含了两个概念：参照物和测试环境。也就是说，在某种测试环境下，保存同样的数据，实时数据库可以达到参照产品的1/N。

这里的参照物有两种可能性，可以是压缩之前的原始数据，也可以是另一种典型的存贮系统，比如关系数据库。这里的测试环境，应该是某种人为约定的标准输入。关键的问题是，我们能找到一种能近似模拟工控设备数据源的标准输入吗？如果不能找到合适的测试数据，那些测试结果又有多大的价值呢？

实时数据库应用在过程控制及相关行业，在这个领域中，数据具有如下特征：

最常见的数据是模拟量，也有一部分开关量；
数据中只有一小部分值经常发生改变，很多开关量常期不变化；
数据的变化具有一定波形规律；
很多数值都具有慢变化的特征；
数值变化与时间变化具有共同变化特性；
用户在一定范围内，能够允许数据的精度损失；

我们能找到一组模拟以上特性的测试数据吗？聪明的观众肯定会自然地想到，可以用正弦曲线来模拟。只要测得针对正弦曲线的数据压缩率，就能定性（但不能定量）地判断出某实时数据库的大体数据压缩性能。

可是，即便采用正弦曲线来模拟，还需要考虑很多其它因素。

A、取样密度
对于同一条正弦曲线，比如1分钟变化一个周波，如果取样密度不一样，所得到的取样点数是不一样的。如果每秒钟取一个点，可以取得60个点，如果每0.1秒取一个点，可以取得600个点，再极端一点，如果1毫秒取一个点，可以取得60000个点。我们假定可以用一些特征点来描述该曲线，则取样密度越大，数据冗余度越高，数据压缩率就越高。如果某实时数据库产品宣称自己的数据压缩率为1000:1，你也不要认为他在吹牛，他也许就是对以毫秒为单位取样的1分钟变化一个周波的数据进行压缩呢。

B、数据精度
保存一个双精度数比保存一个单精度数所需要的空间肯定要大。但在很多过程控制应用中，单精度数完全足够了。

C、数据范围
数据范围可能影响数据精度。

C、数据失真率
如果用户不允许任何失真，那就是无损压缩。但事实上，工控行业就是一个不可能完全不失真的行业（详见我的博文《关于变位压缩的讨论》）。

聪明的观众看到这儿，肯定就会说，那好办，制定一个统一的标准，以1秒钟作为取样密度，取单精度数，以1分钟变化一个周波，数据范围为-100至100，失真率设为0.5%，将各个实时数据库产品都运行起来，看看各个实时数据库厂家的数据压缩率到底是一个什么样的值。

这个方法确实可行，可是，会有一些实时数据库厂家站出来说，只有这些还不够，还要考虑以下因素：

A、时间精度
大家部实时数据库支持精确到毫秒，但部分厂家在这上面打起了节省空间的算盘，只精确到5毫秒，或只精确到100毫秒，并很严正地宣告，在常规实时数据库应用中，精确到毫秒完全没有意义。

B、测点数
有一些实时数据库对多个测点的数据压缩与对单个测点的数据压缩，效果是有区别的（这个地方我卖个关子，有谁能猜得出来吗？）

C、测试时间
大部分实时数据库为了减少磁盘读写时间，对磁盘空间都是预分配的，系统初始化后，就预先申请了一大块磁盘空间，你怎么测试它保存数据花了多少空间呢？

聪明的观众会继续聪明地说，再加约束条件，所有的时间精确到1毫秒，统一测试1万点，统一运行一个月，现在总可以了吧。

差不多了（还有一些其它因素，就不再罗列，否则有人会说我是唐僧），如果按照这个标准来测，呵呵，大家会发现，每一家实时数据库的测试结果都比他们的宣传要低几倍。

但这些实时数据库厂家也有理由，这种测试本来就不能完全模拟工控现实情况呀，工控现场有开关量，有整型量，还有个别字符串量，还存在很多大部分时间不变化的量，这些因素，是要考虑进去呀。

OK，这么多理由，那你告诉我你的数字怎么来的吧。他们会这么答复：我们是从多个典型工程的多年对比数据中统计而来的，这些数据，如果用关系数据库来存贮，需要比实时数据库30倍的空间（PI是这么回答的）。

有实验报告吗？没有！

在“2008远程自动化高峰论坛”演讲PPT之解说版（二）

Linkman的学习记录 — Tue, 18 Nov 2008 15:59:00 GMT

PPT：

1. 实时数据库的基本概念

解说：

虽然演讲的主题及标题找在十多天以前便定下来了，但到底该在“2008远程自动化高峰论坛”演讲些什么内容，这是一件令人难以决策的事情。既然是论坛，就应该淡化商业色彩，不要将演讲变成对公司实时数据库产品的发布宣传；既然是高峰论坛，所演讲的内容就应该有点高度和深度，不要将演讲变成对实时数据库的科普介绍和扫盲培训。

如果要演讲组态软件或采集板卡，我不需要从最基本的概念说起，因为在工控行业这些产品应用得非常广泛，已达到耳熟能详的程度。但是，实时数据库在国内的工控行业被知晓和认可的程度还很不够。这次高峰论坛，虽然参加的人员是来自各行各业的专家，我还是想先介绍一些基本概念。

PPT：

1.1. 实时数据库的功能

可以对海量数据进行：

l 采集

n 滤波

l 处理

n 量程变换

n 报警处理

n 事件通知

l 压缩

l 存贮

l 计算

l 查询

l 统计

解说：

因为面对的是非实时数据库专业的人员，而且，面对的受众大多是各行各业对监控软件熟悉的专家，我没有讲太多关于实时数据库理论方面的内容，只描述了实时数据库核心模块的所应该具备的基本功能。

这个功能描述，可以对比一下组态软件能完成的功能，可以看到，实时数据库核心模块所能完成的功能，比组态软件多一个“压缩”；比组态软件小一个“界面展现”；另外，它们之间处理数据量有区别，实时数据库能处理“海量”数据。

“海量”数据具体是一个什么概念呢？可以参考我的博文“实时数据库与组态软件市场定位之异同”，那里面提到了两者之间点数的大致区别。

从上面的描述可以看到，实时数据库的功能其实很简单，就是完成对工业数据的采集、实时处理、存贮。实时数据库能与其它产品有区别且能有自己的市场定位在于，实时数据库能高性能地完成这几项简单的工作。实时数据库的核心价值在于它的性能，一个性能平庸而功能完备的实时数据库没有任何市场生存空间。

PPT：

1.2. 与关系数据库的区别

强化和弱化，通用和专用：

l 表关系的复杂度

l 测点数量

l 数据插入速度

l 数据查询速度

l 保存的历史数据容量

l 工业业务逻辑

解说：

几乎所有人都了解关系数据库，因此，如果能够以关系数据库的概念去理解实时数据库，并搞清他们之间的区别，即能对实时数据库有一个基本而大概的了解。

关系数据库的发展历史非常长，它能以事务处理作为理论基础，以三范式作为构建基础，由小至大，以简单地逻辑能描述复杂的世界，因此，它具有通用而广泛的应用空间。但是，当由于性能等原因而不能使用关系数据库时，就需要使用其它存贮解决方案，实时数据库因此而产生。

关系数据库的定位在于通用商业应用，如果我们将这个范围减少，针对某具体应用领域的应用特征对关系数据库作限定和优化，就可以形成各种不同的类数据库系统。实时数据库就是这样的类数据库系统。

在工业相关的行业，生产过程数据是一种结构简单、关系简单的数据，它具有随时间而变化的简单特性，同时，它所产生的历史数据量非常大，针对这种应用，我们可以设计出非常简单的表结构，设计非常简单的表关系，并针对实时和历史数据的特点，设计出特定的处理功能，设计出特定的数据压缩算法以及存贮逻辑，就形成了实时数据库。

上面解释了实时数据库所具有的“专用”的特性，也解释了实时数据库的强化和弱化的特性，同时解释了实时数据库的工业业务逻辑。

这些弱化和专用的目的，就是为了针对工业过程数据的应用，达到如下几个目标：

l 能处理尽可能多的测点数量；

l 能以尽可能快的速度插入和查询数据；

l 能尽可能多尽可能快地保存历史数据。

关系数据库、内存数据库、实时数据库的简单比较

Linkman的学习记录 — Tue, 04 Nov 2008 03:38:00 GMT

　很多情况下，用户会将实时数据库与关系数据库混为一谈，实际上，这两类产品的设计理念及应用场合是完全不同的。

内存数据库就是将数据放在内存中直接操作的数据库，它利用内存的读写速度比磁盘快、内存是随机访问而磁盘是顺序访问这两个特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。

而实时数据库不但利用了内存的特性，而且考虑到工控行业的应用特性，将关系数据库的表结构和表关系简化，以进行性能的优化，并针对工控行业的数据特性，对数据进行压缩处理。

关系数据库、实时数据库与内存数据库相比，有如下差别：

比较项目	关系数据库	内存数据库	实时数据库	说明
表结构	完整	完整	简化	实时数据库不能处理复杂的表关系，但在特定行业的应用中，比如工控监控软件中，不需要复杂的表关系
每秒读写速度	3000	50000	500000	内存实时数据库比关系数据库快10倍左右，实时数据库比内存数据库快10倍左右
历史数据压缩	无	无	有	实时数据库比内存数据库的压缩率能达到20~40倍
4G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）	5小时	5小时	8.5天	在4G内存的情况下，在单服务器处理30万点的情况下，内存数据库只能存贮5小时以内的历史数据，在带索引时，只能保存3小时以内的历史数据。(详见我的博文《实时数据库存贮容量计算方法》)
128G空间能存贮30万个测点的每秒变化一次的历史数据（不带索引）	7天	7天	269天	内存数据库有般用在电信行业，国内电信行业应用的最大项目也就使用了90G内存，在128G内存下，内存数据库也只能保存7天的历史数据
是否需要历史数据库	不需要	需要	不需要	内存数据库还需要配套使用历史数据库，且历史数据库同样存在不能压缩、不能保存长时间海量历史数据的问题

从以上的表格可以看出，内存数据库与关系数据库相比，速度快10-20倍左右，且具有与关系数据库类似的完整表结构，因此在电信业处理大量实时事务业务时经常用到，它也可以应用在工控行业，比如，在很多电力行业SCADA软件中，都包含了一个小型的内存数据库系统（但不是真正意义上的内存数据库），但是，在超大型SCADA软件中，它仍不能满足需求，因为它性能比实时数据库慢10倍，且不能解决历史数据存贮的问题，还存在因为掉电导致大量数据丢失的风险。

以上的比较，指标并不全面，也并不是说，实时数据库一定比关系数据库和内存数据库好，只能说，需要针对不同应用的不同需求，做出综合决策，选择最适合自己需要的数据库产品。

最后，列举一些典型的内存数据库产品：

■ Oracle TimesTen

Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。

■ Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适合于有高时效要求的实时系统。

■ eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。

实时数据库在大型远程移动监控系统中的应用要点（二）

Linkman的学习记录 — Mon, 13 Oct 2008 12:26:00 GMT

这一章重点讨论在大型远程移动监控系统中网络方面需要处理的问题。

随着移动设备数量的增加，需传输的数据量、对网络带宽的占用、单台服务器的负载等都会随之增长，在设计大型远程移动监控系统时，需要考虑增长的趋势以及增长对系统的影响，做出定量分析和定性判断，在必要时做出增加服务器、改造网络等系统重构决策，并要确保系统重构不对现有系统结构、软件架构产生冲击。

对网络带宽的影响有如下因素：

单台移动设备单位时间内的数据上传量

假定每台移动设备需要传送的总量为100个，这些变量中，开关量和模拟量是各占一半，再考虑到大部分变量都是慢速变化量的特性，并在移动设备本地采用一些简单的数据压缩算法，每次需上传的数据量还可以更低。可以将每台移动设备每一分钟上传的数据量，控制在平均500-1K字节之间。

数据中心与电信之间的网络带宽

GPRS理论带宽可达171.2Kbps，实际应用带宽大约在40~100Kbps；CDMA 1x理论带宽可达300Kb/s，目前的实际应用带宽大约在100Kb/s左右。在TCP/IP协议上，每一秒钟能够传输的数据量为3K-9K左右，移动设备端不会出会通讯带宽瓶颈。但随着移动设备数量的增加，数据中心与电信之间则有可能出现带宽瓶颈。

按照10000台移动设备计算，如果每台移动设备每一分钟传送的数据量为1K字节，则数据中心与电信之间的理论带宽为10000*1024*2*8/60=2.5Mbps，再考虑到GPRS网络的不稳定性，数据传输的时间不均匀性，可以将该带宽值*4倍，即在10000台移动设备的情况下，数据中心与电信之间的网络带宽应设计为10Mbps左右。

单台服务器的处理性能

对于单台服务器的处理性能，需要考虑在操作系统下，单台服务器能够处理的最大连接数。单台服务器能够处理的最大连接数由以下几个因素决定（以linux为例）：

A、Linux内核支持的最大socket连接数，现有linux默认支持的最大socket连接数为2048，但可以通过修改内核的方法调整该值；

B、服务器支持的最大内核信号量，该内核信号量用于网络连接处理、数据库访问等一系列多进程或多线程处理的数据同步。linux服务器版本设置的全系统支持的信号量虽然有上万个，但是分配给每个用户的数目一般为200-500之间，对于通讯服务器往往是不够的。可以通过修改内核信号量参数来适度增大该值；

C、服务器内存及在合理的CPU负荷率情况下，能支持的最大连接数。

以上对性能参数的分析，只有定性分析，没有定量分析，只能通过经验值进行调整。目前，一般的单台linux服务器能够支持的连接数为2000-4000个，业界也有通过调整内核、程序优化等手段，将单台linux服务器支持的连接数指标提高到20000个，但那样花费在linux内核调整、linux的TCP协议栈的程序修攺等方面所作的工作非常之大，在很多时侯是得不偿失的。

为了使得大型远程移动监控系统能够在移动设备数量扩展的过程中，能够达到只增加服务器（最好能实现动态在线增加服务器）、不需要重构软件系统的目标，必要要在系统中引入支持负载均衡的多采集服务器群集。

目前，业内通用的负载均衡方法有两类，一类是硬件解决方案，一类是软件解决方案。

硬件解决方案主要是引入支持负载均衡的路由器或防火墙来实现，是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。

目前，许多厂商推出了专用于平衡服务器负载的负载均衡器。目前负载均衡器生产商有：Intel、Alteon Web、Arrow Point(已被思科并购)、Coyote Point、F5 Networks、Foundry Networks、HydraWeb以及 RADWare等。负载均衡器的形式多种多样，作为启动器，它以各种形式和大小出现。一些厂商，如Alteon、ArrowPoint，将负载均衡器集成到交换设备中，置于服务器与Internet链接之间；而另外一些厂商，如Coyote Point、 F5 Networks 以及HydraWeb，则运用两块网络适配器将这一功能集成到PC中，其中一块连接到前端止于Web服务器的Hub上，另一块通过路由器或其他设备连接到Internet上。一旦负载均衡设备检测到所管理的每台服务器承载的负荷量，它会按照一定的算法来分配通信。

而软件方案则有如下选择：
动态DNS方法；
反向Proxy方法；
NAT（网络地圵转换方法）；
IP隧道方法；
直接IP路由方法；

这些方法各有其优缺点，在大型远程移动监控系统中，我们选用NAT方法来实现分布式数据采集及负载均衡。

NAT（Network Address Translation网络地址转换）的工作原理修攺IP包的报文头，报文头（目标地址、源地址和端口等）被改写后，客户相信它们连接一个 IP 地址，而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由此，可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址上的一个虚拟服务。

在一组采集服务器前有一个调度服务器，移动设备连接数据中心时，请求报文到达调度服务器，调度服务器根据连接调度算法从真实的采集服务器中选出一台服务器，将报文的目标地址改写为选定服务器的地址，报文的目标端口改写为选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度服务器在连接表中记录这个连接，当这个连接的下一个报文到达时，从连接表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自采集服务器的响应报文经过调度服务器时，调度服务器将报文的源地址和源端口改为对应的IP地圵和相应的端口，再把报文发给移动设备。当连接终止或超时，调度服务器将这个连接从连接表中删除。这样，移动设备所看到的只是一个固定的IP上提供的服务，而采集服务器的集群的结构对用户是透明的。

这种负载均衡方案存在两个缺点：

1、调度服务器存在单点故障，即调度服务器出故障后整个系统会出会故障，这个问题可以通过双机冗余方案来解决。

2、调度服务器可能存在性能瓶颈，从目前已运行系统的经验数据来看，调度服务器在连接20台以上的采集服务器时，将会出现性能瓶颈，但这已足够大多数应用的需求了。

这是什么概念呢？简单总结一下：通过负载均衡技术，单采集服务器可以支持3000个移动设备，最大可以支持20台服务器，最大可以支持60000个移动设备。

实时数据库在大型远程移动监控系统中的应用要点（一）

Linkman的学习记录 — Sun, 12 Oct 2008 14:38:00 GMT

刚出差回来，在整理邮件时，收到一封控制工程中文网发来的“邀您参加2008远程自动化高峰论坛”的邮件，打开一看，呵呵，我们公司是赞助商之一。有兴趣者可以点击以下网址查看详情：（http://www.cechinamag.com/event/SCADA2008/eletter.htm）。

既然我们公司也是赞助商之一，肯定要写写文章捧捧场。刚好，这次出差，与一家重型机械厂家谈项目合作时，就大型远程移动监控系统中的技术要点进行了深入的讨论，在此，将一些想法写出平，权当抛砖引玉。

远程移动监控系统的概念是，通过安装在移动设备（如车辆、船舶、仪器等）上的现地数据采集设备，以无线通讯技术将移动设备的信息传送到中心站点，在中心站点实现远程监控、维护、管理及其它扩展应用。而当系统需要管理的移动设备达到一个非常大的数字时，便可称之为大型远程移动监控系统。

大型远程移动监控系统到底是一个什么样的系统呢，还是以这个重型机械厂家的项目为例进行说明：该厂家生产重型机械车辆，在每台出厂的车辆上都安装了现地监控设备和GPS定位系统，通过GPRS网络向厂家实时发送车况信息，发送频率为1-10秒钟一次，需要发送的数据量为100-200个，现在安装车载设备的车辆达到了3000台，系统最终的规模会达到50000台车辆，在厂家需要对所有安装了车载设备的车辆进行远程监控，实现对车辆的地理定位、实时车况监控、远程维护、客户服务等功能。

可称之为大型远程移动监控系统的项目比较多，我就不一一例举了。这类应用，应该是未来几年远程监控系统的新应用热点，瞄向这类应用的不单单有厂家、集成商，还包括移动公司，移动公司专业就此成立了M2M部门。

部分常规远程SCADA技术仍可以应用在大型远程移动监控系统中，但是，由于系统的规模的扩大，许多常规远程SCADA技术已无能为力，需要应用新的解决技术。归纳起来，在大型远程移动监控系统中需要处理如何几个要点：

1.使用负载均衡技术和多采集服务器解决超大容量网络传输及网络数据接入问题。

2.使用分布式实时数据库服务器解决超大容量实时和历史数据访问问题；

3.通过设备模板、功能模板、画面模板、脚本语言、在线数据修改功能，实现移动设备的动态管理，包括移动设备的动态加入、在线、停运等自动维护功能；

4.现地引入GPS模块，后台的SCADA软件与GIS软件的溶合，实现对移动设备的工况和地理位置的统一处理；

5.实时数据库与关系数据库的配合使用，提供易用接口和二次开发接口，实现扩展管理应用；

后续文章，将就以上问题一一展开讨论，敬请期待。

文章来源:http://blog.gkong.com/more.asp?name=linkman&id=64113

实时数据库中故障恢复PPT

Linkman的学习记录 — Sat, 27 Sep 2008 03:47:00 GMT

提纲
1 关系数据库中故障恢复理论
 实时数据库中故障恢复实现
 参考书目
1 关系数据库中故障恢复理论
1.1 数据库恢复概述
1.2 故障的种类
1.3 恢复的实现技术
1.4 恢复策略
1.5 具有检查点的恢复技术
1.6 数据库镜像
1.1 数据库恢复概述
• 故障是不可避免的
– 计算机硬件故障
– 系统软件和应用软件的错误
– 操作员的失误
– 恶意的破坏
• 故障的影响
– 运行事务非正常中断
– 破坏数据库
1.1 数据库恢复概述（续）
• 数据库管理系统对故障的对策
– DBMS提供恢复子系统
– 保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态
– 保证事务ACID
• 恢复技术是衡量系统优劣的重要指标
1.2 故障的种类
1.2.1 事务故障
1.2.2 系统故障
1.2.3 介质故障
1.2.1 事务故障
• 什么是事务故障
– 某个事务在运行过程中由于种种原因未运行至正常终止点就夭折了
• 事务故障的常见原因
– 输入数据有误
– 运算溢出
– 违反了某些完整性限制
– 某些应用程序出错
– 并行事务发生死锁
– 。。。。
事务故障的恢复
• 发生事务故障时，夭折的事务可能已把对数据库的部分修改写回磁盘
• 事务故障的恢复：撤消事务（UNDO）
• 强行回滚（ROLLBACK）该事务
• 清除该事务对数据库的所有修改，使得这个事务象根本没有启动过一样
1.2.2 系统故障
• 什么是系统故障
– 整个系统的正常运行突然被破坏
– 所有正在运行的事务都非正常终止
– 内存中数据库缓冲区的信息全部丢失
– 外部存储设备上的数据未受影响
系统故障的常见原因
• 操作系统或DBMS代码错误
• 操作员操作失误
• 特定类型的硬件错误（如CPU故障）
• 突然停电
系统故障的恢复
• 清除尚未完成的事务对数据库的所有修改
– 系统重新启动时，恢复程序要强行撤消（UNDO）所有未完成事务
• 将缓冲区中已完成事务提交的结果写入数据库
– 系统重新启动时，恢复程序需要重做（REDO）所有已提交的事务
1.2.3 介质故障
• 硬件故障使存储在外存中的数据部分丢失或全部丢失
• 介质故障比前两类故障的可能性小得多，但破坏性大得多
介质故障的常见原因
• 硬件故障
– 磁盘损坏
– 磁头碰撞
– 操作系统的某种潜在错误
– 瞬时强磁场干扰
介质故障的恢复
• 装入数据库发生介质故障前某个时刻的数据副本
• 重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库
1.3 恢复的实现技术
1.3.1 恢复操作的基本原理
1.3.2 恢复操作的关键问题
1.3.3 数据转储
1.3.4 日志文件
1.3.1 恢复操作的基本原理
• 恢复操作的基本原理：冗余
– 利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据
• 恢复的实现技术：复杂
– 一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上
1.3.2 恢复的实现技术
恢复机制涉及的关键问题
1. 如何建立冗余数据
• 数据转储（backup）
• 登录日志文件（logging）
2. 如何利用这些冗余数据实施数据库恢复
1.3.3 数据转储
A、什么是转储
B、转储的用途
C、转储方法
A、什么是转储
• 转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程。
• 这些备用的数据文本称为后备副本或后援副本。
B、转储的用途
C、转储方法
• 静态转储与动态转储
• 海量转储与增量转储
• 转储方法小结
静态转储
• 在系统中无运行事务时进行转储
• 转储开始时数据库处于一致性状态
• 转储期间不允许对数据库的任何存取、修改活动
• 优点：实现简单
• 缺点：降低了数据库的可用性
– 转储必须等用户事务结束
– 新的事务必须等转储结束
利用静态转储副本进行恢复

动态转储
• 转储操作与用户事务并发进行
• 转储期间允许对数据库进行存取或修改
• 优点
– 不用等待正在运行的用户事务结束
– 不会影响新事务的运行
• 动态转储的缺点
– 不能保证副本中的数据正确有效
动态转储
• 利用动态转储得到的副本进行故障恢复
– 需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
– 后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态
利用动态转储副本进行恢复

利用动态转储副本进行恢复

海量转储与增量转储
• 海量转储: 每次转储全部数据库

• 增量转储: 只转储上次转储后更新过的数据

• 海量转储与增量转储比较
– 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
– 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效
转储方法小结
• 转储方法分类
转储策略
• 应定期进行数据转储，制作后备副本。
• 但转储又是十分耗费时间和资源的，不能频繁进行。
• DBA应该根据数据库使用情况确定适当的转储周期和转储方法。
    例：
– 每天晚上进行动态增量转储
– 每周进行一次动态海量转储
– 每月进行一次静态海量转储
1.3.4 日志文件
一、日志文件的内容
二、日志文件的用途
三、登记日志文件的原则
一、日志文件的内容
A. 什么是日志文件
日志文件(log)是用来记录事务对数据库的
更新操作的文件
B. 日志文件的格式
以记录为单位的日志文件
以数据块为单位的日志文件
日志文件的内容（续）
C. 日志文件内容
– 各个事务的开始标记(BEGIN TRANSACTION)
– 各个事务的结束标记(COMMIT或ROLLBACK)
– 各个事务的所有更新操作
– 与事务有关的内部更新操作
日志文件中的一个日志记录 (log record)
D. 基于记录的日志文件
每条日志记录的内容
– 事务标识
– 操作类型（插入、删除或修改）
– 操作对象（记录ID、Block NO.）
– 更新前数据的旧值（对插入操作而言，此项为空值）
– 更新后数据的新值（对删除操作而言, 此项为空值）
E. 基于数据块的日志文件
每条日志记录的内容
– 事务标识（标明是那个事务）
– 操作对象（记录ID、Block NO.）
– 更新前数据所在的整个数据块的值（对插入操作而言，此项为空值）
– 更新后整个数据块的值（对删除操作而言, 此项为空值）
二、日志文件的用途
1．用途
– 进行事务故障恢复
– 进行系统故障恢复
– 协助后备副本进行介质故障恢复
日志文件的用途（续）
2．与静态转储后备副本配合进行介质故障恢复
– 静态转储的数据已是一致性的数据
– 如果静态转储完成后，仍能定期转储日志文件，则在出现介质故障重装数据副本后，可以利用这些日志文件副本对已完成的事务进行重做处理
– 这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态
日志文件的用途（续）
日志文件的用途（续）
3．介质故障恢复：LOG FILE + 动态转储后备副本
– 动态转储数据库：同时转储同一时点的日志文件
– 后备副本与该日志文件结合起来才能将数据库恢复到一致性状态。
– 利用这些日志文件副本进一步恢复事务，避免重新运行事务程序。
三、登记日志文件的原则
• 为保证数据库是可恢复的，登记日志文件时必须遵循两条原则
– 登记的次序严格按并行事务执行的时间次序
– 必须先写日志文件，后写数据库
• 写日志文件操作：把表示这个修改的日志记录写到日志文件
• 写数据库操作：把对数据的修改写到数据库中
登记日志文件的原则（续）
• 为什么要先写日志文件
– 写数据库和写日志文件是两个不同的操作
– 在这两个操作之间可能发生故障
– 如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了
– 如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性
1.4 恢复策略
1.4.1 事务故障的恢复
1.4.2 系统故障的恢复
1.4.3 介质故障的恢复
1.4.1 事务故障的恢复
• 事务故障：事务在运行至正常终止点前被中止
• 恢复方法
– 由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改
• 事务故障的恢复由系统自动完成，不需要用户干预
事务故障的恢复步骤
1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”（Befor Image, BI）写入数据库。
– 插入操作， “更新前的值”为空，则相当于做删除操作
– 删除操作，“更新后的值”为空，则相当于做插入操作
– 若是修改操作，则用BI 代替 AI（After Image）
事务故障的恢复步骤
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。
1.4.2 系统故障的恢复
• 系统故障造成数据库不一致状态的原因
– 一些未完成事务对数据库的更新已写入数据库
– 一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
• 恢复方法
– 1. Undo 故障发生时未完成的事务
– 2. Redo 已完成的事务
• 系统故障的恢复由系统在重新启动时自动完成，不需要用户干预
系统故障的恢复步骤
1. 正向扫描日志文件（即从头扫描日志文件）
– Redo队列: 在故障发生前已经提交的事务
   T1, T3, T8…..
– Undo队列:故障发生时尚未完成的事务
   T2, T4, T5, T6, T7, T9 …...
系统故障的恢复步骤
2. 对Undo队列事务进行UNDO处理
       反向扫描日志文件，对每个UNDO事务的更
       新操作执行逆操作
       T2, T4, T5, T6, T7, T9 ……
    3. 对Redo队列事务进行REDO处理
       正向扫描日志文件，对每个REDO事务重新
      执行登记的操作
      T1, T3, T8…..
1.4.3 介质故障的恢复
1. 重装数据库，
    使数据库恢复到一致性状态
2. 重做已完成的事务
1.4.3 介质故障的恢复
• 恢复步骤
1. 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。
– 对于静态转储的数据库副本，装入后数据库即处于一致性状态
– 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障相同的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。
利用静态转储副本将数据库恢复到一致性状态

利用动态转储副本将数据库恢复到一致性状态

介质故障的恢复（续）
2. 装入有关的日志文件副本，重做已完成的事务。
– 首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
– 然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。
介质故障的恢复（续）
介质故障的恢复需要DBA介入
• DBA的工作
– 重装最近转储的数据库副本和有关的各日志文件副本
– 执行系统提供的恢复命令
• 具体的恢复操作仍由DBMS完成
1.5 具有检查点的恢复技术
一、问题的提出
二、检查点技术
三、利用检查点的恢复策略
一、问题的提出
• 两个问题
– 搜索整个日志将耗费大量的时间
– REDO处理：重新执行，浪费了大量时间
解决方案
• 具有检查点（checkpoint）的恢复技术
– 在日志文件中增加检查点记录（checkpoint）
– 增加重新开始文件
– 恢复子系统在登录日志文件期间动态地维护日志
二、检查点技术
• 检查点记录的内容
– 1. 建立检查点时刻所有正在执行的事务清单
– 2. 这些事务最近一个日志记录的地址
• 重新开始文件的内容
– 记录各个检查点记录在日志文件中的地址

在检查点维护日志文件
1. 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上。
2. 在日志文件中写入一个检查点记录。
3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中。
4. 把检查点记录在日志文件中的地址写入一个重新开始文件。
建立检查点
• 定期
– 按照预定的一个时间间隔
• 不定期
– 按照某种规则，如日志文件已写满一半建立一个检查点
三、利用检查点的恢复策略
• 当事务T在一个检查点之前提交
T对数据库所做的修改已写入数据库
• 在进行恢复处理时，没有必要对事务T执行REDO操作
利用检查点的恢复策略（续）
利用检查点的恢复步骤
1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址
2 由该地址在日志文件中找到最后一个检查点记录
利用检查点的恢复策略（续）
2.由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
– 建立两个事务队列
• UNDO-LIST
• REDO-LIST
– 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
利用检查点的恢复策略（续）
3.从检查点开始正向扫描日志文件，直到日志文件结束
– 如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列
– 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列
4.对UNDO-LIST中的每个事务执行UNDO操作, 对REDO-LIST中的每个事务执行REDO操作
1.6 数据库镜像
• 介质故障是对系统影响最为严重的一种故障，严重影响数据库的可用性
– 介质故障恢复比较费时
– 为预防介质故障，DBA必须周期性地转储数据库
• 提高数据库可用性的解决方案
– 数据库镜像（Mirror）
数据库镜像（续）
• 数据库镜像
– DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上
– DBMS自动保证镜像数据与主数据的一致性
数据库镜像的用途
• 出现介质故障时
– DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本
• 没有出现故障时
– 可用于并发操作
– 一个用户对数据加排他锁修改数据
– 其他用户可以读镜像数据库上的数据
数据库镜像（续）
2 实时数据库中故障恢复实现
• 实时数据库中故障恢复的特点
– 在内存缓冲区中保存了相当多已修改但未提供的页面，系统故障造成的数据丢失比关系数据库多得多
– 用户可以忍受因为系统故障造成的数据损失，不能忍受系统故障造成系统完崩溃
– 磁盘I/O是实时数据库的瓶颈，引入故障恢复后，更是瓶颈
– 基于操作的日志记录的数据量已非常海量，基于页面更改的日志记录的数据量大到无法接受
– 基于操作的日志记录的UNDO难度较大
断电时会产生什么后果
• 什么事情都可能发生，但事件发生的概率有高低
• 磁盘损坏，文件丢失，文件结构损坏，文件内数据被逻辑破化，文件内扇区物理损坏
• 如何尽量保证断电时文件结构不破化？
• 如何判断某扇区的内容是正确的？
基于日志的故障恢复方法的代价
• 日志的提交与操作的提交需不需要同步？
• 精确检测点和模糊检测点
• 日志的批次提交
实时数据库分时间段的特性可否利用？
重要数据双写技术
镜像和冗余技术
3.参考书目
• 《事务处理概念与技术》
– 事处处理的经典书
• 《数据库与事务处理》
– 前一书的补充，并在关系数据库上进行扩展
• 《内存数据库若干关键技术研究》硕士论文
– 对内存数据库的故障恢复的讨论同样适用我们的产品
结束

文章来源:http://blog.gkong.com/more.asp?name=linkman&id=63199

实时数据库中并发控制理论

Linkman的学习记录 — Sat, 27 Sep 2008 03:47:00 GMT

实时数据库中并发控制理论

提纲
1. 与并发控制有关的概念
2. 并发控制的理论
3. 并发控制的实现
4. 锁的类别
5. 并发控制的原则
6. 实时数据库中并发控制的实现
7. 参考书目

1.与并发控制有关的概念
1.1. 事务的ACID特性
1.2. 事务分类
1.3. 平坦事务分类
1.4. 隔离性定义1
1.5. 隔离性的依赖模型
1.6. 三种有害的依赖关系
1.7. 隔离性原理
1.8. 隔离性定义2
1.9. 隔离性的级别

1.1. 事务的ACID特性
1.1.1. 一致性
1.1.2. 原子性
1.1.3. 执久性
1.1.4. 隔离性

1.1.1. 一致性
系统必须满足所有完整性约束
内部状态一致性
系统必须满足应用程序的完整性约束
系统异常时，能恢复到一致性的状态

1.1.2. 原子性
系统必须确保事务一直运行到完成，如果没有运行完成，将不产生任影响，就像没有运行一样。
原子性的执行表明事务要么成功提交，要么异常中址

1.1.3. 执久性
系统必须确保，一旦事务成功提交，不管后来计算机和存贮介质是否发生故障，其执行结果必须反映在系统中

1.1.4. 隔离性
尽管事务是并发执行的，但并发调度执行的结果就像事务按照某种顺序串行执行时所产生的结果一样

1.2. 事务分类
平坦事务
链式事务
嵌套事务
分布式事务

1.3. 平坦事务分类
只读事务
只写事务
更新事务

1.4. 隔离性定义1
事务处理系统可以并发地运行事务，但它的结果如同顺序执行一样，就应用程序而言，事务好像是在没有并行的情况下运行，事务的确切执行顺序是由系统控制的，系统行为等价于事务的某种串行执行，其造成的表面现象是一个事务执行完毕后，下一个事务才开始运行

1.5. 隔离性的依赖模型
事务的某次操作A的执行必须在另一个事务的某次操作B的操作结果，则称A依赖B
读-读没有依赖关系
读-写有依赖关系
写-写有依赖关系
写-读有依赖关系

1.6. 三种有害的依赖关系
丢失更新：事务T1的写被事务T2所忽略
T2读; T1写；T2写；
读脏数据：T1在读的是T2写的的中间数据
T2写；T1读；T2写；
不可重复读：事务T1读某对象两次，两次的结果不一致
T1读；T2写；T1读；

1.7. 隔离性原理
三种有害的依赖关系覆盖了事务处理的所有情况，如果可以防止它们发生，那么将不会有并发异常，事务将表现为隔离运行的状态

1.8. 隔离性定义2
如果满足下列条件，事务T与其它事务是隔离的：
0. T不会重写其它务的脏数据。
1. T所写的数据，在提交前，不会被其它事务读或写；
2. T不读其它务的脏数据；
3. T在提交之前，其它事务不会写T所要读的数据；
其中：
条件0和1排除了丢失更新；
条件2防止了读脏数据；
条件3防止了不可重复读；

1.9.隔离性的级别
0级： 0级事务不会重写高一级事务的脏数据
1级： 1级事务不会有丢失更新
2级： 2级事务既不会有丢失更新，也不会读脏数据；
3级： 3级事务不会有丢失更新，不会读脏数据，可重复读
SQL标准定义了这四种级别，每个关系数据库都实现了这四种级别

2.并发控制理论
2.1. 并发控制的原则
2.2. 并发控制的性能指标
2.3. 并行调度的等价性
2.4. 调度的可串行性
2.5. 调度可串行化的判断
2.6. 隔离性定理

2.1. 并发控制的原则
事务的并发执行不应导致程序的失效；
相比于串行执行，并发执行不应该有更低的平均吞吐量和更长的平均响应时间

2.2. 并发控制的性能指标
平均吞吐量
加权平均吞吐量
平均响应时间
加权平均响应时间
错失率

2.3. 并行调度的等价性
冲突等价
两个调度具有相同的事务集，相应的事务具有相同的操作；
两个调度中，任何两个相冲突的提交事务的操作的先后顺序一致；
视图等价
两个调度读出的数据是一样的；
两个调度留给系统的操作结果是一样的；
冲突等价实现容易，视图等价实现困难，现在的并发控制理论大多依据冲突等价

2.4. 调度的可串行化
如果一个调度等价于一个串行调度，则称该事务为可串行化的，该调度为可串行化调度；
可串行化调度分为冲突可串行化和视图可串行化
冲突可串行化实现容易，视图可串行化实现困难，现在的并发控制理论大多依据冲突可串行化

2.5. 可串行化调度的判断
如果某调度中，任意事务的的输出集与其余事务的输入集及输出集无交集，则该调度是可串行化的
构建事务调度的串行图，如果没有检测到环，则该调度是可串行化的；
可串行化判断有静态和动态两种

2.6. 隔离性定理
如果事务的读、写、解锁都有相应的锁覆盖，且所有的锁都会在事务结束前释放，则该事务是规范的；
如果某事务中所有的加锁操作都在解锁操作之前，则该事务是两阶事务；
如果同一时间内没发生两个不同事务的锁冲突，则该调度是合法的；
如果一个调度中，所有的事务都是规范的且是两阶段的，则任何合法的调度是隔离的

3.并发控制的实现
3.1. 基于锁的并发控制
3.2. 二段封锁协议的分类
3.3. 二段封锁协议的优缺点
3.4. 改进型二段封锁协议
3.5. 乐观并发控制
3.6. 乐观并发控制的优缺点
3.7. 改进型乐观并发控制
3.8. 其它并发控制算法

3.1. 基于锁的并发控制
锁类型：共享锁、排它锁
锁相容：读读相容，其它不相容
一个事务中，所有的加锁动作都在所有的解锁动作之前，称该事处是二段事务，相应的加锁封锁协议称为二段封锁协议（2PL）,2PL是调度可串行化的充分条件；
悲观协议

3.2. 二段封锁协议的分类
一般2PL
保守2PL
• 事务在访问对象之前，加锁全部完毕
• 避免死锁，降低并发性
严格2PL
• 所有排它锁必须在事务结束时才释放
• 避免读脏数据
强2PL
• 所有锁必须在事务结束时才释放
• 避免不可重复读

3.3. 二段封锁协议的优缺点
二段封锁协议是悲观协议，存在事务阻塞，降低了事处的并发度
如果对数据访问的竞争大，则二段封锁协议具有较高的性能，否则，会存在不必要的加锁和解锁操作
主要用在资源紧张的情况下

3.4. 改进型二段封锁协议
高优先级优先2PL
优先级继承2PL
条件优先级继承2PL
……

3.5. 乐观并发控制
乐观并发控制事先不进行冲突检查；
乐观并发控制将事务分为读、校验、提交三个阶段；
读操作从对象中取得副本并进行处理；校验阶段判断是否冲突；如果没有冲突，则提交更新，否则重启该事务；
同一时刻只一个事处处在验证阶段和写阶段

3.6. 乐观并发控制的优缺点
乐观并发处理中没有锁；
每个事务都有自己的私有缓存，空间浪费大；
如果冲突产生，事务重启的成本太高；
如果对象竞争小，乐观并发控制效率高，如果对象竞争频繁，则效率低，特别是有“热点”时

3.7. 改进型乐观并发控制
前验证乐观并发控制；
高优先级乐观并发控制；
半重启乐观并发控制；
……

3.8. 其它并行控制算法
字段调用*
契约封锁*
多版本并发控制
推测并发控制
基于动态调整串行化顺序的并发控制

4.锁的类别
采用不同类型的锁可以实现更精确的并发控制
4.1. 共享锁和排它锁
4.2.谓词锁
4.3. 粒度锁
4.4. 意向锁
4.5. 码区间封锁
4.6. 启发式封锁

4.1. 共享锁和排它锁
这是最常规的锁

4.2. 谓词锁
幻像
记录锁不能防止其它事务执行insert功能
Select * from emp where eye=“blue”
谓词锁
eye=“blue”
谓词锁能解决幻像的产生；
谓词锁能的执行成本太高；

4.3. 粒度锁
锁可以分为不同的级别：表锁、页锁、记录锁、字段锁、索引锁
根据需要对不同级的对象加锁

4.4. 意向锁
粒度锁的优化版本
锁可以分为不同的级别，这些分级就形成了一棵树
对树加锁，引入意向锁，在对某结点加锁前，必须先得到它的父结点的意向锁
意向锁是谓词锁的特例，效率比谓词锁高；

4.5. 码区间锁
意向锁的特殊版本
树标识可以通过区间码来标识，则可以只针对码区间加锁

4.6. 加锁的启发式算法
针对粒度锁、意向锁和码区间锁，可以在运行时动态升级和降级

5.并发控制实现时的原则
不同目标选择不同的并发控制方法；
不同执行环境选择不同的并发控制方法；
在明确具体应用需求的情况下，可以适当违反并行控制理论，以获得更高的性能；
选择了并发控制算法后，数据结构也应相应调整，以提高并发性能；
并发控制是有成本的，能不并行则不并行，能不锁就别锁，能短锁就别长锁，能简单则不复杂；

文章来源:http://blog.gkong.com/more.asp?name=linkman&id=34557

实时数据库中的二级压缩技术

Linkman的学习记录 — Tue, 13 Nov 2007 04:35:00 GMT

今天心情不好，写写文章散散心。

我在文章《实时数据库领域中有关数据压缩的认识误区》中提到，在工业应用领域中，常用的压缩算法分为三类：无损压缩、有损压缩、二级压缩。二级压缩技术，同时利用了无损压缩、有损压缩这两种数据压缩技术。

liyaoer123同学很好学也很好问，他问到：“我有点疑问，通过旋转门压缩后的数据基本上是没有重复量了，二次压缩这个词应该不能准确表达意思。”

首先要提醒liyaoer123同学一下，旋转门压缩只是有损压缩的一种，osisoft公司似乎还拥有旋转门压缩的技术专利，我们还是少提它吧。

常用的几种的有损压缩的方法都类似，主要是抽取那些特征点，以特征点的连线来近似地表示原始数据曲线，如下两图所示。

图一压缩前，总共有52个采集点

图二压缩后，只有6个特征点

二级压缩的概念，是在已进行有损压缩的基础上，再次对数据进行压缩。

对于二级压缩，需要考虑如下如下两方面的问题：

1、为什么需要进行二级压缩？

在《实时数据库领域中有关数据压缩的认识误区》中，我已提到，对实时数据库而言，数据压缩可以带来两方面的好处：占用硬盘容量减小、系统整体处理速度提高。

随着计算机硬件水平的提高，硬件成本在整个系统投入的比重逐步下降，硬盘容量不再是实时数据库中最主要的矛盾，但对系统整体处理速度及性能的追求，还是非常重要的。

关于压缩性能和系统整体处理速度及性能的指标，我经常面对两类指责。

有一些人对我说，我们保必要追求那么高的压缩比，何必要追求那么快的处理速度，只要够用就行了，我们还是将精力放在系统的稳定性和可靠性方面吧，似乎对指标的追求导致了系统稳定性的下降。

而另外一些人则对我说，你们中国人只知道在低层次上的技术水平上竞争，现在PI的最新的版本已支持单服务器1000万点，而国内这些实时数据库厂家还在10万点这个层次上竞争。

对这两类指责，我不想评价是与非，只想说，不管我们做什么，都会有不同的意见，关键的问题是，我们自己想做出什么东西。

对于MES系统集成商，实时数据库只是其中一个子系统，只要够用就行，而作为实时数据库的提供商，我们希望我们的实时数据库系统在各个指标方面，包括稳定性和可靠性方面，也包括功能的完备性和需求的准确性，都能全面与国外产品抗衡，因此，对性能的追求是一直会坚持走下去的。

写到这里，跑一下题。这前段时间在全国几处地方跑了跑，与很多客户进行了技术和商务交流，当我们提到，我们的实时数据库的数据读写指标为每秒30万次，他们大部分表示了惊讶：不对呀，PI和IH都是每秒2万到10万呀，你们的实时数据库怎么比那些国外的品牌还要强呀。

再将马拉回来，我在《此实时数据库非彼实时数据库》中提到，压缩比例的提高，对实时数据库的整体性能的提高有很大的推动作用（但不一定成正比），因此，有必要分析一下，能否对已经进行有损压缩处理的数据进行二级压缩。

2、如何进行二级压缩？

从刚才分析的情况，大家很可能就得出结论，行呀，先通过有损压缩，将点数由52个变成6个，再对剩下的6个点进行编码，再进行哈佛曼压缩或别的什么压缩，不就行了？

没这么简单。

哈佛曼压缩的特点是，将那些经常使用的字母用较小长度的字节表示，这在文本和字符串压缩中会有比较大的效果，比如英文那个e就是用得很多的，而汉字中的五笔字型也有一级编码、二级编码等，也就是说，它们具有可压缩的余地。

如果大家对随机的数据点，比如刚才6个数据点，采用哈佛曼或其它无损压缩试验，会发现压缩率不会特别地高，也就是说，再次进行无损压缩的意义已经不是特别地大。

难度就没有别的办法了？办法还是有的，要完整地表达测点的一个数据，需要包括以下四个字段：

测点ID
时间戳
质量戳
值

其中，同一测点的多个数据可以保存在一起，因此，测点ID可以不考虑。还剩下三个字段，仔细分析一下这三个字段的特性，还是有很多文章可做的。

值

先考虑“值”字段，我们采用8字节的双精度数来表示一个模拟量，这里就存在一个由低精度值来表示高精度值的可能。如果一批数据中，全部（或大部分）数据都可以由4个字节（或2个字节）来表示精度误差范围内的8字节双精度数，便可以节省下很多空间了。

当然，如果我们能明确地知道某数据的精度范围，便可直接在配置环境下选择最合适的数据类型，而不必要一定要选择双精度数。

对于值，还有另一种压缩思路，在流程工业中，某值的绝对值可能非常大，但如果该值在某时间段时的变量范围在某个精度范围内，也可以采用基准值+变化值的方式保存值，其中基准值只保存一次，而变化值用低精度值表示。

质量戳

质量戳是慢变化量，如果不与值共同保存，则可以有很高的压缩比。但如果不共同保存，则需要考虑查找的索引方式，这是一笔额外的空间开销。

时间戳

对于时间戳，也可以按照值相类似的方式来考虑。

首先，那个毫秒字段，不一定是每个系统每个测点都需要的。再者，两个时间之间的相差值，在大部分情况下，不会超过1天的，这个就可以采用简化表示。还有，现在的系统，肯定不需要再处理时间为2000年以前的时间了。

以上只是分析，在实际系统中，还需要考虑这些因素的制约关系，解压的难度和时间度，索引建立的方便性，以及编程的复杂度。