CN105184550B - 管理排期数据的方法、服务器及系统 - Google Patents
管理排期数据的方法、服务器及系统 Download PDFInfo
- Publication number
- CN105184550B CN105184550B CN201510641007.6A CN201510641007A CN105184550B CN 105184550 B CN105184550 B CN 105184550B CN 201510641007 A CN201510641007 A CN 201510641007A CN 105184550 B CN105184550 B CN 105184550B
- Authority
- CN
- China
- Prior art keywords
- information
- presented
- data
- data information
- storage cell
- 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.)
- Active
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了管理排期数据的方法、服务器及系统。其中服务器包括第一数据存储单元、第二数据存储单元、接收单元、判断单元、第一存储引擎、第二存储引擎和查询引擎。接收单元适于接收来自客户端的一个或者多个待呈现信息的原始排期数据信息。判断单元适于判断原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠。第一存储引擎,在判断单元确定未发生重叠时,适于将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段。第一存储引擎将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中。
Description
技术领域
本发明涉及互联网领域,尤其涉及管理排期数据的方法、服务器及系统。
背景技术
随着互联网的快速发展与普及,网络已成为信息获取的重要来源。网络中各种网络平台都会被投放大量的信息内容以便用户浏览。所说的信息内容可以是新闻、广告、音乐、视频等多媒体信息内容。例如网站在装备呈现信息内容时,需要对信息呈现的位置、时间和展示方式等数据进行排期管理。排期管理是对排期数据进行管理。例如,一条排期数据包括投放位置、投放时间、定向属性等多种排期参数。这样,排期管理所需要处理的排期数据为数量巨大的多维度数据。
目前的排期管理系统通常采用单一的关系型数据库存储方式,将排期数据分表存储,并在需要查询排期数据时连表查询。这样,对大量的排期数据进行查询时,查询效率会很低。
发明内容
为此,本发明提供一种新的管理排期数据的方案,以力图解决或者至少缓解上面存在的问题。
根据本发明的一个方面,提供一种管理排期数据的方法,适于在服务器中执行。该服务器包括第一数据存储单元和第二数据存储单元。第一数据存储单元中存储一个或者多个第一排期数据信息。第二数据存储单元中存储一个或者多个第二排期数据信息。其中,第一排期数据信息包括待呈现信息的呈现位置和呈现时间段。呈现时间段包括开始时间和结束时间。第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表。该方法包括接收来自客户端的一个或者多个待呈现信息的原始排期数据信息。其中每个待呈现信息的原始排期数据信息包括待呈现信息的呈现位置和呈现时间单元集合。管理排期数据的方法还包括判断该原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠。如果未发生重叠,管理排期服务器的方法还包括下述两个步骤。第一个,将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段。并且,将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中。第二个,将原始排期数据信息的呈现时间单元集合连同这个集合对应的呈现位置和待呈现信息作为一个第二排期数据信息、存储到第二数据存储单元中。第二排期数据信息中的呈现时间单元集合被存储为呈现时间单元列表。
根据本发明的又一个方面,提供一种管理排期数据的服务器。该服务器包括第一数据存储单元、第二数据存储单元、接收单元、判断单元、第一存储引擎、第二存储引擎和查询引擎。第一数据存储单元适于存储一个或者多个第一排期数据信息。第一排期数据信息包括待呈现信息的呈现位置和呈现时间段。呈现时间段包括开始时间和结束时间。第二数据存储单元适于存储一个或者多个第二排期数据信息。第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表。接收单元适于接收来自客户端的一个或者多个待呈现信息的原始排期数据信息。每个待呈现信息的原始排期数据信息包括该待呈现信息的呈现位置和呈现时间单元集合。判断单元适于判断原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠。第一存储引擎,在判断单元确定未发生重叠时,适于将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段。第一存储引擎将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中。第二存储引擎,在判断单元确定未发生重叠时,适于将原始排期数据信息的呈现时间单元集合连同这个集合对应的呈现位置和待呈现信息作为一个第二排期数据信息存储到第二数据存储单元中。第二排期数据信息中的呈现时间单元集合被存储为呈现时间单元列表。
根据本发明的又一个方面,提供一种管理排期数据的系统,包括客户端和根据本发明的管理排期数据的服务器。其中客户端适于生成一个或者多个呈现信息的原始排期数据信息。
根据本发明的管理排期数据的技术方案,能够将排期数据以两种格式分别存储到第一数据存储单元(例如,MySQL数据库)和第二数据存储单元(例如,MongoDB数据库)中。这样,两种数据存储单元中排期数据信息可以互为备份,提高了数据的安全性。进一步,管理排期数据的方案通过划分时间段的方式将原始排期数据信息存储为第一存储单元中的第一排期数据信息,极大节省了第一存储单元中的存储空间。另外,管理排期数据的方案通过将原始排期数据信息封装为第二数据存储单元中一个包括呈现时间单元列表的第二排期数据信息。这样,尽管排期数据的数据量很大(例如100万数量级以上),根据本发明的管理排期数据的方案可以对第二数据存储单元中排期数据进行快速查询。再者,由于例如MongoDB的第二存储单元本身支持动态扩展,使得根据本发明的方案可以对排期数据的存储进行快速扩展。
附图说明
为了实现上述以及相关目的,本文结合下面的描述和附图来描述某些说明性方面,这些方面指示了可以实践本文所公开的原理的各种方式,并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述,本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开,相同的附图标记通常指代相同的部件或元素。
图1示出了根据本发明一些实施例的管理排期数据的系统100示意图;
图2示出了根据本发明一个实施例客户端的GUI界面;
图3示出了根据本发明一个实施例的管理排期数据的服务器300的框图;以及
图4示出了根据本发明一个实施例的管理排期数据的方法400流程图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
图1示出了根据本发明一些实施例的管理排期数据的系统100示意图。
如图1所示,系统100包括客户端110和管理排期数据的服务器120。客户端110是适于生成原始排期数据信息的计算设备。这里计算设备可以实现为小尺寸便携(或者移动)电子设备的一部分,这些电子设备可以是诸如蜂窝电话、个人数字助理(PDA)、个人媒体播放器设备、无线网络浏览设备、个人头戴设备、应用专用设备、或者可以包括上面任何功能的混合设备。计算设备还可以实现为包括桌面计算机和笔记本计算机配置的个人计算机。原始排期数据信息是指待呈现信息的呈现位置和呈现时间进行安排所生成的数据。这里的待呈现信息可以是适于在例如网页中显示的广告、新闻和通知等,但不受限于此。这里的呈现位置由多种参数共同确定。呈现位置的参数包括但不限于呈现位置名称、呈现设备属性、呈现信息的路径、呈现信息的定向属性、呈现信息在网页中的位置和呈现信息轮播标识。下面依次对呈现位置的参数进行说明。呈现位置名称是对用于呈现信息的资源位置的名称表示,便于用户分辨不同的呈现位置。呈现设备属性值例如包括PC端和移动终端等。换言之,在两个呈现位置的参数维度一致时,一个呈现设备属性为PC端,而另一个为移动终端,那这两个呈现位置为不同的呈现位置。呈现信息的路径例如为网页的路径。呈现信息在网页中的位置为网页中具体位置,例如页面的顶栏或者边栏等。一个网页中的具体位置可以在同一日期内滚动播放信息。例如一个具体位置在一天内共有3个呈现信息进行轮播,则每个呈现信息会对应一个轮播标识。呈现信息的定向属性为按照获取信息的人群进行划分的属性。例如按照不同的地域划分后,不同省份的IP地址在浏览同一网页时,所呈现的信息内容可以不同。总而言之,呈现位置由多个参数共同确定。由于呈现位置的参数维度通常较高,因此呈现位置资源是十分巨大的。在确定一个呈现位置后,呈现时间单元集合为对该呈现位置上可以选择的时间单元的选定集合。这里的时间单元例如为一天。当然,时间单元也可以是以小时为单元或者以月为单位,本发明对此不做限定。
如图2示出了根据本发明一个实施例的客户端110的UI界面。
图2示出了呈现位置和日期的二维列表。该列表以天为时间单位。其中已占用的时间单元和未占用时间单元被区别显示为不同颜色。已占用的时间单元(例如正式合同、预定合同的时间单元)处于锁定状态。列表中未被占用的时间单元处于未锁定状态,可以被选定。客户端110可以将一个呈现位置上选定的时间单元集合连同这个呈现位置和所要呈现信息生成一个原始排期数据信息。当然,客户端110可以同时生成多个原始排期数据信息。
如上所述,客户端110在生成一个或者多个原始排期数据信息后,可以将生成的信息发送到服务器120,以便排期服务器将原始排期数据信息进行存储管理。
图3示出了根据本发明一个实施例管理排期数据的服务器300的框图。如图3所示,服务器300包括第一数据存储单元310、第二数据存储单元320、接收单元330、判断单元340、第一存储引擎350、第二存储引擎360和查询引擎370。
第一数据存储单元310适于存储一个或多个第一排期数据信息。这里第一排期数据信息包括待呈现信息的呈现位置和呈现时间段。其中呈现时间段包括开始时间和结束时间。第二数据存储单元320适于存储一个或者多个第二排期数据信息。这里第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表。第一数据存储单元310为关系型数据库,例如为MySQL数据库,但不限于此。第二数据存储单元320为nosql数据库,例如为MongoDB数据库。在根据本发明一些实施例中,第一、第二数据存储单元也可以是与服务器300耦接的独立数据库服务器,本发明对此不做限定。
查询引擎370适于对第二数据存储单元320中所有的第二排期数据信息建立一个或多个索引。这里,一个索引为按照呈现日期或呈现位置中一个参数而建立的索引项。查询引擎370可以根据该索引对第二排期数据信息进行快速查询。
接收单元330适于从客户端(例如上文中客户端110)接收一个或者多个待呈现信息的原始排期数据信息。每个待呈现的原始排期数据信息包括该待呈现信息的呈现位置和呈现时间单元集合。
判断单元340适于判断原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠。在根据本发明一些实施例中,判断单元340会将该原始排期数据信息中呈现位置作为索引值,指示查询引擎370从第二数据存储单元320中查询满足索引值的第二排期数据信息。换言之,查询引擎370从第二数据存储单元320中查询该呈现位置上已占用的时间单元集合。判断单元340判断原始排期数据信息中呈现时间单元集合与所查询到的已占用时间单元集合是否存在重叠。如果存在重叠,则表明在重叠的时间单元上,对呈现信息的显示安排存在冲突。由此,判断单元340会放弃该原始排期数据信息。反之,判断单元340会指示第一存储引擎350和第二存储引擎360分别对原始排期数据信息进行存储管理。下面分别对第一存储引擎350和第二存储引擎360所做操作进行说明。
第一存储引擎350适于将原始排期数据信息中的呈现时间单元集合中连续的呈现时间单元划分为一个时间段。第一存储引擎350可以将每个时间段连同这个时间段对应的呈现位置和呈现信息本身作为一个第一排期数据信息,然后存储到第一数据存储单元310中。其中原始排期数据信息中呈现时间单元集合示例如下:
["2015-04-04","2015-04-05","2015-04-06","2015-04-07","2015-04-08","2015-04-09","2015-04-10","2015-04-11","2015-04-12","2015-04-13","2015-04-14","2015-04-15","2015-04-16","2015-04-17","2015-04-18","2015-04-19","2015-04-20","2015-04-21","2015-04-22","2015-04-23","2015-04-24","2015-04-25","2015-04-26","2015-04-27","2015-04-28","2015-04-29","2015-04-30","2015-06-23","2015-06-24","2015-06-25","2015-06-26","2015-06-27","2015-06-28","2015-06-29","2015-06-30"]
在第一存储引擎350执行存储操作后,第一排期数据信息中时间段的代码示例如下:
开始日期 结束日期 广告id
2015-04-04 2015-04-30 1
2015-06-23 2015-06-30 1
如上所述,第一存储引擎350将呈现时间单元进行了时间段划分,并且将时间段存储为用开始日期和结束日期来表示。每个时间段以及其对应的呈现位置和呈现信息本身被存储为第一存储单元310中一个第一排期数据信息。这样,不同于通常的每个日期对应一个排期数据信息的存储方式,根据本发明的第一存储单元310通过采用对时间段进行存储的方式,能够节省大量的存储空间,并且使得管理排期数据信息和传输也更加高效。
第二存储引擎360可以将原始排期数据信息存储为第二存储单元320中一个第二排期数据信息。其中,呈现时间单元集合被存储为呈现时间单元列表。另外,第二排期数据信息中还包括了呈现时间单元集合的最早日期和最晚日期。在根据本发明一些实施例中,第二存储单元320为MongoDB数据库。第二存储引擎360将原始排期数据信息进行的对象封装操作,从而转化为适于存储到MongoDB中的实体对象,即第二排期数据信息。需要说明的是,MongoDB是以集合文档的方式来存储数据。第二排期数据信息被存储为键-值对的形式。键用于唯一标识一个文档,为字符串类型,而值则可以是各种复杂的文件类型,例如list列表。存储到MongoDB中第二排期数据信息示例如下:
第二排期数据信息代码示例如下:
如上数据示例所示,第二存储引擎360在对原始排期数据信息进行的对象封装操作中,将原始数据中投放时间集合转化为适于在MongoDB中键值对的“值”中存储的时间列表。另外,MongoDB中存储到第二排期数据信息还会被建立磁盘文件和内存的映射关系,以便于快速对该第二数据存储单元320中数据进行高效查询。
在根据本发明一些实施例中,接收单元330还适于接收来自客户端的包含呈现位置和呈现时间的查询参数。例如,查询呈现位置01,日期:2015-01-01,2015-01-03,2015-01-05号,定向北京的排期数据信息。查询引擎370,还适于从第二数据存储单元320中查询并返回满足该查询参数的第二排期数据信息。例如从MongoDB数据库中查询满足查询参数的第二排期数据信息。在MongoDB中查询数据的请求消息格式如下:
{“adPosId”:呈现位置ID 01,“schedulesList“:[‘2015-01-01’,‘2015-01-03’,‘2015-01-05’],”ipCity”:110100}
由于MongoDB内存中有相应文件的数据映射,查询引擎370在查询的时候直接通过内存中索引进行操作。因此,查询引擎370在查询的时候效率高于普通的数据库。
这样,根据本发明的服务器300,能够将排期数据以两种格式分别存储到第一数据存储单元(例如,MySQL数据库)和第二数据存储单元(例如,MongoDB数据库)中。两种数据存储单元中排期数据信息可以互为备份,提高了数据的安全性。进一步,服务器300通过划分时间段的方式将原始排期数据信息存储为第一存储单元中的第一排期数据信息,节省了第一存储单元中的存储空间。另外,排期服务器300能够将原始排期数据信息封装为第二数据存储单元中一个包括呈现时间单元列表的第二排期数据信息。这样,尽管排期数据的数据量很大(例如100万数量级以上),排期服务器300能够高效查询排期数据信息。再者,由于例如MongoDB的第二存储单元320本身支持动态扩展,使得服务器300可以对排期数据的存储进行快速扩展。
图4示出了根据本发明一个实施例的管理排期数据的方法400流程图。该方法400适于在排期服务器中执行。该服务器包括第一数据存储单元和第二数据存储单元。第一数据存储单元中存储一个或者多个第一排期数据信息。第二数据存储单元中存储一个或者多个第二排期数据信息。其中,第一排期数据信息包括待呈现信息的呈现位置和呈现时间段。呈现时间段包括开始时间和结束时间。第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表。根据本发明一些实施例,第一存储单元为关系型数据库,例如MySQL。第二数据存储单元为Nosql数据库,例如MongoDB数据库。
如图4所示,方法400始于步骤410。在步骤S410中,接收来自客户端的一个或者多个待呈现信息的原始排期数据信息。其中,每个待呈现信息的原始排期数据信息包括待呈现信息的呈现位置和呈现时间单元集合。呈现位置的参数包括呈现位置名称、呈现设备属性、呈现信息的路径、呈现信息的定向属性、呈现信息在网页中的位置和呈现信息轮播标识中至少一个。呈现时间单元集合为所选定的用于呈现信息的日期的集合。
随后,方法进入步骤S420,判断该原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠。根据本发明一些实施例,在步骤S420中,将原始排期数据信息中呈现位置作为索引值,从第二数据存储单元中查询该呈现位置已占用的时间单元集合,即查询满足索引值的第二排期数据信息。随后,判断该原始排期数据信息中呈现时间单元集合是否与所查询到的已占用的时间单元的集合存在重叠。如果存在重叠,则放弃该原始排期数据信息。换言之,客户端需要重新生成针对本次排期的原始排期数据信息。如果不存在重叠,则方法400执行步骤S430和步骤S440。
在步骤S430中,将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段。随后,将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中。
在步骤S440中,将原始排期数据信息的呈现时间单元集合连同这个集合对应的呈现位置和待呈现信息作为一个第二排期数据信息、存储到第二数据存储单元中。该第二排期数据信息中的呈现时间单元集合被存储为呈现时间单元列表。
如上所述,通过步骤S430和S440所执行操作,原始排期数据信息分别以不同存储结构存储到了第一、第二数据存储单元中。这两个数据存储单元实现了数据的互为备份,提高了数据安全性。另外,步骤S430中对呈现时间单元进行按照时间段划分,并且每个时间段存储为一个排期数据记录。这样,步骤S430实现了对大量排期数据的优化存储,极大节省了第一数据存储单元的存储空间。
根据本发明一些实施例,方法400还包括步骤S450。在步骤S450中,对第二数据存储单元中所有第二排期数据信息建立一个或多个索引。其中,每个索引对应呈现位置的参数中一个或者投放时间集合中一个日期。例如,第二数据存储单元为MongoDB数据库。MongoDB数据库中存储到第二排期数据信息被建立磁盘文件和内存的映射关系。换言之,第二排期数据信息被建立内存中存放的索引,从而可以对第二数据存储单元中数据进行高效查询。可选地,方法400还包括步骤S460。在步骤S460中,响应于接收到客户端包含呈现位置和呈现时间的查询参数,从第二数据存储单元中查询并返回满足该查询参数的第二排期数据信息。
A10、如A9所述的服务器,其中判断单元适于根据下述方式判断所述原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠:将该原始排期数据信息中呈现位置作为索引值,指示查询引擎从所述第二数据存储单元查询该呈现位置已占用的时间单元的集合;判断该原始排期数据信息中呈现时间单元集合与所述查询到的已占用的时间单元的集合是否存在重叠;如果存在重叠,则放弃该原始排期数据信息。A11、如A9所述的服务器,其中,接收单元,还适于接收来自客户端的包含呈现位置和呈现时间的查询参数;以及查询引擎,还适于从所述第二数据存储单元中查询并返回满足该查询参数的第二排期数据信息。A12、如A7-A11中任一项所述的服务器,其中,所述第一数据存储单元为MySQL数据库;所述第二数据存储单元为MongoDB数据库。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中,或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
此外,所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此,具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外,装置实施例的在此所述的元素是如下装置的例子:该装置用于实施由为了实施该发明的目的的元素所执行的功能。
如在此所使用的那样,除非另行规定,使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例,并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。
尽管根据有限数量的实施例描述了本发明,但是受益于上面的描述,本技术领域内的技术人员明白,在由此描述的本发明的范围内,可以设想其它实施例。此外,应当注意,本说明书中使用的语言主要是为了可读性和教导的目的而选择的,而不是为了解释或者限定本发明的主题而选择的。因此,在不偏离所附权利要求书的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围,对本发明所做的公开是说明性的,而非限制性的,本发明的范围由所附权利要求书限定。
Claims (13)
1.一种管理排期数据的方法,适于在服务器中执行,该服务器包括第一数据存储单元和第二数据存储单元,第一数据存储单元为关系型数据库,第二数据存储单元为nosql数据库,第一数据存储单元中存储一个或者多个第一排期数据信息,第二数据存储单元中存储一个或者多个第二排期数据信息,其中第一排期数据信息包括待呈现信息的呈现位置和呈现时间段,所述呈现时间段包括开始时间和结束时间,第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表,该方法包括:
接收来自客户端的一个或者多个待呈现信息的原始排期数据信息,其中每个待呈现信息的原始排期数据信息包括该待呈现信息的呈现位置和呈现时间单元集合;
判断该原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠,如果未发生重叠,则:
将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段,并将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中;以及将所述原始排期数据信息的呈现时间单元集合连同这个集合对应的呈现位置和待呈现信息作为一个第二排期数据信息、存储到第二数据存储单元中,该第二排期数据信息中的呈现时间单元集合被存储为呈现时间单元列表。
2.如权利要求1所述的方法,其中,
所述呈现位置的参数包括呈现位置名称、呈现设备属性、呈现信息的路径、呈现信息的定向属性、呈现信息在网页中的位置和呈现信息轮播标识中至少一个;以及
所述呈现时间单元集合为所选定的用于呈现信息的日期的集合。
3.如权利要求2所述的方法,还包括:
对所述第二数据存储单元中所有第二排期数据信息建立一个或多个索引,其中每个索引对应所述呈现位置的参数中一个或者所述呈现时间单元集合中一个日期。
4.如权利要求3所述的方法,其中,判断所述原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠的步骤包括:
将该原始排期数据信息中呈现位置作为索引值,从所述第二数据存储单元查询该呈现位置已占用的时间单元的集合;以及
判断该原始排期数据信息中呈现时间单元集合与查询到的已占用的时间单元的集合是否存在重叠,
如果存在重叠,则放弃该原始排期数据信息。
5.如权利要求3所述的方法,还包括:
响应于接收到客户端包含呈现位置和呈现时间的查询参数,从所述第二数据存储单元中查询并返回满足该查询参数的第二排期数据信息。
6.如权利要求1-5中任一项所述的方法,其中,
所述第一数据存储单元为MySQL数据库;以及
所述第二数据存储单元为MongoDB数据库。
7.一种管理排期数据的服务器,包括:
第一数据存储单元,所述第一数据存储单元为关系型数据库,适于存储一个或者多个第一排期数据信息,其中第一排期数据信息包括待呈现信息的呈现位置和呈现时间段,所述呈现时间段包括开始时间和结束时间;
第二数据存储单元,所述第二数据存储单元为nosql数据库,适于存储一个或者多个第二排期数据信息,第二排期数据信息包括待呈现信息的呈现位置和呈现时间单元列表;
接收单元,适于接收来自客户端的一个或者多个待呈现信息的原始排期数据信息,其中每个待呈现信息的原始排期数据信息包括该待呈现信息的呈现位置和呈现时间单元集合;
判断单元,适于判断该原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠;
第一存储引擎,在判断单元确定未发生重叠时,适于将原始排期数据信息的呈现时间单元集合中连续的呈现时间单元划分为一个时间段,并将每个划分的时间段连同这个时间段对应的呈现位置和待呈现信息本身作为一个第一排期数据信息、存储到第一数据存储单元中,以及
第二存储引擎,在判断单元确定未发生重叠时,适于将所述原始排期数据信息的呈现时间单元集合连同这个集合对应的呈现位置和待呈现信息作为一个第二排期数据信息、存储到第二数据存储单元中,该第二排期数据信息中的呈现时间单元集合被存储为呈现时间单元列表。
8.如权利要求7所述的服务器,其中,
所述呈现位置的参数包括呈现位置名称、呈现设备属性、呈现信息的路径、呈现信息的定向属性、呈现信息在网页中的位置和呈现信息轮播标识中至少一个;
所述呈现时间单元集合为所选定的用于呈现信息的日期的集合。
9.如权利要求8所述的服务器,还包括查询引擎,适于:对所述第二数据存储单元中所有第二排期数据信息建立一个或多个索引,其中每个索引对应所述呈现位置的参数中一个或者所述呈现时间单元集合的一个日期。
10.如权利要求9所述的服务器,其中判断单元适于根据下述方式判断所述原始排期数据信息是否与第二数据存储单元中存储的第二排期数据信息发生重叠:
将该原始排期数据信息中呈现位置作为索引值,指示查询引擎从所述第二数据存储单元查询该呈现位置已占用的时间单元的集合;
判断该原始排期数据信息中呈现时间单元集合与所述查询到的已占用的时间单元的集合是否存在重叠;
如果存在重叠,则放弃该原始排期数据信息。
11.如权利要求9所述的服务器,其中,
接收单元,还适于接收来自客户端的包含呈现位置和呈现时间的查询参数;以及
查询引擎,还适于从所述第二数据存储单元中查询并返回满足该查询参数的第二排期数据信息。
12.如权利要求7-11中任一项所述的服务器,其中,
所述第一数据存储单元为MySQL数据库;
所述第二数据存储单元为MongoDB数据库。
13.一种管理排期数据的系统,包括:
客户端,适于生成一个或者多个呈现信息的原始排期数据信息;以及
如权利要求7-12中任一项所述的管理排期数据的服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510641007.6A CN105184550B (zh) | 2015-09-30 | 2015-09-30 | 管理排期数据的方法、服务器及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510641007.6A CN105184550B (zh) | 2015-09-30 | 2015-09-30 | 管理排期数据的方法、服务器及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105184550A CN105184550A (zh) | 2015-12-23 |
CN105184550B true CN105184550B (zh) | 2018-09-14 |
Family
ID=54906612
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510641007.6A Active CN105184550B (zh) | 2015-09-30 | 2015-09-30 | 管理排期数据的方法、服务器及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105184550B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105701648A (zh) * | 2016-02-22 | 2016-06-22 | 太仓苏易信息科技有限公司 | 一种排班管理系统 |
CN110148015A (zh) * | 2019-04-25 | 2019-08-20 | 政采云有限公司 | 网络广告投放的排期方法和装置 |
CN112788386B (zh) * | 2019-11-06 | 2023-12-05 | 西安诺瓦星云科技股份有限公司 | 节目排期生成方法及其装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102006522A (zh) * | 2010-11-04 | 2011-04-06 | 深圳市同洲电子股份有限公司 | 广告排期方法及系统 |
CN102663581A (zh) * | 2012-03-05 | 2012-09-12 | 北京千橡网景科技发展有限公司 | 用于存储事件排期的方法和装置 |
CN103514561A (zh) * | 2013-10-21 | 2014-01-15 | 东莞市东信网络技术有限公司 | 广告排期管理方法及其系统 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9094714B2 (en) * | 2009-05-29 | 2015-07-28 | Cognitive Networks, Inc. | Systems and methods for on-screen graphics detection |
US8983274B2 (en) * | 2011-05-20 | 2015-03-17 | Echostar Technologies L.L.C. | Systems and methods for revolving recording conflicts |
-
2015
- 2015-09-30 CN CN201510641007.6A patent/CN105184550B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102006522A (zh) * | 2010-11-04 | 2011-04-06 | 深圳市同洲电子股份有限公司 | 广告排期方法及系统 |
CN102663581A (zh) * | 2012-03-05 | 2012-09-12 | 北京千橡网景科技发展有限公司 | 用于存储事件排期的方法和装置 |
CN103514561A (zh) * | 2013-10-21 | 2014-01-15 | 东莞市东信网络技术有限公司 | 广告排期管理方法及其系统 |
Non-Patent Citations (1)
Title |
---|
移动广告系统中广告排期的设计与实现;刘晨等;《计算机系统应用》;20111231;第20卷(第3期);全文 * |
Also Published As
Publication number | Publication date |
---|---|
CN105184550A (zh) | 2015-12-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11163957B2 (en) | Performing semantic graph search | |
US11741057B2 (en) | Unified data object management system and the method | |
CN105183735B (zh) | 数据的查询方法及查询装置 | |
US9146994B2 (en) | Pivot facets for text mining and search | |
US9251130B1 (en) | Tagging annotations of electronic books | |
AU2015204742B2 (en) | Methods for generating an activity stream | |
CN106326429A (zh) | 一种基于solr的Hbase秒级查询方案 | |
Alarabi et al. | TAREEG: a MapReduce-based web service for extracting spatial data from OpenStreetMap | |
CN103942205A (zh) | 存储、读取目录索引的方法、装置及系统 | |
US20170286549A1 (en) | Displaying results, in an analytics visualization dashboard, of federated searches across repositories using as inputs attributes of the analytics visualization dashboard | |
CN105210061A (zh) | 加标签的搜索结果维护 | |
CN105426449A (zh) | 海量数据查询方法和装置、服务器 | |
CN105184550B (zh) | 管理排期数据的方法、服务器及系统 | |
CN106776717A (zh) | 一种基于HBase的接口构造方法及系统 | |
US20130346405A1 (en) | Systems and methods for managing data items using structured tags | |
US10606842B2 (en) | Cross-model filtering | |
CN104808995B (zh) | 一种用于跨应用收藏应用内容的方法和装置 | |
CN107239568B (zh) | 分布式索引实现方法及装置 | |
CN109947702A (zh) | 索引构建方法及装置、电子设备 | |
US9542457B1 (en) | Methods for displaying object history information | |
CN111008198A (zh) | 业务数据获取方法、装置、存储介质、电子设备 | |
US9230011B1 (en) | Index-based querying of archived data sets | |
Bugaje et al. | Data retrieval= text retrieval? | |
US10423629B2 (en) | Intelligent tabular big data presentation in search environment based on prior human input configuration | |
US20210157804A1 (en) | Reporting and knowledge discovery for databases |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |