SYBASE IQ 在综合网管系统中的应用的研究

jarjar

传统的OMC(操作维护中心)/OMM(操作维护终端)中，提供的主要功能是配置管理，性能管理，安全管理，告警管理。由于管理的网元数量不多，所以一般使用OLTP型或者混合型的数据库即可满足要求，如ORACLE,SYBASE ASE等。但在综合网管系统中，由于管理的网元急剧上升，在某些极端情况下达到几千个网元，导致分析处理的数据量迅速上升，同时综合网管的功能开始偏向数据分析，包括性能分析，告警关联性分析，日志查询等，操作型的动作减少，包括配置管理等。以这些操作为主要特征的系统，再去使用OLTP型的数据库，可能在数据的查询效率上满足起来就非常吃力，尤其是性能数据的统计分析。


详细的过程请参见附件。

jarjar

SYBASE IQ在综合网管系统中的应用研究

关键词：SYBASE IQ,综合网管，OLAP
(一)背景
     传统的OMC(操作维护中心)/OMM(操作维护终端)中，提供的主要功能是配置管理，性能管理，安全管理，告警管理。由于管理的网元数量不多，所以一般使用OLTP型或者混合型的数据库即可满足要求，如ORACLE,SYBASE ASE等。但在综合网管系统中，由于管理的网元急剧上升，在某些极端情况下达到几千个网元，导致分析处理的数据量迅速上升，同时综合网管的功能开始偏向数据分析，包括性能分析，告警关联性分析，日志查询等，操作型的动作减少，包括配置管理等。以这些操作为主要特征的系统，再去使用OLTP型的数据库，可能在数据的查询效率上满足起来就非常吃力，尤其是性能数据的统计分析。

(二)问题描述
    性能数据的DB建模按照一个测量类型（指某种网元的同类型的话务指标，比如GSM网核心网网元MSC的目的码话务指标，包括总呼入数，总呼出数，成功呼入数，成功呼出数等就算一个测量类型）一个表的方式来存储，除去索引字段，表的每列就是一个性能对象属性（PO Attribute）.常见的索引字段是：局号，开始时间，结束时间，MSC编号，目的码编号，等。还有元数据存储，指明每个PO的汇总方式，包括加，减，乘，除，最大，最小等。
性能数据的处理流程目前如下：
１）采集
根据性能任务,从下级系统采集相关的原始粒度的性能文件，一般是用FTP来取，文件格式为文本文件。一般的性能数据粒度为15分钟。大型系统中为30分钟或者1小时。

２）原始数据入库
应用代码从文件中取出数据，采用JDBC入库

３）原始数据汇总
根据建立的汇总模型，即时对相应的原始数据进行各个粒度的汇总。将汇总数据入库。这里一般是使用存储过程进行数据汇总。并且不同粒度的汇总数据分表存储。

４）根据设置条件，触发相应的QOS告警
性能数据查询或者性能报表查询时，根据选择的天，周，月等不同粒度，从相应的表中查询数据。
这种传统的处理方式的优点是：
１）数据处理即时。
２）即时汇总。
３）汇总数据已经在表里面，不用临时汇总，速度较快。
４）QOS告警可以即时触发。QOS告警可以设置在KPI上。

主要缺点：
１）在同类型网元较多的情况下，可能存在一个表的数据量特别大的情况。比如BTS网元，在国家网的情况下，1000个BTS是比较常见的，性能数据要求存储3个月，假如原始数据的粒度是15分钟的话，目的码有10要求存储的记录数是：1000*24*4*30*3*10,就是8000多万条的数据存储量，这还是比较保守的估计。这样的记录规模，一般要求分表，但这又为分表的依据，分表数据间的联合查询，统一的备份恢复等带来极多问题。
２）每条性能数据，采用JDBC入库，效率慢。
３）入库的同时要触发所有粒度的相关汇总操作，包括小时汇总，天汇总，周汇总，月度汇总表，处理事务量较大，数据库IO较重。对于性能文件的补采，后面入库的代价较大。因为性能记录的入库触发的动作太多。
４）存储量较大，DB模型复杂。包括小时汇总表，天汇总表，周汇总表，月度汇总表。
５）KPI需要单独管理。KPI是通过原始元数据和KPI公式二次计算而来的。比如，呼叫成功率=呼叫成功次数/总呼叫次数。查询KPI时，目前是使用代码进行动态计算，数据库中不存储具体的KPI值。KPI的计算速度较慢。如果使用数据库计算，在原始话务指标分布在不同的表时，联合查询的数据量特别大。

