）（静止传感器数据是通过一个模拟程序随机２
生成的，该模拟程序可以模拟出１２８０００～３２００００ 个静止传感器的动态数据采样．
将上述两部分数据按照一定的比例（如移动传感器与静止传感器的比例为１进行合成，从而∶１０）可以得到实验中所需要的总体数据集．表２列出了实验中的主要参数．
表２ 模拟实验的主要参数
参数名
参数值（单位）１２８００～３２０００
参数含义
移动传感器的数目静止传感器的数目
传感器的总数目（其中移动传感
）器与静止传感器的比例为１∶１０每个传感器进行原始数据采样
的平均时间间隔
ＳＣＰ结点抽取的关键采样数据的平均时间间隔根结点服务器的数目叶结点服务器的数目
结点上执行对应的Ｓ在执行ＳＱＬ语句．ＱＬ语句时，，叶结点不能调用本地的Ｌ但通过属ＦＴＫＢ－Ｔｒｅｅ性Ｂ＋树仍然可以获得较快的查询速度．
＋
对于更加复杂的查询（如多个约束条件通过，ＡＮＤ或者ＯＲ连接）ＩｏＴ－ＣｌｕｓｔｅｒＤＢ可以通过相应的全局索引，针对每个约束条件获得一个叶结点集然后根据连接条件对这些集合进行相应的交集合，
或并集计算，最终获得真正需要执行查询的叶结点范围，并在这些叶结点上执行查询从而得到最后的查询结果．
５．３ 新采样数据触发的数据更新处理
在ＩｏＴ－ＣｌｕｓｔｅｒＤＢ中包含多个采样数据接收服务器，这些服务器组成一个集群，共同对传感器接入处理器上传的新采样值进行处理．
新采样值的数据格式为（ｏｂＩＤ，ｓｔａｔｉｃＭｏｖ，ｊ），其中ｏｓｖａｌｕｅｂＩＤ是监控对象的标识，ｓｔａｔｉｃＭｏｖｊ
标明监控对象是静止的还是移动的，ｓｖａｌｕｅ＝（，，是一个ｓｔｌｏｃ，ｎｏｓｓｃｈｅｍａ，ｖａｌｕｅ）ａｍｌｉｎＶａｌｕｅｐｐｇ类型的值．采样数据接收服务器接收到上述数据之后，首先判断ｓ如果是静止监控对象，则可ｔａｔｉｃＭｏｖ，通过ＳＡＰａｂｌｅ找到管辖区域与ｌｏｃ相交的叶结点－Ｔ（，然ｌｏｃ∈Ｒｅｉｏｎ时可以有多个叶结点与ｌｏｃ相交）ｇ
后将采样数据转发给相应的叶结点进行存储处理；如果是移动监控对象，则需要进一步判断上次提交了采样值之后该监控对象是否跨越了叶结点的管辖区域边界，若是，则需要进行相应的插值计算，并将
ＮＭｏｖＳｅｎｓｏｒｓ
ＮＳ２８０００～３２００００ｔａｔｉｃＳｅｎｓｏｒｓ１ＮＳｅｎｓｏｒｓ
ａｍｌｉｎｐｇξＳ
１４０８００～３５２０００
５ｓ３００ｓ１
２～３２
ｅＳａｍｌｉｎｙｐｇξＫ
ＮＭａｓｔｅｒＮｏｄｅｓ
ＮＬｅａｆＮｏｄｅｓ
１１８８
计 算 机 学 报２０１２年
在实验中，我们重点针对ＩｏＴ－ＣｌｕｓｔｅｒＤＢ的查询响应时间及加速比进行了分析．由于在海量传感目前器采样数据的云存储以及时空数据处理方面，尚没有系统性的相关工作，我们将ＩｏＴ－ＣｌｕｓｔｅｒＤＢ与单数据库结点处理机制（ＳｉｎｌｅＮｏｄｅＱｕｅｒＰｒｏ －ｇｙ ，进行了比较．此外，为了分析传感器ｃｅｓｓｉｎＳＮＱＰ）ｇ数据动态采集对查询性能所造成的影响，在实验的过程中，由数据模拟生成程序根据实验数据集，持续向ＩｏＴ－ＣｌｕｓｔｅｒＤＢ发送并插入传感器采样数据．
实验的测试用例分别采用第３．２．４节中介绍的关键字查询Ｑ属性约束条件查询Ｑ１、３和时空约束条件Ｑ图９给出了Ｉ５．ｏＴ－ＣｌｕｓｔｅｒＤＢ处理各个查询的响应时间（为了更好地分析属性约束条件查询Ｑ３的性能，我们在各叶结点中没有对相关属性建立局部索引）
．
的，根结点上的ＳＡＰａｂｌｅ和各叶结点上的时空索－Ｔ
４
引Ｓ加快了Ｔ－Ｔｒｅｅ共同构成了一个全局时空索引，
时空查询处理的速度，并降低了叶结点数据量对查询性能的影响．
为了进一步分析ＩｏＴ－ＣｌｕｓｔｅｒＤＢ中叶结点规模对非关键字查询处理性能的影响，我们在表３和表４中分别给出ＩｏＴ－ＣｌｕｓｔｅｒＤＢ在处理Ｑ３和Ｑ５时的加速比实验结果．加速比Ｓｅｅｄｕｐｐ定义为
，Ｓｅｅｄｕｐｐ＝ＩｏＴＣｌｕｓｔｅｒＤＢξ
其中ξＮＱＰ和ＩｏＴＣｌｕｓｔｅｒＤＢ－ＳＮＱＰ和ξＩｏＴＣｌｕｓｔｅｒＤＢ分别是Ｓ
ＳＮＱＰ
的查询响应时间．
表３ ＩｏＴｌｕｓｔｅｒＤＢ在执行Ｑ３时的加速比－Ｃ
ＮＬｅａｆＮｏｄｅｓ
２
４ ８ １６ ３２
加速比
ＮＳ６４×１０００ ｅｎｓｏｒｓ＝
１．５７
３．２５ ６．２７ １１．８３ ２０．１９
ＮＳ１６０×１０００ｅｎｓｏｒｓ＝
１．６２
３．２６６．３２１３．５２２４．８６
表４ ＩｏＴｌｕｓｔｅｒＤＢ在执行Ｑ５时的加速比－Ｃ
ＮＬｅａｆＮｏｄｅｓ
２
４ ８ １６ ３２加速比
ＮＳ６４×１０００ ｅｎｓｏｒｓ＝
１．６２
１．９５ ２．８９ ３．６８ ６．１１ＮＳ１６０×１０００ｅｎｓｏｒｓ＝
１．８７
２．４５３．９２４．７７６．１２
图９ ＩｏＴ－ＣｌｕｓｔｅｒＤＢ的查询响应时间
从图９可以看出，ＩｏＴ－ＣｌｕｓｔｅｒＤＢ可以有效地支持关键字查询Ｑ且在不同的数据量及不同的叶１，结点规模的情况下，关键字查询的响应时间基本保持稳定．这是因为ＩｏＴ－ＣｌｕｓｔｅｒＤＢ通过ＧＦＴＫＢ－
＋
从表３可以看出，ＩｏＴ－ＣｌｕｓｔｅｒＤＢ在处理属性约束条件查询Ｑ加速比随着叶结点个数的增３时，而且数据量越大，加速比增加得加几乎呈线性增长，
也越明显．这是因为在ＩｏＴ－ＣｌｕｓｔｅｒＤＢ中所有的数据均是统一存放在单个关系表中的，不牵涉到连接因此查询的响应时间基本上取决于各叶结点运算，
的平均数据量．此外，多个数据库结点的协同工作也分担了传感器数据更新所带来的繁重通信与计算开销．
从表４可以看出，ＩｏＴ－ＣｌｕｓｔｅｒＤＢ在处理时空约束条件查询Ｑ加速比也随着叶结点个数的５时，增加而随之增大，但与Ｑ３相比，Ｑ５的加速比变化这是由于全局时空索引的影响不如Ｑ３变化明显，而导致的．另外，轨迹的分割与合并也给全局查询处理带来了额外的计算开销．
