CN102158345A - 一种数据管理方法、装置和系统 - Google Patents
一种数据管理方法、装置和系统 Download PDFInfo
- Publication number
- CN102158345A CN102158345A CN2010102070975A CN201010207097A CN102158345A CN 102158345 A CN102158345 A CN 102158345A CN 2010102070975 A CN2010102070975 A CN 2010102070975A CN 201010207097 A CN201010207097 A CN 201010207097A CN 102158345 A CN102158345 A CN 102158345A
- Authority
- CN
- China
- Prior art keywords
- synchronous meter
- network element
- node
- pairing
- synchronous
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明实施例公开了一种数据管理方法、装置和系统。本发明实施例提供的数据管理方法包括:确定网元所对应的同步表;以及,接收配置指令,以配置所述网元所对应的内存数据库的节点;根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
Description
技术领域
本发明涉及数据库技术领域,尤其涉及一种数据管理方法、装置和系统。
背景技术
基于IP协议的电视广播服务(Internet Protocol Television,IPTV),能够将电视机或个人计算机作为显示终端,通过宽带网络向用户提供数字广播电视、视频服务、信息服务、互动社区、互动休闲娱乐、电子商务等多种宽带业务。
在IPTV系统中,为了保证系统中各个网元的正常工作,需要向各个网元提供必要的数据。随着对IPTV系统性能的要求越来越高,为了加快各个网元读取数据的速度,设置了内存数据库,任一网元可以从内存数据库的节点(该节点指任一内存数据库)中读取所需的数据,该数据通常以数据表的方式实现。并且,IPTV系统将包括核心数据的所有数据都存储在了磁盘数据库中,内存数据库从磁盘数据库中读取需要同步的数据表,保证内存数据库的数据表与磁盘数据库的数据表同步,以满足各个网元的业务需求。
不同的内存数据库的节点需要进行同步的数据表是不一样的,将需要进行同步的数据表称为同步表,则在进行组网时,必须预先配置IPTV服务器上内存数据库的节点与同步表之间的对应关系,以保证网元基于这种对应关系读取到所需的数据表。现有技术中通过手动直接配置内存数据库的节点与同步表的对应关系。
在实现本发明过程中,发明人发现现有技术中至少存在如下问题:
由于IPTV系统的性能不断提升,内存数据库的节点数量或者同步表的数量都不断地增多,配置的复杂度也不断提高,现有技术的方案操作繁琐、耗时较长、增加了运营商的负担,且出错概率较大,导致网元无法读取到所需的数据表,影响了IPTV系统的正常运行。
发明内容
为解决现有技术中存在的问题,本发明实施例提供了一种数据管理方法、装置和系统。
一方面,本发明实施例提供了一种数据管理方法,包括:
确定网元所对应的同步表;以及,
接收配置指令,以配置所述网元所对应的内存数据库的节点;
根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
另一方面,本发明实施例提供了一种数据管理装置,所述装置包括:
第一关联单元,用于确定网元所对应的同步表;
第二关联单元,用于接收配置指令,以配置所述网元所对应的内存数据库的节点;
生成单元,用于根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
再一方面,本发明实施例还提供了一种IPTV系统,该系统包括IPTV服务器,该IPTV服务器包括上述的数据管理装置。
本发明任一实施例的技术方案,在内存数据库的节点与同步表之间引入了作为第三方的网元,该网元同时与内存数据库的节点和同步表具有关联,利用这种关联生成内存数据库的节点与同步表的对应关系,克服了现有技术中需要人工手动直接配置内存数据库的节点与同步表的对应关系所带来的问题,显著简化了部署软件系统时的数据管理操作,提高了工作效率,降低了出错概率,保证了网元能够获取所需的数据表,保证了系统的正常运行。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1(a)为本发明实施例一提供了一种数据管理方法流程示意图;
图1(b)为本发明实施例一提供了另一种数据管理方法流程示意图;
图2(a)为现有的数据管理模型示意图;
图2(b)为本发明实施例二提供的数据管理模型示意图;
图3(a)为本发明实施例三提供的一种数据管理装置结构示意图;
图3(b)为本发明实施例三提供的另一种数据管理装置结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例的技术构思在于当在部署软件系统的过程中直接建立并管理第一业务数据实体和第二业务数据实体的操作比较繁琐时,引入“冗余信息”。这种“冗余信息”是一种具有在软件系统的部署过程中并不需要,但与第一业务数据实体和第二业务数据实体都关联的特性的信息。利用该“冗余信息”(如网元)在第一业务数据实体(如内存数据库的节点)和第二业务数据实体(如同步表)之间建立的关联,简化部署软件系统时数据的配置、管理操作,提高工作效率,改善系统的性能。
本发明实施例主要以IPTV系统中的数据管理的场景为例进行说明,但不局限于此,本领域普通技术人员可以将本发明实施例的技术方案应用于其它相似的部署软件系统的场景中。
为了便于清楚描述本发明实施例的技术方案,在本发明的实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分,本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定。
本发明的实施例一提供了一种数据管理方法,所述方法包括:
11:确定网元所对应的同步表;以及,
12:接收配置指令,以配置所述网元所对应的内存数据库的节点;
13:根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
在此,不严格限定上述步骤11和步骤12的执行时序,参见图1(a)和图1(b),根据不同的操作方式,可以同时实现网元与同步表的关联以及网元与内存数据库的节点的关联;也可以首先实现网元与同步表的关联,基于网元与同步表之间对应关系,建立网元与内存数据库的节点的关联。上述配置指令指示网元与内存数据库的节点的关系。
本发明实施例的技术方案,在内存数据库的节点与同步表之间引入了作为第三方的网元,该网元同时与内存数据库的节点和同步表具有关联,利用这种关联生成内存数据库的节点与同步表的对应关系,克服了现有技术中需要人工手动直接配置内存数据库的节点与同步表的对应关系所带来的问题,显著简化了部署软件系统时的数据管理操作,提高了工作效率,降低了出错概率,保证了网元能够获取所需的数据表,保证了系统的正常运行,改善了系统的性能。
下面对本发明实施例二提供的数据管理方法进行具体描述。
考虑到内存数据库的节点进行数据同步是为了满足网元的业务需要,从而在数据管理模型中引入了网元,而该网元在部署软件系统中并不是必需的。参见图2(a)和图2(b),图2(a)为现有的数据管理模型示意图;图2(b)为本发明实施例提供的数据管理模型示意图。可见本发明实施例所建立新的数据管理模型,无需修改原有的数据结构,很好地兼容了原有的资源。
本发明实施例的数据管理方法具体包括如下处理:
S1:确定网元所对应的同步表。
在本发明实施例中引入了“冗余信息”网元,本发明实施例中的网元可以由实现相应业务功能的模块实现,参见表1,示例性地显示了一组网元及其信息。
表1网元定义表
网元名称(CCOL1) | 网元描述(CCOL2) |
UA | 用户代理(user agent) |
tvmsg | 电视消息(tv message) |
AC/AU/Offline | 计费/鉴权/离线计费 |
shinedb | 内存数据库 |
presence_server | 呈现服务 |
adengine | 广告引擎 |
ac_cycle | 账务 |
signon | 认证 |
... | ... |
其中,表1中给出的网元的信息主要包括网元名称,用CCOL1简化表示;和网元描述,用CCOL2简化表示。
本发明实施例中的同步表主要指需要进行同步的数据表。参见表2,示例性地显示了本发明实施例提供的一组同步表的具体内容:
表2同步表定义表
同步表ID(ACOL1) | 同步表名(ACOL2) | 同步表行长(ACOL3) | 同步表记录数(ACOL4) | 同步表记录数计算规则(ACOL5) |
4 | 本地序列(LOCALSEQUENCE) | 20 | 200 | |
20001 | 语言(LANGUAGE) | 352 | 1000 | |
20003 | 类型(CATEGORYTYPE) | 108 | 100 | |
20006 | 广播(CASTROLE) | 108 | 100 | |
20009 | 节目(PROGRAM) | 804 | 13000 | vodno+videoadno |
20010 | 节目元(PROGRAMMETA) | 2612 | 26000 | (vodno+videoadno)*langno |
20011 | 节目内容(PROGRAMCONTENT) | 336 | 21000 | vodno*2+videoadno |
20012 | 节目广播(PROGRAMCAST) | 24 | 24000 | vodno*3 |
20013 | 频道(CHANNEL) | 912 | 1000 | channo |
从表2中可见,同步表的具体内容可以包括同步表标识(ID),用ACOL1简化表示;同步表名,用ACOL2简化表示;同步表行长,用ACOL3简化表示,指示该同步表中横向上所有列所占用的字节数;同步表记录数,用ACOL4简化表示,指示该同步表中纵向上所有行所占用的字节数;同步表记录数计算规则,用ACOL5简化表示,当存在该计算规则时,利用该计算规则得到相应的同步表记录数,当不存在该计算规则时,同步表记录数采用预设的固定值。
为了便于理解和方便实际的操作,基于业务的主要内容设置了表2中的同步表名,例如,命名为LANGUAGE的同步表,可以指示该同步表对应的业务主要涉及语言。但本发明实施例并不对同步表、数据量关键字、以及网元等项目的名称进行限定,例如上述表2中各同步表名可采用table1、table2至tablen命名,n为序号。
S2:接收配置指令,以配置所述网元所对应的内存数据库的节点。
将为加快网元读取数据的速度而设置的任一内存数据库称之为内存数据库的节点,参见表3,示例性地给出了一组内存数据库的节点的具体内容。
表3内存数据库的节点定义表
节点ID(ECOL1) | 节点名称(ECOL2) | 节点IP(ECOL3) | 节点描述(ECOL4) |
16001 | EPG-A | 10.0.16.1 | 描述1 |
16002 | EPG-B | 10.0.16.2 | 描述2 |
16003 | AAA1 | 10.0.16.3 | 描述3 |
16004 | AAA2 | 10.0.16.4 | 描述4 |
16005 | MPE | 10.0.16.5 | 描述5 |
16132 | MDC-A | 10.0.16.132 | 描述6 |
16133 | MDC-B | 10.0.16.133 | 描述7 |
... | ... | ... | ... |
由上述表3可以看出,内存数据库的节点的信息主要包括了节点标识(ID)、节点名称、节点网络地址(IP)和节点描述,其中,需要合理地配置各个内存数据库的节点的节点IP,以保证系统的正常运行。
对上述步骤S1和S2可至少按照如下两种方式操作:
方式一、
在步骤S1中将预定的同步表作为上述网元所对应的同步表。为了保证网元能够执行相应的功能,预先指定的同步表不应少于所述网元所需的同步表。在步骤S2中将预定的内存数据库的节点配置为所述网元所对应的内存数据库的节点,这时,需要保证上述预定的内存数据库的节点能够为网元提供相应的同步表。例如,当内存数据库的节点1能够提供同步表A、同步表B、同步表C和同步表D,内存数据库的节点2能够提供同步表A和同步表B,内存数据库的节点2的资源较丰富,可以优先将内存数据库的节点2作为预定的内存数据库的节点,或者,同时将内存数据库的节点1和内存数据库的节点2作为预定的内存数据库的节点。
这种方式,能够进一步简化网元、同步表之间以及网元、内存数据库的节点之间关联的建立,适用于网元功能相对简单(根据其功能易于确定出所需的同步表)、内存数据库的节点资源比较丰富的场景。
方式二、
在步骤S1中根据所述网元的业务,统计所述网元的需要同步的数据表,得到所述网元所对应的同步表。由于当网元满足一定业务时,执行的功能是固定的,所需的同步表也是固定的,所以可以对网元的所需的同步表进行统计,准确得到网元所对应的同步表,在步骤S2中仅在存储有所述网元所对应的同步表的内存数据库的节点中,配置所述网元所对应的内存数据库的节点。例如,当确定网元对应于同步表C和同步表D时,仅将上述内存数据库的节点1配置为所述网元所对应的内存数据库的节点。
这种方式使网元、同步表之间以及网元、内存数据库的节点之间建立的关联更加准确,不但精确保证了网元能够获取到所需的同步表,而且提高了资源的利用效率。并且,对于IPTV服务器能够在初始化过程中自动统计并生成网元所对应的同步表的场景,采用本方式操作简单。
并不对上述步骤S1和S2的执行次序进行限定,例如,可以上述步骤S1可以在IPTV系统的初始化过程中执行,而步骤S2在初始化过程之后再执行;或者,上述S1和S2都在IPTV系统的初始化过程之后再执行。
S3:根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
利用上述步骤S1得到的网元与同步表的对应关系,可以参见如下表4:
表4网元与同步表的关联表
网元名称(CCOL1) | 同步表ID(ACOL1) |
presence_server | 30010 |
presence_server | 30011 |
presence_server | 30012 |
UA | 20028 |
adengine | 30107 |
tvmsg | 20809 |
UA | 60005 |
UA | 20106 |
网元名称(CCOL1) | 同步表ID(ACOL1) |
tvmsg | 20105 |
表4中示例性地给出了利用网元名称与同步表ID建立网元与同步表的对应关系的场景。
利用上述步骤S2得到的网元与内存数据库的节点的对应关系,可以参见如下表5:
表5网元与内存数据库的节点的关联表
节点ID(ECOL1) | 网元名称(CCOL1) |
172206 | shinedb |
172207 | shinedb |
172206 | epg |
172206 | AC/AU/Offline |
172206 | sdps |
172206 | signon |
172207 | epg |
172207 | AC/AU/Offline |
172207 | sdps |
表5中示例性地给出了利用网元名称与内存数据库的节点的节点ID建立网元与内存数据库的节点的对应关系的场景。
由上述表4和表5可以清楚看出,在内存数据库的节点和同步表之间引入了网元,网元的相关信息(如网元名称)与内存数据库的节点和同步表都具有关联,通过网元的相关信息(如网元名称)建立了内存数据库的节点和同步表之间的关联关系表,参见表6,显示了本发明实施例提供的一种内存数据库的节点和同步表的关联关系。利用这种关联关系,IPTV服务器可自动生成内存数据库的节点和同步表的对应关系。IPTV服务器利用该关联关系将内存数据库的节点对应于相应的同步表,再去除作为“冗余信息”的网元,即可得到内存数据库的节点和同步表的对应关系,如图6中所示的关联关系表。根据该对应关系,内存数据库的节点从磁盘数据库读取需要同步的数据表,使内存数据库的节点的数据与磁盘数据库中的数据保持同步,从而使网元能够从内存数据库的节点中读取到相应的同步表。
表6内存数据库的节点和同步表的关联关系表
内存数据库节点ID(COL1) | 同步表ID(COL2) | 同步表名(COL3) | 同步表行长(COL4) | 同步表记录数(COL5) |
172206 | 1 | CACHE_TABLE_DIC | 48 | 1024 |
172206 | 2 | CACHE_FIELD_DIC | 52 | 10240 |
172206 | 3 | CACHE_INDEX_DIC | 120 | 10240 |
172206 | 4 | LOCALSEQUENCE | 20 | 200 |
172206 | 20008 | CASTMETA | 596 | 30000 |
172206 | 20009 | PROGRAM | 804 | 13000 |
172206 | 20010 | PROGRAMMETA | 2612 | 26000 |
172206 | 20011 | PROGRAMCONTENT | 336 | 21000 |
172206 | 20012 | PROGRAMCAST | 24 | 24000 |
172206 | 20013 | CHANNEL | 912 | 1000 |
172207 | 20022 | CONTENTPACKAGEDETAIL | 52 | 15000 |
172207 | 20025 | CHANNELNUMBERFORHOTEL | 52 | 5000 |
172207 | 20028 | SHINENODE | 152 | 50 |
172207 | 20029 | EPG | 220 | 1000 |
172207 | 20030 | NORMALFILES | 520 | 1000 |
172207 | 20031 | CATEGORYPROMOTION | 24 | 7500 |
... | ... | ... | ... | ... |
由上所述,可以看出,通过预先指定网元所对应的同步表或者统计生成网元所对应的同步表,本发明实施例在组网过程中仅需配置内存数据库的节点和网元之间的关系,无需查找同步表的字段信息表、内存数据库的索引表等字典表,克服了现有技术中需要人工手动直接配置内存数据库的节点与同步表的对应关系所带来的问题,显著简化了部署软件系统时的数据管理操作,提高了工作效率,降低了出错概率,保证了网元能够获取所需的数据表,保证了系统的正常运行,改善了系统的性能。
进一步的,由于现有技术中内存数据库的节点在建库时就固定了各同步表的数据量,无法再进行调整,并且,在进行数据管理时不能获知内存数据库的节点实际占有的内存,导致数据管理效率低下,影响了系统的性能,本发明实施例还可以从各个维度计算占有内存的大小,为实际部署提供参考依据,例如,通过结构化查询语言(Structured Query Language,SQL)实现各个维度内存的计算,具体的,至少包括如下维度的内存计算:
1:计算同步表在内存数据库的节点中占用的内存。
设置数据量关键字以及所述数据量关键字的数值,根据所述数据量关键字的数值和预定规则计算所述同步表的同步表记录数,利用所述同步表记录数计算所述同步表所占用的内存。通过这种方式计算一些数据量较大,或者数据量变化频繁的同步表,可以有效监测内存数据库的节点实际所占用内存的变化;而对于一些数据量较小或者数据量较稳定的同步表,仍可以直接采用固定的数据量。
上述的预定规则参见表2中的同步表记录数计算规则,该预定规则是根据所述同步表所对应业务的特性抽样得到的。当为同步表设置了同步表记录数计算规则,该同步表的同步表记录数由同步表记录数计算规则计算得到,参见名称为“PROGRAM”的同步表,其同步表记录数(13000)是由同步表记录数计算规则计算得到的;当同步表不存在同步表记录数计算规则,如名称为“LANGUAGE”的同步表,其同步表记录数采用固定的数值。
其中,上述同步表记录数计算规则中的数据量关键字及其数值,可根据实际的业务需要进行设置,参见表7,显示了一组可采用的数据量关键字的定义及其数值。
当计算得到的某一同步表所占用的内存过大,或者,业务要求发生了变化时,可以利用关键字调整同步表所占用的内存。例如,对数据量关键字的数值进行调整,根据调整后的所述数据量关键字的数值和所述预定规则计算所述同步表的更新后的同步表记录数,由更新后的同步表记录数重新计算同步表所占用的内存,可以反复进行上述调整操作,直至同步表所占用的内存满足要求。
本发明实施例可以根据如下公式,利用所述同步表记录数计算所述同步表所占用的内存:
同步表占用的内存=同步表记录数*(同步表行长+额外开销)+同步表记录数*内存库索引节点个数*每个索引节点的大小+(同步表记录数*保存索引值的空间大小+额外开销)*内存库索引节点个数。
对于上述公式,同步表记录数*(同步表行长+额外开销)部分表示业务数据占用的内存大小;同步表记录数*内存库索引个数*每个索引节点的大小部分表示索引数据占用的内存大小;(同步表记录数*保存索引值的空间大小+额外开销)*内存库索引个数部分表示存储管理数据和索引的开销数据占用的内存。
其中,同步表记录数和同步表行长参见表2,额外开销和保存索引值的空间大小为系统参数,如额外开销为8字节。内存数据库采用索引值搜索到索引节点,再根据索引节点查找到同步表。内存数据库需要保存索引值,该索引值可以由哈希(Hash)值实现,示例性的,保存索引值的空间大小可以为4字节。
每个索引节点的大小指示索引节点存储在内存数据库的节点中的位置信息。对于内存库索引节点个数和可以通过IPTV初始化过程中的内存数据库的索引表得到,参见表8。其中,同步表ID为20027的同步表对应的内存库索引节点的个数为3,同步表ID为20028的同步表对应的内存库索引节点的个数为2。
表7数据量关键字的定义及其数值
关键字类型(BCOL1) | 关键字描述(BCOL2) | 数值(BCOL3) |
vodhours | vod总时长 | 9000 |
tvodhours | tvod总时长 | 5000 |
fsnodeno | shineFSnode数量 | 5 |
appno | app的数量 | 10 |
mtvno | MTV数目 | 400 |
channo | 频道数 | 250 |
vodno | vod(包含连续剧)数目 | 9000 |
cateno | 分类数目 | 500 |
tvodno | tvod数目 | 5000 |
hotelno | 酒店数目 | 5 |
icspno | ICSP数量 | 50 |
pubusemo | 公众用户数 | 1000000 |
hotelusemo | 酒店用户数 | 10 |
admno | 广告机用户数 | 10 |
virchanno | 虚拟频道数 | 20 |
videoadno | 视频广告数量 | 1000 |
imageadno | 图片广告数量 | 500 |
verno | 支持升级的次数 | 100 |
listno | 播放列表数目 | 500 |
langno | 系统语言种类 | 2 |
表8内存数据库的索引表
同步表ID | 索引ID | 索引名 | 是否唯一 | 索引类型 | 排序类型 | 索引字段1 | 索引字段n | 索引字段8 | 排序字段1 | 排序字段n | 排序字段 |
20025 | 1 | 20025_IDX002 | 0 | 1 | 3 | 2 | 0 | 0 | 4 | 0 | 0 |
20026 | 0 | 20026_IDX001 | 1 | 1 | 3 | 1 | 0 | 0 | 1 | 0 | 0 |
20026 | 1 | 20026_IDX002 | 0 | 1 | 3 | 2 | 0 | 0 | 1 | 0 | 0 |
20027 | 0 | 20027_IDX000 | 1 | 1 | 3 | 1 | 0 | 0 | 1 | 0 | 0 |
20027 | 1 | 20027_IDX001 | 0 | 1 | 3 | 2 | 0 | 0 | 1 | 0 | 0 |
20027 | 2 | 20027_IDX002 | 0 | 1 | 3 | 3 | 0 | 0 | 1 | 0 | 0 |
20028 | 0 | 20028_IDX000 | 1 | 1 | 3 | 1 | 0 | 0 | 1 | 0 | 0 |
20028 | 1 | 20028_IDX001 | 0 | 1 | 3 | 6 | 0 | 0 | 1 | 0 | 0 |
20029 | 0 | 20029_IDX000 | 1 | 1 | 3 | 1 | 0 | 0 | 1 | 0 | 0 |
... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
通过上述计算获知同步表所占用内存的大小,针对超大数据量的同步表可以进行单独调整,以在保证业务正常进行时,满足IPTV服务器的内存容量的要求。
2、计算内存数据库的节点所占用的内存。
计算组网时,每个内存数据库的节点占用IPTV服务器的总内存,该总内存包括该内存数据库的节点中同步表所占用的内存,从而验证部署方案是否合理,IPTV服务器的配置是否满足需要。该内存数据库的节点所占用的内存可以通过将该节点所对应的所有同步表的所占用的内存叠加得到。
3、计算网元在内存数据库的节点上占用的内存。
计算每个网元所对应的全部同步表在内存数据库的节点上占用的内存,从而为重新部署方案提供参考信息。该网元所占用的内存可以通过将该网元所对应的所有同步表的所占用的内存叠加得到。
4、计算内存数据库的节点全量同步时占用的内存。
全量同步指由一个内存数据库的节点同步IPTV服务器上所有同步表,该同步表包括IPTV服务器上各个节点需要从磁盘数据库同步到内存数据库里的所有表。可以通过计算各个节点上每个同步表占用内存之后再叠加计算得到,从而验证IPTV服务器的配置是否满足需要。
可以根据需要选取上述四种维度内存计算中的一种或多种,为实际部署软件系统提供参考依据。
本发明实施例的技术方案,引入网元的信息,建立新的数据管理模型,且无需改动原有的数据结构,很好地兼容了原有的资源,简化了配置过程,提高了工作效率,改善了系统的性能。
本发明实施例三还提供了一种数据管理装置,参见图3,所述装置包括:
第一关联单元31,用于确定网元所对应的同步表;
第二关联单元32,用于接收配置指令,以配置所述网元所对应的内存数据库的节点;
生成单元33,用于根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
其中,上述配置指令指示所述网元与内存数据库的节点的对应关系。
参见图3(a)和图3(b),显示了在不同的工作方式下,上述装置的结构示意图。
进一步的,所述第一关联单元31,用于将预定的同步表作为所述网元所对应的同步表;以及,所述第二关联单元32,用于接收配置指令,以将预定的内存数据库的节点作为所述网元所对应的内存数据库的节点;或者,
所述第一关联单元31,用于根据所述网元的业务,统计所述网元的需要同步的数据表,得到所述网元所对应的同步表;以及,所述第二关联单元32,用于接收配置指令,以仅在存储有所述网元所对应的同步表的内存数据库的节点中,配置所述网元所对应的内存数据库的节点。
进一步的,所述装置还包括:
同步表内存计算单元,用于设置数据量关键字以及所述数据量关键字的数值;根据所述数据量关键字的数值和预定规则计算所述同步表的同步表记录数;利用所述同步表记录数计算所述同步表所占用的内存。
其中,所述同步表内存计算单元还包括调整模块,用于调整所述数据量关键字的数值;所述同步表内存计算单元,还用于根据所述调整模块根据调整后的所述数据量关键字的数值和所述预定规则计算所述同步表的更新后的同步表记录数;利用所述更新后的同步表记录数计算所述同步表所占用的内存。
本发明装置实施例中各功能模块和单元的具体工作方式参见本发明方法实施例。本发明装置实施例中各功能模块和单元可以单独实现,也可以集成在一个或多个单元中实现。
本发明实施例的技术方案,在内存数据库的节点与同步表之间引入了作为第三方的网元,该网元同时与内存数据库的节点和同步表具有关联,利用这种关联生成所述内存数据库的节点与所述同步表的对应关系,克服了现有技术中需要人工手动直接配置内存数据库的节点与同步表的对应关系所带来的问题,显著简化了部署软件系统时的数据管理操作,提高了工作效率,降低了出错概率,保证了网元能够获取所需的数据表,保证了系统的正常运行,改善了系统的性能。
本发明又一实施例还提供了本发明实施例还提供了一种IPTV系统,该系统包括包括IPTV服务器,该IPTV服务器包括上述数据管理装置。该数据管理装置的具体工作方式参见本发明的方法实施例和装置实施例。
本发明实施例的技术方案,在内存数据库的节点与同步表之间引入了作为第三方的网元,该网元同时与内存数据库的节点和同步表具有关联,利用这种关联生成所述内存数据库的节点与所述同步表的对应关系,克服了现有技术中需要人工手动直接配置内存数据库的节点与同步表的对应关系所带来的问题,显著简化了IPTV系统中的数据管理操作,提高了工作效率,降低了出错概率,保证了网元能够获取所需的数据表,保证了IPTV系统的正常运行,改善了IPTV系统的性能。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,包括如下步骤:确定网元所对应的同步表;以及,配置所述网元所对应的内存数据库的节点;根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表,所述的存储介质,如:ROM/RAM、磁碟、光盘等。
Claims (11)
1.一种数据管理方法,其特征在于,所述方法包括:
确定网元所对应的同步表;以及,
接收配置指令,以配置所述网元所对应的内存数据库的节点;
根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
2.根据权利要求1所述的方法,其特征在于,所述确定网元所对应的同步表,以及,接收配置指令,以配置所述网元所对应的内存数据库的节点包括:
将预定的同步表作为所述网元所对应的同步表,以及,接收配置指令,以将预定的内存数据库的节点作为所述网元所对应的内存数据库的节点;或者,
根据所述网元的业务,统计所述网元的需要同步的数据表,得到所述网元所对应的同步表,以及,接收配置指令,以仅在存储有所述网元所对应的同步表的内存数据库的节点中,配置所述网元所对应的内存数据库的节点。
3.根据权利要求1所述的方法,其特征在于,所述方法还包括:
设置数据量关键字以及所述数据量关键字的数值;
根据所述数据量关键字的数值和预定规则计算每一个所述同步表的同步表记录数;
利用所述同步表记录数计算每一个所述同步表所占用的内存。
4.根据权利要求3所述的方法,其特征在于,根据如下公式,利用所述同步表记录数计算每一个所述同步表所占用的内存:
同步表占用的内存=同步表记录数*(同步表行长+额外开销)+同步表记录数*内存库索引节点个数*每个索引节点的大小+(同步表记录数*保存索引值的空间大小+额外开销)*内存库索引节点个数。
5.根据权利要求3或4所述的方法,其特征在于,在所述利用所述同步表记录数计算每一个所述同步表所占用的内存之后,所述方法还包括:
调整所述数据量关键字的数值;
根据调整后的所述数据量关键字的数值和所述预定规则计算所述同步表的更新后的同步表记录数;
利用所述更新后的同步表记录数计算所述同步表所占用的内存。
6.根据权利要求3或4所述的方法,其特征在于,所述方法还包括:
将每一个所述内存数据库的节点所对应的同步表所占用的内存进行叠加,计算得到每一个所述内存数据库的节点所占用的内存;和/或
将每一个所述网元所对应的同步表所占用的内存进行叠加,计算得到每一个所述网元所占用的内存;和/或
将所有所述内存数据库的节点所对应的同步表所占用的内存进行叠加,计算得到任一个所述内存数据库的节点执行全量同步时所占用的内存。
7.一种数据管理装置,其特征在于,所述装置包括:
第一关联单元,用于确定网元所对应的同步表;
第二关联单元,用于接收配置指令,以配置所述网元所对应的内存数据库的节点;
生成单元,用于根据所述网元所对应的内存数据库的节点以及所述网元所对应的同步表,生成所述内存数据库的节点与所述同步表的对应关系,以根据所述对应关系使所述网元读取到相应的同步表。
8.根据权利要求7所述的装置,其特征在于,
所述第一关联单元,用于将预定的同步表作为所述网元所对应的同步表;以及,所述第二关联单元,用于接收配置指令,以将预定的内存数据库的节点作为所述网元所对应的内存数据库的节点;
或者,
所述第一关联单元,用于根据所述网元的业务,统计所述网元的需要同步的数据表,得到所述网元所对应的同步表;以及,所述第二关联单元,用于接收配置指令,以仅在存储有所述网元所对应的同步表的内存数据库的节点中,配置所述网元所对应的内存数据库的节点。
9.根据权利要求7所述的装置,其特征在于,所述装置还包括:
同步表内存计算单元,用于设置数据量关键字以及所述数据量关键字的数值;根据所述数据量关键字的数值和预定规则计算每一个所述同步表的同步表记录数;利用所述同步表记录数计算每一个所述同步表所占用的内存。
10.根据权利要求9所述的装置,其特征在于,所述同步表内存计算单元还包括调整模块,
所述调整模块,用于调整所述数据量关键字的数值;
所述同步表内存计算单元,还用于根据所述调整模块根据调整后的所述数据量关键字的数值和所述预定规则计算所述同步表的更新后的同步表记录数;利用所述更新后的同步表记录数计算所述同步表所占用的内存。
11.一种IPTV系统,所述系统包括IPTV服务器,其特征在于,所述IPTV服务器包括如权利要求7至10任一项所述的数据管理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010207097 CN102158345B (zh) | 2010-06-23 | 2010-06-23 | 一种数据管理方法、装置和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201010207097 CN102158345B (zh) | 2010-06-23 | 2010-06-23 | 一种数据管理方法、装置和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102158345A true CN102158345A (zh) | 2011-08-17 |
CN102158345B CN102158345B (zh) | 2013-06-05 |
Family
ID=44439546
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 201010207097 Active CN102158345B (zh) | 2010-06-23 | 2010-06-23 | 一种数据管理方法、装置和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102158345B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102323940A (zh) * | 2011-09-01 | 2012-01-18 | 中兴通讯股份有限公司 | 基于数据库的配置台实现方法、配置台及系统 |
CN102880704A (zh) * | 2012-09-25 | 2013-01-16 | 上海证券交易所 | 一种新型的并发内存数据组织与访问方法 |
CN105630864A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 存储行标识符值的字典的强制排序 |
WO2019062710A1 (zh) * | 2017-09-30 | 2019-04-04 | 华为技术有限公司 | 通信方法及其通信设备 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101136773A (zh) * | 2007-03-05 | 2008-03-05 | 中兴通讯股份有限公司 | 网元配置数据的备份与恢复方法 |
CN101158871A (zh) * | 2007-11-12 | 2008-04-09 | 浙江大学 | 集散控制系统操作员站内存数据库结构存储的同步方法 |
CN101197694A (zh) * | 2006-12-04 | 2008-06-11 | 中兴通讯股份有限公司 | 一种通讯系统日志集中统计、处理系统及其方法 |
CN101369283A (zh) * | 2008-09-25 | 2009-02-18 | 中兴通讯股份有限公司 | 一种内存数据库与物理数据库间的数据同步方法及系统 |
CN101526940A (zh) * | 2008-03-19 | 2009-09-09 | 中兴通讯股份有限公司 | 一种应用系统物理数据库与内存数据库的数据同步方法 |
-
2010
- 2010-06-23 CN CN 201010207097 patent/CN102158345B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101197694A (zh) * | 2006-12-04 | 2008-06-11 | 中兴通讯股份有限公司 | 一种通讯系统日志集中统计、处理系统及其方法 |
CN101136773A (zh) * | 2007-03-05 | 2008-03-05 | 中兴通讯股份有限公司 | 网元配置数据的备份与恢复方法 |
CN101158871A (zh) * | 2007-11-12 | 2008-04-09 | 浙江大学 | 集散控制系统操作员站内存数据库结构存储的同步方法 |
CN101526940A (zh) * | 2008-03-19 | 2009-09-09 | 中兴通讯股份有限公司 | 一种应用系统物理数据库与内存数据库的数据同步方法 |
CN101369283A (zh) * | 2008-09-25 | 2009-02-18 | 中兴通讯股份有限公司 | 一种内存数据库与物理数据库间的数据同步方法及系统 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102323940A (zh) * | 2011-09-01 | 2012-01-18 | 中兴通讯股份有限公司 | 基于数据库的配置台实现方法、配置台及系统 |
WO2012155643A1 (zh) * | 2011-09-01 | 2012-11-22 | 中兴通讯股份有限公司 | 基于数据库的配置台实现方法、配置台及系统 |
CN102880704A (zh) * | 2012-09-25 | 2013-01-16 | 上海证券交易所 | 一种新型的并发内存数据组织与访问方法 |
CN105630864A (zh) * | 2014-11-25 | 2016-06-01 | Sap欧洲公司 | 存储行标识符值的字典的强制排序 |
WO2019062710A1 (zh) * | 2017-09-30 | 2019-04-04 | 华为技术有限公司 | 通信方法及其通信设备 |
US11451286B2 (en) | 2017-09-30 | 2022-09-20 | Huawei Technologies Co., Ltd. | Communication method and communications device thereof |
Also Published As
Publication number | Publication date |
---|---|
CN102158345B (zh) | 2013-06-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109739929B (zh) | 数据同步方法、装置及系统 | |
CN101242356B (zh) | Iptv系统中内存数据库的实现方法及iptv系统 | |
US9934290B1 (en) | Systems and methods for dynamic sharding of hierarchical data | |
US7523124B2 (en) | Methods and apparatus for improving data warehouse performance | |
US8862607B2 (en) | Content receiving apparatus with search query generator | |
US20200213633A1 (en) | Extending Data Records for Dynamic Data and Selective Acceptance Based on Hardware Profile | |
CN107071511A (zh) | 提供客户端接收的广播视频流的倒回的方法及计算机系统 | |
US9235613B2 (en) | Flexible partitioning of data | |
CN104104717A (zh) | 投放渠道数据统计方法及装置 | |
CN102638584A (zh) | 数据分布缓存方法及系统 | |
US20180144001A1 (en) | Database transformation server and database transformation method thereof | |
CN102158345B (zh) | 一种数据管理方法、装置和系统 | |
CN105405070A (zh) | 一种分布式内存电网系统构建方法 | |
TW201507453A (zh) | 網路媒介資訊的播放方法及回應處理方法與系統、播放裝置、服務側裝置與機器可讀取儲存介質 | |
CN108154376B (zh) | 数据处理方法及装置 | |
US7110997B1 (en) | Enhanced ad-hoc query aggregation | |
CN106897338A (zh) | 一种针对数据库的数据修改请求处理方法及装置 | |
CN111382182A (zh) | 数据处理方法、装置、电子设备及存储介质 | |
CN101699443B (zh) | 一种管理网络文件的方法和装置 | |
US7856460B2 (en) | Device, method, and computer program product for structuring digital-content program | |
US9479839B2 (en) | Method and system for providing a representative phrase based on keyword searches | |
CN103731478A (zh) | 一种基于用户访问时间的内容发布方法及系统 | |
CN102289494A (zh) | 一种视频点播单双向web导航页面生成系统与生成方法 | |
CN104284217A (zh) | 网络收视统计方法和装置 | |
CN111178965B (zh) | 一种资源投放方法及服务器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C41 | Transfer of patent application or patent right or utility model | ||
TR01 | Transfer of patent right |
Effective date of registration: 20170123 Address after: 266100 Shandong Province, Qingdao city Laoshan District Songling Road No. 399 Patentee after: Poly Polytron Technologies Inc Address before: 266071 Laoshan, Qingdao province Hongkong District No. East Road, room 248, room 131 Patentee before: Hisense Media Networks Co., Ltd. |