CN102426589B - 一种用于数据库信息检索的中间层系统及信息检索方法 - Google Patents
一种用于数据库信息检索的中间层系统及信息检索方法 Download PDFInfo
- Publication number
- CN102426589B CN102426589B CN201110336342.7A CN201110336342A CN102426589B CN 102426589 B CN102426589 B CN 102426589B CN 201110336342 A CN201110336342 A CN 201110336342A CN 102426589 B CN102426589 B CN 102426589B
- Authority
- CN
- China
- Prior art keywords
- server
- index
- database
- data
- file
- 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
- 238000000034 method Methods 0.000 title claims abstract description 45
- 239000011229 interlayer Substances 0.000 title abstract 5
- 230000001360 synchronised effect Effects 0.000 claims abstract description 5
- 241000252794 Sphinx Species 0.000 claims description 18
- 230000008569 process Effects 0.000 claims description 12
- 238000005192 partition Methods 0.000 claims description 3
- 238000011161 development Methods 0.000 abstract description 5
- 239000010410 layer Substances 0.000 abstract 5
- 238000012216 screening Methods 0.000 description 15
- 230000014509 gene expression Effects 0.000 description 12
- 238000013549 information retrieval technique Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 238000004422 calculation algorithm Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 210000001072 colon Anatomy 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 235000013399 edible fruits Nutrition 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种用于数据库信息检索的中间层系统及信息检索方法，包括：用于接收应用层发出的检索请求的API应用服务器群组，API应用服务器群组从索引服务器群获取所检索视频的ID，通过视频的ID从在线数据库获取视频，离线数据库将在线数据库的信息同步后，供索引创建服务器创建索引并存储到索引服务器群中。本发明所述的用于数据库信息检索的中间层系统及信息检索方法，中间层系统能接收基于http协议的检索请求，经过语法分析引擎解析后，能精确获取数据，满足大数据量且任意字段组合的查寻，数据库查寻时间短，数据层与应用层分离，数据层和应用层的开发互不影响。
Description
技术领域
本发明涉及在线数据库检索或在线搜索引擎技术领域，具体说是一种用于数据库信息检索的中间层系统及信息检索方法。所述数据库尤指视频网站用于存储在线视频信息的数据库。
背景技术
现有的视频网站都会为用户提供视频信息检索服务，视频网站将视频信息分类后存储在数据库中，视频网站会使用很多的数据库及数据表来存储数据，一个数据库包括若干个数据表，具体的视频信息都存储在数据表中。传统的视频信息检索方式是：应用层需要跟据业务需求，到不同的数据库和不同的数据表去取数据，这些数据表的查寻一般无法达到使用任何查寻都有很高的效率，并且，这些数据表可能是分散存储在不同的数据库中的，应用层使用起来非常不方便。
现有的视频信息检索服务采用的是目录式分类法，目录式分类法只能按照一个特定的维度进行分类，比如树形分类，再比如我们的文件目录结构等。但生活中往往一个对象，可以有多种属性，比如图书，可以有作者、年代、出版商、类形等。而用户可能从各种不同的维度出发，查找感兴趣的内容。
现有的视频信息检索服务并不一定使用的是目录式分类法，目录式分类法只是常用分类法的一种，目前传统开发方式也有很多采用多面筛选法或叫面分类法，这种方法并非本系统独创，面分类法是由冒号分类法演变而来，冒号分类法的发明人应该是印度人S.R.Ranganathan。但传统实现方式基本上是跟据业务需求来定制数据库，当业务逻辑发生变化时数据库结构，实现代码等一系列内容都要跟着修改，基本上没有灵活性可言。本系统的一个方面就是要解决业务逻辑灵活性问题，业务层无论发生何种变化，都不会对数据结构和代码构成同步大量修改。
以图书为例：使用目录式分类法进行检索，就像我们在图书馆找一本关于计算机编程的书，我们先要知道，找的书是属于什么类的，如文史类、经济类还是计算机类图书，因为是编程类的，所以找到计算机类图书的专区后，再找编程类，然后可能更具体的，再找PHP编程，还是JAVA编程等等，一级级找下去。
还是以图书为例，假设我现在只知道该书的作者，那么我可能直接使用作者来进行查找，一下能列出该作者所著的所有著作，这就好像在图书馆里，提供了一某作者的专区。比如小说《达芬奇密码》，作者丹布朗，在小说类的书架上有该书，而图书馆为了促销，专门设置的丹布朗专区，在这里我可以找到所有丹布朗的著作。但在现实生活中，由于作者有千千万，不可能为每个作者都设立专区，而且还会有年代，出版社等内容，同时还会有组合情况发生，如清华出版社1990-2000年发行的所有图书。现实生活中，这种分类方式几乎是不可能实现的。
使用传统的数据库查寻技术，在数据量较小的时候，比如一张表几百条记录，也是可实现不同维度(数据库里一般一个维度就是一个字段)的快速查找，但仅局限在一张表内的查找，如果一个资源是由很多表组成，则需要查寻多次，比如视频信息，视频的标题，简介，创建时间等放在一张表，而播放数，评论数等放在另一张表，那就要查寻两次。而一个资源，如我们的视频信息，需要几十张表存储不同的内容。这种查寻不但复杂，而且数据量只有在很小的时候才能有很高的查寻效率，显然，传统数据库查寻无法满足大数据量且任意字段组合的查寻。
本发明中所说的维度，是指思维的维度，比如一个视频，可以从分类的维度去找(如：电影、电视剧、综艺)，也可以从发行的年代的维度去找。属性则可以理解为每个属性是一个思维的维度的技术表现形式。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种用于数据库信息检索的中间层系统及信息检索方法，中间层系统能接收基于http协议的检索请求，经过语法分析引擎解析后，能精确获取数据，满足大数据量且任意字段组合的查寻，数据库查寻时间短，数据层与应用层分离，数据层和应用层的开发互不影响。
为达到以上目的，本发明采取的技术方案是：
一种用于数据库信息检索的中间层系统，其特征在于，包括：
用于接收应用层发出的检索请求的API应用服务器群组，所述应用层发出的检索请求为一个符合URL规范的http地址，该http地址中包括用于在数据库中进行检索的相应的参数，
用于接收API应用服务器群组转发的检索请求的索引服务器群Sphinx Server，所述索引服务器群包括若干节点服务器Node IndexerServer，
用于接收API应用服务器群组转发的检索请求的在线数据库服务器群，所述在线数据库服务器群包括若干在线数据库群组，
离线数据库服务器群，通过数据交互通道与在线数据库服务器群进行数据同步，所述离线数据库服务器群包括若干离线数据库群组，
索引创建服务器，索引创建服务器跟据索引配置文件中指定的离线数据库群组得到数据来创建索引，索引创建服务器创建索引的过程，就是生成索引文件的过程，索引文件存储在索引创建服务器中，
索引服务器群中的各节点服务器从索引创建服务器中获取最新的索引文件。
在上述技术方案的基础上，所述API应用服务器群组包括若干APP服务器APP Server，每个APP Server中均设有服务软件，所述服务软件包括：用来接收http请求的服务软件nginx，用来管理php运行进程的服务软件php fpm，用来解析php脚本的服务软件php，服务软件用于完成接收请求和语法分析，此即语法分析引擎。
在上述技术方案的基础上，索引文件会放在索引创建服务器上的FTP服务目录下，通过服务器上的定时任务执行程序定时生成一个新的索引文件，并以文本方式记录本次生成的索引文件的版本号，新的版本号是上一次生成的版本号加一；
索引创建服务器同时安装了FTP服务，节点服务器通过FTP客户端命令，访问到FTP服务目录下的各个索引文件。
在上述技术方案的基础上，节点服务器每次从索引创建服务器下载索引文件，也会在本地记录当前节点服务器中所使用的索引文件的版本号，
节点服务器定时将本地当前节点服务器中所使用的索引文件的版本号与索引创建服务器上最新的索引文件的版本号对比，当小于时，则重新下载索引创建服务器上最新的索引文件。
一种基于上述的用于数据库信息检索的中间层系统的信息检索方法，其特征在于，包括以下步骤：
步骤1，MySQL在线数据库和离线数据库的内容是一一对应的，有一个在线视频库，就会有一个离线视频库，通过MySQL的主从同步复制功能，将在线数据库实时同步复制到离线数据库当中；
步骤2，MySQL离线数据库是专门供索引创建服务器使用的，索引创建服务器上安装sphinx的indexer程序，indexer程序会跟据对应的配置文件，生成索引，
所述配置文件包括数据来源参数，数据来源参数指向MySQL离线数据库，
sphinx的indexer程序定时生成索引文件；
步骤3，API应用服务器装有nginx、php-fpm和php，nginx用于接收到http请求，php-fpm负责调用php脚本，而php本身是用来解析语法分析引擎的程序；当服务器接收到http请求时，对http请求中的参数进行分析通过对q参数和ob参数进行分析，确定需要查寻哪些条件，将分析结果转换成sphinx可以识别的查寻条件，向索引服务器发送查寻请求，索引服务器跟据查寻条件，在索引中进行查寻，索引服务器将查寻后的文档ID返回给API应用服务器；
步骤4，API应用服务器得到文档ID后，通过分析http请求中的fd参数，确定需要返回哪些字段，然后利用刚刚得到的文档ID去MySQL数据库进行查寻需要返回的数据，所述文档id在mysql里为主键。
在上述技术方案的基础上，在MySQL在线数据库和离线数据库中，跟据业务需求按群组划分数据库。
本发明所述的用于数据库信息检索的中间层系统及信息检索方法，当用户通过应用层来检索(查询)数据表中的视频信息时，给出一个http地址作为请求发送到中间层，由中间层完成在数据库中检索视频信息，并将检索结果返回给应用层的工作。
本发明所述的用于数据库信息检索的中间层系统及信息检索方法，具有以下优点：
1.基于http协议
传统的数据库直接调用数据方式，与业务逻辑关系非常紧密，往往需要跟据业务需求，使用不同的数据库类型，并需要跟据业务层面需求来设计数据库结构和数据索引，当业务量不断扩展，其数据库也会随之变得复杂。简单的说，业务逻辑、数据存储、数据查寻索引三个方面是绑在一起的，任何一个有变化都会影响到其它两方面。本发明给出的用于数据库信息检索的中间层系统及信息检索方法，通过http方式调用数据，可以彻底将数据库层面和业务层面隔离开，而通过sphinx(一个基于SQL的全文检索引擎，可以结合MySQL、PostgreSQL做全文搜索，它可以提供比数据库本身更专业的搜索功能)索引服务，又将数据存储和索引分开，使业务逻辑、数据存储、数据查寻索引相对独立，互不影响。未来数据库不管是用mysql存储还是mongodb存储，都不会响业务层应用。
2.精确获取数据(相对于搜索引擎)
传统的搜索引擎，一般是通过关键字分词方式，在文本内容中进行全文查找，这种查寻返回的结果，主要依赖分词算法，但分词算法无论如何优化，都有可能搜索出来的结果并不是用户相要的。本发明给出的用于数据库信息检索的中间层系统及信息检索方法，可针对字段进行精确定向查寻，返回给果一定是前端所需结果，而非模糊搜索的结果。比如查找当天播放数大于1一万的视频，直接使用表达式day_vv:10000-，这有点像传统数据库的条件查寻语句whereday_vv＞10000，但传统数据库必须在day_vv字段上加索引才能快速查寻。
3.数据层与应用层分离(单独开发互不影响)
上面已经提到，本发明给出的用于数据库信息检索的中间层系统及信息检索方法，由于使用http协议进行数据传送，增加字段或修改数据库结构等操作，对应用端来说都是透明的，应用层读取数据的方式永远都是通过http协议向接口请求数据，所以数据库层面的修改不会影响到应用层，这也使得数据层和应用层的开发互不影响。
4.统一的数据读取方法(协议)
传统的方法是应用层的程序要直接到数据库读取数据，这就需要知道数据库如何配置的，数据结构是怎样的等一些关于数据库的具体问题，而且，不同的数据库都不一样，应用层使用起来非常繁琐。本发明给出的用于数据库信息检索的中间层系统及信息检索方法，使用中间层接口读取数据，都是通过一个http地址请求获取数据，而且所使用的查寻表达式规范相同，这样不管是读取节目数据还是视频数据，查寻方法完全一样，所不同就是告诉接口要节目数据还是视频数据，有哪些字段等。对于前端应用来说，只要学会查寻表达式，就可轻易读取任何想要的数据，而不用关心数据库存储和索引等内容。开发效率和开发成本大大降低。
5.极好的性能
传统的数据库存储，数据读取往往由业务逻辑决定，时刻都要关心是业务逻辑需要的查寻，数据库是否能满足查寻需求，执行效率如何等一系列问题。本发明给出的用于数据库信息检索的中间层系统及信息检索方法，中间层由于使用独立的索引系统，将所有字段都进行了索引，所以通过中间层获取数据，字段查寻可以任意组合同时可以保证高效查寻。业务逻辑永远不用关心查寻效率问题，也不用关心字段查寻的先后顺序。举例来说，传统数据库有一张数据表A，表A中有三个字段F1、F2、F3，数据库在F1上有索引，假如该表有一千万数据，使用传统的查寻方式，查寻条件中只能对F1进行查寻，才能命中索引，查寻时间可以在0.1秒以内，如果对F2或F3或它们之间任意组合的查寻，由于无法命中索引，就需要全表扫描，其查寻时间从几分钟到几十分钟都是有可能的，这显然不能满足线上应用需求。而中间层由于使用了独立的索引服务，这一千万数据都是通过离线方式将F1、F2、F3全部创建了索引，而且索引都放在内存当中，这样业务层无论是查寻任何一个字段或组合，都可以命中索引，查寻时间都可控制在0.1秒以内。
附图说明
本发明有如下附图：
图1中间层服务器架构示意图，
图2中间层所处位置示意图，
图3中间层与各模块之间的关系示意图，
图4语法分析引擎工作流程图。
具体实施方式
以下结合附图对本发明作进一步详细说明。
本发明所述的用于数据库信息检索的中间层系统及信息检索方法，主要用于视频网站为用户提供海量视频信息检索服务，或具有类似检索需求的场合，当用户通过应用层来检索(查询)数据表中的视频信息时，给出一个http地址作为请求发送到中间层，由中间层解析该http地址获得请求检索的相关信息后，完成在数据库中对视频信息的检索，并将检索结果返回给应用层的工作。
本发明不局限于视频信息检索服务，本发明给出的中间层系统的结构可以应用于几乎网站的所有内容，如看吧(优库社区产品)，明星(明星库产品)等。本发明在目前优酷网站中，主要用于数据筛选、读取，不等同于传统的基于分词的搜索引擎，或理解为一种精确检索的搜索引擎。
在作为请求的http地址中包括相应的参数供中间层在数据库中进行检索。应用层、中间层、数据库(底层)三者的结构关系参见图2。所述的中间层包括访问协议，该访问协议是一种基于http的协议，是一个读取数据的规范。
中间层所完成的工作可划分为：
对底层(数据库)，通过中间层创建数据表的索引，使其查寻效率非常高，应用层不用关心条件如何组合才能命中数据表索引，各种查寻条件完全可以自由结合，而中间层负责将这些分散在各数据表中的数据读取出来并进行封装，应用层只要告诉中间层要什么数据，中间层为其完成到各个数据库和数据表的查寻工作。
对应用层，提供一种简单、高效、统一的读取接口，应用层只需要按照中间层中的访问协议将参数拼装起来构成符合规范(URL规范)的http地址，即可获取到指定的数据。
如图1所示，本发明给出的用于数据库信息检索的中间层系统，包括；
用于接收应用层发出的检索请求的API应用服务器群组，所述应用层发出的检索请求为一个符合URL规范的http地址，该http地址中包括用于在数据库中进行检索的相应的参数，本发明中涉及的各参数详见后述，
所述API应用服务器群组包括若干APP Server(APP服务器)，每个APP Server中均设有服务软件，所述服务软件包括：用来接收http请求的服务软件nginx，用来管理php运行进程的服务软件phpfpm，用来解析php脚本的服务软件php，服务软件用于完成接收请求和语法分析，此即语法分析引擎，语法分析引擎工作流程图参见图4，语法分析引擎可以理解为将http请求中的参数数据，解析成为sphinx服务api提供的查寻代码和反回对应于数据库字段信息的一个分析器，
用于接收API应用服务器群组转发的检索请求的索引服务器群Sphinx Server，
所述索引服务器群包括若干索引服务器(节点服务器)NodeIndexer Server，
用于接收API应用服务器群组转发的检索请求的在线数据库服务器群，
所述在线数据库服务器群包括若干在线数据库群组，在线数据库群组可以使用MySQL数据库，
API应用服务器群组从索引服务器群Sphinx Server获取所请求检索对象的对象身份标识号码ID(例如：请求检索对象为视频，则获取到的则为视频ID)，再通过检索对象(视频)的ID从在线数据库服务器群获取最终的检索结果，对象的ID用于唯一标识请求检索的对象，和上面提到的一样不局限于视频ID，视频只是一个具体资源的示例，
离线数据库服务器群，通过数据交互通道与在线数据库服务器群进行数据同步，
所述离线数据库服务器群包括若干离线数据库群组，离线数据库群组与在线数据库群组使用相同的数据库，例如可以使用MySQL数据库，使用相同的数据库是为了便于进行数据同步，
索引创建服务器，索引创建服务器跟据索引配置文件中指定的离线数据库群组得到数据来创建索引，索引创建服务器创建索引的过程，就是生成索引文件的过程，索引文件存储在索引创建服务器中，
索引服务器群中的各节点服务器从索引创建服务器中获取最新的索引文件。例如：
索引文件会放在索引创建服务器上一个特定的目录(FTP服务目录)下，通过服务器(索引创建服务器)上的定时任务执行程序(例如：unix系统中的定时任务执行程序crontab)定时生成一个新的索引文件，并以文本方式记录本次生成的索引文件的版本号，版本号为正值(例如：1、2、100等正值)，新的版本号是上一次生成的版本号加一。最终的目录文件类似于下面这样(以节目索引为例)
29504(以版本号命名的目录，其中存储与该版本号对应的索引文件，下同)
29505(目录)
29506(目录)
29507(目录)
29508(目录)
29509(目录)
version.show.master(记录最后版本号的文本文件，如29509是最后一个索引文件的版本号，则该文本文件中记录的内容可以为：VER_LAST＝29509)
索引创建服务器同时安装了FTP服务，节点服务器通过FTP客户端命令，访问到FTP服务目录下的各个索引文件。
节点服务器每次从索引创建服务器下载索引文件，也会在本地记录当前节点服务器中所使用的索引文件的版本号，例如：在节点服务器中索引文件的目录中会有一个名为version.show.loc的文本文件，内容类似于VER_LAST_LOCAL＝29508，记录当前节点服务器中所使用的索引文件的版本号。节点服务器同样可通过定时任务执行程序crontab程序，定时执行(如每3分钟执行一次)shell脚本(shellscript，利用shell的功能所写的一个程序，这个程序是使用纯文本本件，将一些shell的语法与指令写在里面，然后用正规表示法，管线命令以及数据流重导向等功能，以达到我们所想要的处理目的)，所述shell脚本主要完成的工作是比较本地的索引文件的版本号是否小于索引创建服务器上最后的索引文件的版本号，如果小于，则从索引创建服务器上下载最后一个版本的索引文件覆盖本地的索引文件，实现索引文件的更新。以前述为例：本地的索引文件的版本号是29508，而索引创建服务器上最后的索引文件的版本号是29509，则需要更新。如果本地索引文件的版本号等于索引创建服务器上的最后的索引文件的版本号，则说明索引文件没有更新，则直接结束shell脚本不做任何操作。
上述中间层系统中各服务器的架构可按如下设置，所述架构是指环境及所用开发语言：
操作系统OS：CentOS 5.5(一个linux操作系统)
APP服务器APP Server：Nginx(用来接收http请求的服务软件)+php fpm(用来管理php运行进程的服务软件)+php(用来解析php脚本的程序)
索引创建服务器Index Server：sphinx(一个基于SQL的全文检索引擎)
分布脚本Distribute script：linux bash shell script(linux系统下的脚本语言)+php script(php脚本语言)
数据库database：MySQL(一种数据库)
使用中间层架构的要求：
进入中间层的资源，必须有一个唯一的对象身份标识号码ID(数字识别ID)，所有字段或属性都是基于该ID之上，这是一种文档式数据结构。以视频为例，首先必须有一个视频ID，其它一切视频信息都可以作为属性存在，以视频为例，其结构类似如下，
ID
title(标题)
seconds(视频长度)
createtime(创建时间)
guest(嘉宾)
id(嘉宾ID，可关链到人物资源)
name(嘉宾名)
…
可以看出，对于视频资源的每个记录，都可以认为是一个文档“ID”，而文档“ID”下，记录着该视频资源的所有信息，例如：标题、视频长度、创建时间、嘉宾、嘉宾ID、嘉宾名等等。
以上述用于数据库信息检索的中间层系统为基础，本发明所述的用于数据库信息检索的中间层系统的信息检索方法，服务器间的工作流程包括以下步骤：
1.API应用服务器装有nginx、php-fpm和php，nginx用于接收到http请求，php-fpm负责调用php脚本，而php本身是用来解析语法分析引擎的程序。当服务器接收到http请求时，对http请求中的参数进行分析(分析过程后面有述)，通过对q参数(查询条件指定参数)和ob参数(排序参数)进行分析，确定所请求的对象需要查寻哪些条件，将分析结果转换成sphinx可以识别的查寻条件，向索引服务器Node Indexer Server发送查寻请求，索引服务器跟据查寻条件，在索引中进行查寻，索引服务器将查寻后的对象ID(例如前述的文档ID)返回给API应用服务器。
2.API应用服务器得到对象ID(文档ID)后，通过分析http请求中的fd参数(返回接口参数)，确定需要返回哪些字段，然后利用刚刚得到的对象ID(文档ID)去MySQL数据库(在线数据库)进行查寻需要返回的数据(字段)。由于查寻mysql数据库时，永远都是使用对象ID(文档ID)查寻，而对象ID(文档ID)在mysql里都是主键，所以查寻效率极高。
3.MySQL在线数据库和离线数据库的内容是一一对应的，有一个在线数据库，就会有一个离线数据库，通过MySQL的主从同步复制功能，将在线数据库实时同步复制到离线数据库当中。要说明的是，在线数据库中包函写库，但本专利中不涉及此项内容，所以在线数据库和离线数据库可以简单镜像数据库，一模一样，只是使用他们的(人或其他服务器)不同。
4.正如上面所说，MySQL离线数据库是专门供索引创建服务器使用的，索引创建服务器上安装sphinx的indexer程序(创建sphinx索引的程序)，indexer程序会跟据对应的配置文件，生成索引，而配置文件中，最重要的数据来源，就是指向的MySQL离线数据库。创建索引由crontab程序定时完成，如每小时生成一次索引。该服务器同时还安装了ftp服务，生成的索引以文件方式存放在ftp目录下以便Node Indexer Server可以将文件复制到本地。
5.Node Indexer Server上安装和sphinx的searhd服务(用于提供sphinx查寻的服务)，通过crontab程序，定时执行查寻索引创建服务器上生成的索引文件并与本机索引文件进行比较的shell脚本程序，如果索引创建服务器上的索引文件比较新，则通过ftp方式将其下载到本机，完成下载后通知searhd程序使用新的索引文件。
在MySQL在线数据库和离线数据库中，跟据业务需求按群组划分数据库，如图1所示，按节目、视频、人物划分三个数据库群组，离线数据库和在线数据库是同步对应的关系，如，有一个在线视频库，就要有一个离线视频库，在线数据库是为线上实时提供实时数据的，而离线数据库是为了创建索引使用，由于创建索引时，数据库服务器负载非常高，为了不影响线上实时提供数据，所以才进行在线离线分离的。该结构理论可以支持所有的数据信息，任何信息都可以使用该结构以达到快速检索目的。
以视频目录服务为例：
1.视频目录服务确定需要呈现的数据，通过查寻表达式向中间层接口请求查寻；
2.接口接收到查寻请求后，将查寻表达式提交给语法分析器进行分析，解析成索引服务可接收的查寻命令，并提交给索引服务器。
3.索引服务器跟据查寻命令到索引中查寻符合条件的数据，并将找到的ID返回。
4.话语法分析器得到索引服务返回的ID到，直接到数据库中取出对应的数据，并按查寻表达式指定的返回字段和格式返回。
以下为应用层读取数据协议与示例(是指用于在数据库中进行检索的相应的参数，以及如何将这些参数拼装获取数据的符合URL规范的http地址，)：
1、查询表达式定义
基本形式：q＝field1：value1 field2：value2…
q为查询条件指定参数，filed指的是数据表中的字段，value指字段的值。后面的跟的数字代表不同的字段和字段的值。
每个字段和字段的值之间用“：”号分隔，构成了一个了最小查寻条件，多个最小查寻条件可进行组合，形成组合查寻条件，多个最小查寻条件中间用空格分隔。条件之间是和(AND)的关系。
其中，字段filed不指定时可以全文范围(指所有的文本类型的字段)内查寻。
举例：
q＝showcategory：电影 releaseyear：2010
q＝performer：孙红雷
q＝越狱
q＝showname：越狱
作为最简单的查询：
q＝越狱(field1：value1只是基本形式，如果不指定会在所有的文本类型的字段中进行搜索)
表示在节目库中全文检索“越狱”，“越狱”称之为关键字(keyword)。
所有取数据的需求无非就是“找到想要的数据”，全文范围内查寻(全文检索)是一种模糊搜索的概念，找出来的数据不一定准确，所以才有了指定字段(即本文提到的field)的查寻方式，但模糊搜索在本中间层系统中仍然支持。
q＝showname：越狱
表示在节目的名称(showname)里检索关键字“越狱”，showname称之为查询字段。
更进一步，可应用多个查寻字段：
q＝showcategory：电视剧 releaseyear：2009
可找出2009年出品的电视剧。
字段值通常三种格式：
| 形式 | 格式 | 举例 | 说明 |
| 单值 | value | 2008 | |
| 多值 | value1，value2，… | 2003，2008 | 2003年或2008年 |
| 范围 | value1-value2 | 1930-1950 | 从1930年到1950 |
| 年之间 |
2、返回字段
基本形式：field1 field2…
接口参数：fd(fields)
说明：fd为返回接口参数，可根据需要，选择需要返回的字段。返回字段用参数fields，字段之间用空格隔开。例如：fd(field1field2)。
举例：
q＝showcategory：电视剧 tv_genre：古装
fd＝showname area avg_rating director tv_genre
上述会查询古装电视剧，并且返回电影的名称(showname)、评分(avg_rating)、地区(area)、导演(director)、类别(tv_genre)。
3、排序
基本形式：field1：[ASC|DESC] field2：[ASC|DESC]…
说明：指明结果集按某字段正序(ASC)或倒序(DESC)排列输出，可对字段进行排序，不是所有字段都支持排序。排序参数用ob。
举例：
q＝showcategory：电视剧
fd＝showname avg_vv
ob＝avg_vv：desc
上述查询将返回电视剧的名称(showname)、节目集均播放数(avg_vv)，并按节目集均播放数(avg_vv)倒排(desc)，倒排是缺省。
q＝showcategory：电视剧
fd＝showname releaseyear
ob＝releaseyear：asc
上述查询将返回电视剧的名称(showname)、出品年份(releaseyear)，并按出品年份(releaseyear)正排序(asc)。
还可以多个字段排序，如下例：
q＝showcategory：电视剧
fd＝showname releaseyear showweek_vv
ob＝releaseyear：desc showweek_vv：desc
4、面统计
有了查寻结果，有时候还需要知道这些结果在不同面上的统计，可使用面统计选项。面统计参数用facets或fc，各个面用空格隔开。
所谓的面统计，可理解为对一个字段下，多个值的统计。如showcategory(节目分类)，是一个可枚举的类型，它的值可以有“电影”，“电视剧”，“综艺”。面统计就是统计一下“电影”有多少节目，“电视剧”有多少节目，“综艺”有多少节目。
q＝showcategory：电视剧
fc＝area releaseyear
通过上述查询，结果中将返回电视剧分类下，地区(area)和发行时间(releaseyear，亦称出品年份)这两个字段下值的统计，返回类似如下结构：
area
大陆(8782)，
香港(2332)，
韩国(454)
…
releaseyear
2008(532)，
2006(433)，
2009(223)
…
或者地区里面只统计大陆和香港：
q＝showcategory：电视剧
fc＝area：大陆，香港
5、其它参数
a)pn(page number)页号
b)pl(page length)每页记录数
通过查寻表达式查寻，满足条件的数据可能不会只有一条记录，大多数情况都会是一个列表，pl就是指一次返回数据的“条”数。而pn是要求返回“第几页”的数据。举列：通过一个查寻表达式查寻节目，满足条件的记录有200条，每页要求返回20条记录(pl＝20)，返回第2页(pn＝2)，那么得到的数据是这200条记录中，从第21条到40条的记录。
跟据以上参数，一个完整的中间层http请求，以节目资源为例，形如：
http://ds.youku.com/show？q＝showcategory：电影 performer：李连杰&ob＝releasedate：asc&fd＝shownamereleasedate&pn＝1&pg＝10&fc＝movie_genre
解析后，该请求包括以下参数：
showcategory：电影
performer：李连杰
ob＝releasedate：asc
fd＝showname releasedate
pn＝1
pg＝10
fc＝movie genre
以上请求会返回“李连杰演过的所有电影的第1页的前10条记录(pn，pl参数)，并按发行时间正序排列(ob参数)，同时按电影的二级分类直接面统计(fc参数)，要求返回字段为节目名称和该电影的发行时间(fd参数)”，得到的结果如下(以下表格只是为了阅读方便，实际程序当中返回的是json串形式)
筛选结果当前显示：1-10
| pk_odshow | showname | releasedate |
| 29275 | 少林寺 | 1982-01-21 |
| 26806 | 少林小子 | 1984-01-26 |
| 44095 | 中华武术84版 | 1984-07-14 |
| 29153 | 南北少林 | 1986-03-01 |
| 30687 | 中华武术87版 | 1987-01-01 |
| 10380 | 东方巨龙 | 1988-01-01 |
| 10703 | 东方巨龙 | 1988-01-01 |
| 28283 | 少林海灯大师 | 1988-01-01 |
| 26545 | 龙行天下 | 1989-05-26 |
| 57422 | 黄飞鸿91版 | 1991-01-01 |
记录总数：63
面统计结果
movie_genre
动作：49
剧情：21
纪录片：12
冒险：10
惊悚：10
历史：7
犯罪：7
喜剧：6
奇幻：5
武侠：5
爱情：5
科幻：2
动画：1
恐怖：1
战争：1
西部：1
说明：
pk_odshow就是节目的ID，也是索引中所指的文档ID，所有资源的文档ID字段不需要fd参数指明，默认都会返回。
showname为节目名称，releasedate为该节目的发行日期(当然以上实例数据仅做为演示)，这两个字段正是我们通过fd参数指定的字段。
由于我们指明了ob参数，要求以releasedata字段正序排列，所以返回的顺序都是以该字段正排。
记录总数63表示满足q＝showcategory：电影 performer：李连杰这个条件的记录数有63条，而我们由于指定了pn＝1和pg＝10，所以返回这63条记录中的前10条。
按movie_genre(电影下的分类)进行面统计，统计出李连杰演过的电影中，动作片有多少(动作：49，即49部)，剧情片有多少(剧情：21，即剧情片21部)，值得注意的是，电影分类是可以多选的，如一部电影可以即是动作片，也可以同时是部剧情片，所以面统计的总数，一般不会等于记录总数。
具体的实施例
1、节目和视频筛选页
事例地址：http://www.youku.com/v_olist/c_97.html
以电视剧筛选页为例，其筛选条件有地区、类型、上映(时间)、排序等条件，用户可以点击任意条件，从不同唯独任意组合进行筛选喜欢的电视剧。
2、作为CMS系统数据源
目前网站大部分的频道页，都是由CMS系统完成，而里的呈现的数据，则由中间层提供，以电影频道页(http://movie.youku.com/)中的新片精选为例。
查询条件：
q＝showcategory：电影 hasvideotype：正片 state：normalcopyright_status：authorized，public
返回结果：
fd＝showid showname showsubtitle show_thumburlshowcategory deschead area streamtypes director performerreputation firstepisode_videourl
排序条件：
ob＝showyesterday_search
结果数目：
pl＝20
以上条件获取的数据内容为：
有正片(hasvideotype：正片)且版权状态为已授权和公共版权(copyright_status：authorized，public)的昨天搜索量最高的(ob＝showyesterday_search)电影(showcategory：电影)状态正常(state：normal)前20条(pl＝20)记录。
本发明所述方法可以进行多面筛选。
在优酷，用户筛选视频的需求是无法预测和多变的，很难给出某种固定的分类顺序来满足大多数用户的需求。通过多面筛选会引导用户筛选他最感兴趣的视频，用户在筛选的过程中筛选条件可以是动态的，通过添加新的筛选条件，进一步缩小筛选范围。有限维度条件可以搭配出无限多种筛选的可能。
比如：
“爱情片”？
“这两年最热的古装电视剧”？
“孙红雷演的电视剧”
“本周高清预告片”？
“80年代的中国老电影”？
同传统的目录型分层系统不同，多面分类法(facetedclassification)并不假定用户筛选视频的维度数量或顺序，维度都是同等对待。用户通常会从他最关心的维度开始筛选视频，并且往往是多种维度的组合。因此，上述问题被分解成以下维度的组合：
本发明所述的中间层系统为实现上述计算提供多面筛选接口和查询表达式，并且封装了实现方法，由于接口的相对稳定性，后端系统和前端系统可以分别独立的进行改进，从而方便整体系统的优化。
中间层经过优化设计，任意组合查询通常能得到极好的性能，前端不用关心性能问题。
有多个系统模块可以采用多面筛选服务，多面筛选API同各个系统的关系参见图3.
本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (6)
1.一种用于数据库信息检索的中间层系统，其特征在于，包括：
用于接收应用层发出的检索请求的API应用服务器群组，所述应用层发出的检索请求为一个符合URL规范的http地址，该http地址中包括用于在数据库中进行检索的相应的参数，
用于接收API应用服务器群组转发的检索请求的索引服务器群Sphinx Server，所述索引服务器群包括若干节点服务器Node IndexerServer，
用于接收API应用服务器群组转发的检索请求的在线数据库服务器群，所述在线数据库服务器群包括若干在线数据库群组，
离线数据库服务器群，通过数据交互通道与在线数据库服务器群进行数据同步，所述离线数据库服务器群包括若干离线数据库群组，
索引创建服务器，索引创建服务器跟据索引配置文件中指定的离线数据库群组得到数据来创建索引，索引创建服务器创建索引的过程，就是生成索引文件的过程，索引文件存储在索引创建服务器中，
索引服务器群中的各节点服务器从索引创建服务器中获取最新的索引文件。
2.如权利要求1所述的用于数据库信息检索的中间层系统，其特征在于：所述API应用服务器群组包括若干APP服务器APP Server，每个APP Server中均设有服务软件，所述服务软件包括：用来接收http请求的服务软件nginx，用来管理php运行进程的服务软件phpfpm，用来解析php脚本的服务软件php，服务软件用于完成接收请求和语法分析，此即语法分析引擎。
3.如权利要求1所述的用于数据库信息检索的中间层系统，其特征在于：索引文件会放在索引创建服务器上的FTP服务目录下，通过服务器上的定时任务执行程序定时生成一个新的索引文件，并以文本方式记录本次生成的索引文件的版本号，新的版本号是上一次生成的版本号加一；
索引创建服务器同时安装了FTP服务，节点服务器通过FTP客户端命令，访问到FTP服务目录下的各个索引文件。
4.如权利要求3所述的用于数据库信息检索的中间层系统，其特征在于：节点服务器每次从索引创建服务器下载索引文件，也会在本地记录当前节点服务器中所使用的索引文件的版本号，
节点服务器定时将本地当前节点服务器中所使用的索引文件的版本号与索引创建服务器上最新的索引文件的版本号对比，当本地当前节点服务器中所使用的索引文件的版本号小于索引创建服务器上最新的索引文件的版本号时，则重新下载索引创建服务器上最新的索引文件。
5.一种基于权利要求1所述的用于数据库信息检索的中间层系统的信息检索方法，其特征在于，包括以下步骤：
步骤1，MySQL在线数据库和离线数据库的内容是一一对应的，有一个在线视频库，就会有一个离线视频库，通过MySQL的主从同步复制功能，将在线数据库实时同步复制到离线数据库当中；
步骤2，MySQL离线数据库是专门供索引创建服务器使用的，索引创建服务器上安装sphinx的indexer程序，indexer程序会跟据对应的配置文件，生成索引，
所述配置文件包括数据来源参数，数据来源参数指向MySQL离线数据库，
sphinx的indexer程序定时生成索引文件；
步骤3，API应用服务器装有nginx、php-fpm和php，nginx用于接收到http请求，php-fpm负责调用php脚本，而php本身是用来解析语法分析引擎的程序；当服务器接收到http请求时，对http请求中的参数进行分析通过对查询条件指定参数q和排序参数ob进行分析，确定需要查寻哪些条件，将分析结果转换成sphinx可以识别的查寻条件，向索引服务器发送查寻请求，索引服务器跟据查寻条件，在索引中进行查寻，索引服务器将查寻后的文档ID返回给API应用服务器；
步骤4，API应用服务器得到文档ID后，通过分析http请求中的fd参数，确定需要返回哪些字段，然后利用刚刚得到的文档ID去MySQL数据库进行查寻需要返回的数据，所述文档id在mysql里为主键。
6.如权利要求5所述的信息检索方法，其特征在于：在MySQL在线数据库和离线数据库中，跟据业务需求按群组划分数据库。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110336342.7A CN102426589B (zh) | 2011-10-31 | 2011-10-31 | 一种用于数据库信息检索的中间层系统及信息检索方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110336342.7A CN102426589B (zh) | 2011-10-31 | 2011-10-31 | 一种用于数据库信息检索的中间层系统及信息检索方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102426589A CN102426589A (zh) | 2012-04-25 |
| CN102426589B true CN102426589B (zh) | 2013-04-03 |
Family
ID=45960570
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110336342.7A Active CN102426589B (zh) | 2011-10-31 | 2011-10-31 | 一种用于数据库信息检索的中间层系统及信息检索方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102426589B (zh) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102779160B (zh) * | 2012-06-14 | 2016-02-03 | 中金数据系统有限公司 | 海量数据信息索引系统和索引构建方法 |
| CN102938789B (zh) * | 2012-11-19 | 2015-04-29 | 江苏省公用信息有限公司 | 一种移动互联网手机应用下载组合分析方法和装置 |
| CN103744896A (zh) * | 2013-12-24 | 2014-04-23 | 乐视网信息技术（北京）股份有限公司 | 一种数据处理方法和装置 |
| CN105338037A (zh) * | 2014-08-07 | 2016-02-17 | 中兴通讯股份有限公司 | 一种动态调度方法及系统 |
| CN105607895B (zh) * | 2014-11-21 | 2021-03-02 | 阿里巴巴集团控股有限公司 | 一种基于应用程序编程接口的应用程序的运行方法和装置 |
| CN104486574A (zh) * | 2014-12-25 | 2015-04-01 | 浪潮软件集团有限公司 | 一种基于音视频平台的办税服务厅音视频应用方法 |
| WO2016187771A1 (zh) * | 2015-05-25 | 2016-12-01 | 武克易 | 基于用户行为分析的云电视数据获取方法及系统 |
| CN105069151A (zh) * | 2015-08-24 | 2015-11-18 | 用友网络科技股份有限公司 | HBase二级索引构建装置和方法 |
| CN106815136B (zh) * | 2015-11-30 | 2020-03-03 | 北京国双科技有限公司 | 单元测试方法及装置 |
| CN105843895B (zh) * | 2016-03-22 | 2019-07-02 | 北京建飞无限科技有限公司 | 基于Ehcache的数据查询及同步方法，装置及系统 |
| CN107346320B (zh) * | 2016-05-06 | 2020-09-01 | 北京神州泰岳软件股份有限公司 | 一种数据调用方法和装置 |
| US11537272B2 (en) * | 2016-12-21 | 2022-12-27 | Aon Global Operations Se, Singapore Branch | Content management system extensions |
| CN107679195B (zh) * | 2017-10-09 | 2021-01-22 | 杭州安恒信息技术股份有限公司 | 基于https协议传输的半主从数据库同步方法及系统 |
| CN110109949A (zh) * | 2017-12-26 | 2019-08-09 | 北京航天泰坦科技股份有限公司 | 社会信用信息服务平台 |
| CN109992987B (zh) * | 2017-12-29 | 2021-04-27 | 港融科技有限公司 | 基于Nginx的脚本文件保护方法、装置及终端设备 |
| CN108399223B (zh) * | 2018-02-12 | 2022-06-03 | 北京奇艺世纪科技有限公司 | 一种数据获取方法、装置及电子设备 |
| CN110309176B (zh) * | 2018-03-15 | 2024-04-05 | 腾讯科技（深圳）有限公司 | 一种数据处理方法和数据中转站 |
| CN108920610B (zh) * | 2018-06-28 | 2021-07-16 | 上海连尚网络科技有限公司 | 一种小说索引方法及设备 |
| CN108959538B (zh) * | 2018-06-29 | 2021-03-02 | 新华三大数据技术有限公司 | 全文检索系统及方法 |
| CN109213518A (zh) * | 2018-08-16 | 2019-01-15 | 安徽云才信息技术有限公司 | 一种基于git的系统自动化持续构建的方法 |
| CN110008269B (zh) * | 2019-03-26 | 2023-08-01 | 创新先进技术有限公司 | 一种数据回流方法、装置、设备及系统 |
| CN111209462B (zh) * | 2020-01-02 | 2021-05-18 | 北京字节跳动网络技术有限公司 | 数据处理方法、装置及设备 |
| CN113297201A (zh) * | 2020-06-29 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 索引数据同步方法、系统及装置 |
| CN112183110A (zh) * | 2020-09-28 | 2021-01-05 | 贵州云腾志远科技发展有限公司 | 一种基于数据中心的人工智能数据应用系统及应用方法 |
| CN113643425A (zh) * | 2021-07-28 | 2021-11-12 | 中石化石油工程技术服务有限公司 | 一种基于开源gis技术的石油地震成果三维空间可视化通用平台构建方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5907837A (en) * | 1995-07-17 | 1999-05-25 | Microsoft Corporation | Information retrieval system in an on-line network including separate content and layout of published titles |
| JP2005514673A (ja) * | 2001-06-22 | 2005-05-19 | オモイグイ，ノサ | 知識の取得、管理、伝達、及び提示のシステム及び方法 |
| CN101833568B (zh) * | 2010-04-01 | 2012-02-08 | 武汉大学 | Web数据管理系统 |
| CN101937469B (zh) * | 2010-09-15 | 2012-09-05 | 任子行网络技术股份有限公司 | 视频网站的信息抓取方法 |
-
2011
- 2011-10-31 CN CN201110336342.7A patent/CN102426589B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN102426589A (zh) | 2012-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102426589B (zh) | 一种用于数据库信息检索的中间层系统及信息检索方法 | |
| US11068439B2 (en) | Unsupervised method for enriching RDF data sources from denormalized data | |
| CN106326429A (zh) | 一种基于solr的Hbase秒级查询方案 | |
| CN109388637A (zh) | 数据仓库信息处理方法、装置、系统、介质 | |
| US20100169361A1 (en) | Methods and apparatus for generating a data dictionary | |
| US9959326B2 (en) | Annotating schema elements based on associating data instances with knowledge base entities | |
| US11755651B2 (en) | Method, apparatus, and computer-readable medium for generating categorical and criterion-based search results from a search query | |
| JP2017076435A (ja) | 広告キャンペーンの生成 | |
| CN103984745A (zh) | 分布式视频垂直搜索方法及系统 | |
| CN101789006A (zh) | 基于智能搜索的电网企业信息集成系统的快速检索方法 | |
| Kochtchi et al. | Networks of Names: Visual Exploration and Semi‐Automatic Tagging of Social Networks from Newspaper Articles | |
| Liang et al. | Co-clustering WSDL documents to bootstrap service discovery | |
| CN105868225A (zh) | 数据查询的方法、客户端、服务器及系统 | |
| Zhou et al. | Bibliography-based quantitative translation history | |
| CN113360500A (zh) | 数据处理方法及装置、存储介质、电子设备 | |
| Hassanzadeh et al. | Helix: Online enterprise data analytics | |
| US8290950B2 (en) | Identifying locale-specific data based on a total ordering of supported locales | |
| US10462236B2 (en) | Coordinating metgadata | |
| CN105184550B (zh) | 管理排期数据的方法、服务器及系统 | |
| Zhang et al. | The Analysis and Implementation of Film Decision‐Making Based on Python | |
| Tan et al. | Placing videos on a semantic hierarchy for search result navigation | |
| Apanovich | Matching of Authors and Publications in Multilingual Bibliographic Knowledge Bases. | |
| Papadakis et al. | Employing Twitter hashtags and linked data to suggest trending resources in a digital library | |
| KR20210037488A (ko) | 빅데이터 분석 기반 광고 마케팅 시스템 | |
| Ying et al. | A commodity search system for online shopping based on ontology and web mining |
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 | ||
| CP01 | Change in the name or title of a patent holder | ||
| CP01 | Change in the name or title of a patent holder |
Address after: 100080 Beijing Haidian District city Haidian street A Sinosteel International Plaza No. 8 block 5 layer A, C Patentee after: Youku network technology (Beijing) Co.,Ltd. Address before: 100080 Beijing Haidian District city Haidian street A Sinosteel International Plaza No. 8 block 5 layer A, C Patentee before: 1VERGE INTERNET TECHNOLOGY (BEIJING) Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20200323 Address after: 310003 room 508, floor 5, building 4, No. 699, Wangshang Road, Changhe street, Binjiang District, Hangzhou City, Zhejiang Province Patentee after: Alibaba (China) Co.,Ltd. Address before: 100080 Beijing Haidian District city Haidian street A Sinosteel International Plaza No. 8 block 5 layer A, C Patentee before: Youku network technology (Beijing) Co.,Ltd. |