下面我们来看一个具体的案例。
印尼金光NOC(国家网络中心)项目.其网元规模：

管理的网元类型	网元个数
BTS、 BSC	1078
MSCe、MGW、HLRe、PDSN、GSM1X	34
ZXDU58 S151、ZXDU3000 、ZXUPS S606	1443
Terminal Multiplexer	100
ZXR10、T128、 T64E、GER、T64G	108
PASOLINK、PASOLINK+ 、S3000	2920
MGE GALAXY UPS	12

数据库服务器针对PM处理的TPMC预估值为：12000,应用服务器处理性能数据采集入库的TPMC估计为70000M部分的存储量预计为：5700G
另外一个案例，新疆短信分析系统。系统建立的目的是对短信的流量，短信的使用情况等进行分析。需要采集全部的短信话单。数据量在每天3G,记录达到每天1一条左右。数据的存储按照每天一个分区（支持分区的数据库，如ORACLE）,并按照话单的流向分成MT,MO，AT,AO类。这样每个分区的每个表大概也有几千万条记录的规模，并且对分区的自动管理逻辑复杂。数据入库的效率较低（JDBC入库）。
很显然，在这种大型的网络下，我们的性能数据的处理模式遇到了挑战：数据存储量大，汇总慢，主机负荷重，客户端数据查询慢。那么有没有更好的方式来解决这个问题呢？
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。下表列出了OLTP与OLAP之间的比较。

	OLTP	OLAP
用户	操作人员,低层管理人员	决策人员,高级管理人员
功能	日常操作处理	分析决策
DB 设计	面向应用	面向主题
数据	当前的, 最新的细节的, 二维的分立的	历史的, 聚集的, 多维的集成的, 统一的
存取	读/写数十条记录	读上百万条记录
工作单位	简单的事务	复杂的查询
用户数	上千个	上百个
DB 大小	100MB-GB	100GB-TB

很显然，我们应该充分发挥数据库使用OLAP的功能来进行性能数据的处理。不论是从数据的入库，汇总，存储，OLAP都可以充分满足性能数据处理的要求。SYBASE　IQ产品在这几个特性上，表现都特别优异。

(三)Sybase IQ
    Sybase IQ是一个专门面向数据仓库环境的关系型数据库。不同于传统的关系型数据库所采用的行存储，Sybase IQ采用基于列的存储方法，这使Sybase IQ与其主要竞争对手有着明显的区别。这种方法在查询环境中提供了众多的优势，包括性能与可扩展性。尤其是，Sybase IQ通常能够在所要求的硬件资源减少的情况下，仍能提供查询性能方面的巨大改进（尤其是对复杂查询或者需要大表扫描的查询）。Sybase IQ的关键特征是一个基于列存储的关系型数据库，从根本上比行存储方式更适合于即席查询进程。由于其列存储的特性，Sybase  IQ以大量不同的方式充分利用每个列的特性：
◆首先，Sybase IQ发布了多种专门的索引以提升查询性能。这些包括为低基数数据、联合列、文本分析、Web应用的实时比较、以及实时的数据与时间序列分析所设立的索引。
◆联合使用列存储与 Sybase IQ的Bit-Wise索引（另一选择）的结果就是，聚合可以随时进行。如果说事务的预先聚合是抽取、转换、加载（ETL）功能的重要一部分，那么在此可能并不需要一个完整的ETL层。
◆列存储方法使数据压缩比使用传统方法下更容易实现，而且，压缩效果也更加显著。事实上，Sybase IQ如此出色，即使使用了索引，其存储也从未超过原始数据的大小。这点与传统数据库相比，取得了数倍的改进效果。Sybase IQ在实际应用中已被证实，数据压缩比例多至原始数据集的50%到70%。而在传统的数据库中，由于数据的预先聚合、物化视图以及传统的基于行的索引等等，数据膨胀至原始数据的3到6倍并不鲜见。
◆使用Sybase IQ，向表中增加或加载一列数据如同传统关系型数据库中增加一行数据一样容易。这种灵活性对于许多用户，尤其是对于那些对实时解决方案感兴趣的用户非常具有吸引力。
◆Sybase IQ支持几乎无限的并发查询，而不是仅仅对一些特定的查询使用并行机制以提高其性能。这不再是一种寻求平衡的方式，因为Sybase IQ的列存储方式与传统方法相比提供了根本性的性能提高（常常要快几百倍）。

(四)改进方案
１）性能数据入库，采用ETL的方式。使用数据库的数据库的方式直接LOAD性能文本文件。性能文本文件的格式可以提前归一化。可以加快原始数据入库速度。数据入库可以提前进行预处理。可以在采集的预处理中，先将接口机上的文件取回本地，并按照规则进行数据归一化的预处理。对于数据的异常报告警。
２）数据的存储只存储原始粒度的数据，汇总数据即时查询。即时查询还可以很好地适应补采的情况(比如由于接口机的故障，或者网络故障，导致性能文件被延迟采集)。
３）对于上千万的数据记录，不用再分表存储
４）KPI不再需要单独管理。还是直接使用原始数据查询的方式，使用SQL直接计算KPI值。
５）对于QOS指标，不再使用入库触发的方式。使用定时器，在每一个周期，定时查询相应的QOS对应的指标，进行比较，如果超界，则报警。定时周期可以设置成与性能数据粒度周期一致的值，如5分钟。
６）对于小时汇总数据，天汇总数据，周汇总数据，月汇总数据，可以考虑在以上方案的效率不能满足要求的情况下，选择在系统相对较闲的情况提前使用查询的方式进行汇总好，比如凌晨。这种情况下需要修改查询的逻辑，作一定的判断。这种优化策略相对比较复杂，适合于海量数据，即席查询也无法满足效率的情况。

[ 本帖最后由 jarjar 于 2007-11-6 09:36 编辑 ]

jarjar

(五)效果测试
Sybase IQ 与一般的关系型数据库的性能对比测试结果（主机CPU XEON ３G ,内存1G的NT服务器,IDE硬盘）

1.
单表总记录查询  （select count(*) from inet_p_mscadest）

	表的总记录数	查询时间
一般的关系型数据库	11976193	56.25s
IQ	26928865	16ms（时间基本恒定）

2.
单表有条件的记录总数查询（select count(*) from
INET_P_MSCADEST where collecttime between to_date('2005-1-1','yyyy-mm-dd') and to_date('2005-2-1','yyyy-mm-dd')）

	查询出的总记录数	查询时间
一般的关系型数据库	2977	54.844s
IQ	8929	16 ms

3.
单表记录有条件全部字段查询（select * from INET_P_MSCADEST where
collecttime between to_date('2005-1-1','yyyy-mm-dd') and to_date('2005-2-1','yyyy-mm-dd')  ）

	查询出的总记录数	查询时间
一般的关系型数据库	2977	43.953s, 44.031s，47.203s
IQ	8929	32ms ,16 ms

4.
插入单条记录（insert into INET_P_MSCADEST() values() ）

	总记录数	查询时间
一般的关系型数据库	1	31ms
IQ	1	62ms

按天分组查询（select to_char(collecttime,'yyyy-mm-dd') time,sum(t.granularity) from
INET_P_MSCADEST t where
collecttime
between to_date('2005-1-1','yyyy-mm-dd') and
to_date('2005-2-1','yyyy-mm-dd')
group by to_char(collecttime,'yyyy-mm-dd'),serverid,amoid,mscid,descrip ）

	分组后的记录数	查询时间
一般的关系型数据库	2977	55.539s（6个月的数据量）
IQ	8929	15ms　(6个月的数据量)

5.
按月分组查询

	分组后的记录数	查询时间
一般的关系型数据库	6	64.344s
IQ	6	0.531s

6.
按年分组查询

	分组后的记录数	查询时间
一般的关系型数据库	7	56.968s
IQ	11	0.031s

结论：

１）简单对比之下，发现IQ在数据查询方面至少比一般的关系型数据库的数据查询快了几个数量级。直接使用原始数据汇总天数据的时间消耗在100ms内，完全可以即席查询汇总。
２）对比单条入库记录的时间，一般的关系型数据库虽然比IQ快了几倍，但如果采用IQ的Load方式入库数据的话，效率在６万条记录1秒钟左右。即使是对上面例子中的超大数据量也适合（在1个数据粒度５分钟内，记录数为1000*10＝１万）。相对于一般的关系型数据库下的JDBC入库方式，1秒钟2000条的入库，效率快30倍。
３）IQ的查询汇总时间与表的总记录数关系不大。时间基本恒定。特别适合表的数据量超大的情况。
４）存储量比在一般的关系型数据库情况下缩减70%
５）QOS告警的即时性比原来的稍差。可能晚2-3分钟，极限情况下晚5分钟。这种一般情况下也是允许的。可以根据数据量适当调整QOS告警定时扫描周期。


[ 本帖最后由 jarjar 于 2007-11-6 09:38 编辑 ]