系统(UMTS)(特别地，长期演进(LTE))、全球移动通信系统(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信系统，但是这样的教导同样适用于其它类型的系统。
[0070]参考图2，⑶MA无线通信系统可以包括多个移动终端100、多个基站(BS)270、基站控制器(BSC)275和移动交换中心(MSCUSOJSCSSO被构造为与公共电话交换网络(PSTN)290形成接口。MSC280还被构造为与可以经由回程线路耦接到基站270的BSC275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM，IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的系统可以包括多个BSC2750。
[0071]每个BS270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离BS270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个BS270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25MHz，5MHz 等等)。
[0072]分区与频率分配的交叉可以被称为CDMA信道。BS270也可以被称为基站收发器子系统(BTS)或者其它等效术语。在这样的情况下，术语"基站"可以用于笼统地表示单个BSC275和至少一个BS270。基站也可以被称为〃蜂窝站〃。或者，特定BS270的各分区可以被称为多个蜂窝站。
[0073]如图2中所示，广播发射器(BT)295将广播信号发送给在系统内操作的移动终端100。如图1中所示的广播接收模块111被设置在移动终端100处以接收由BT295发送的广播信号。在图2中，示出了几个全球定位系统(GPS)卫星300。卫星300帮助定位多个移动终端100中的至少一个。
[0074]在图2中，描绘了多个卫星300，但是理解的是，可以利用任何数目的卫星获得有用的定位信息。如图1中所示的GPS模块115通常被构造为与卫星300配合以获得想要的定位信息。替代GPS跟踪技术或者在GPS跟踪技术之外，可以使用可以跟踪移动终端的位置的其它技术。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。
[0075]作为无线通信系统的一个典型操作，BS270接收来自各种移动终端100的反向链路信号。移动终端100通常参与通话、消息收发和其它类型的通信。特定基站270接收的每个反向链路信号被在特定BS270内进行处理。获得的数据被转发给相关的BSC275ASC提供通话资源分配和包括BS270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数据路由到MSC280，其提供用于与PSTN290形成接口的额外的路由服务。类似地，PSTN290与MSC280形成接口，MSC与BSC275形成接口，并且BSC275相应地控制BS270以将正向链路信号发送到移动终端100。
[0076]基于上述移动终端硬件结构以及通信系统，提出本发明各个实施例。
[0077]实施例一
[0078]当前，在流程工业面临着海量数据时序存储管理的困境时，互联网公司也在面临着海量数据管理的难题。以Had00p、HBaSe等为代表的大数据技术为海量数据管理提供了一种解决方案，并为当前淘宝、百度、搜狐等许多互联网公司采用。Hadoop是一种可靠、可伸缩的分布式文件系统，HBase (Hadoop Database，分布式数据库)是一个分布式、可伸缩的NoSQL(Not Only Structured Query Language，非关系型数据库)数据库，它构建在Hadoop基础设施之上，依托于Hadoop的迅猛发展，HBase在大数据领域的应用越来越广泛。本发明实施例是基于HBase的分布式数据库展开说明，HBase分布式数据库中主键称为RowKey主键，数据库中的Schema信息称为数据库对象的集合，包括表，索引，视图，图表，缺省值，规贝1J，触发器，语法，函数等。
[0079]采用HBase作为消息存储的持久层对比RDBMS的优点如下:
[0080](l)HBase是一个分布式的、面向列的数据存储系统。HBase自底层设计开始将聚焦于各种可伸缩性的问题:表可以很大，将其水平分区并在上千个普通节点上自动复制。而RDBMS只能支持单机，或者手动采用横向切分的方式将数据分配到不同服务器上，如果采用横向切分的方式，不仅增加了程序的复杂度，而且很难以进行多库查询，同时无法自动负载均衡，灵活性很差。
[0081](2)由于HBase没有真正的索引，由于行是顺序存储的，每行中的列也是顺序存储的所以不存在索引膨胀的问题，而且插入性能与表的大小无关。而RDBMS随着数据量的增大，由于索引膨胀，插入速度将越来越慢。
[0082](3)HBase支持分布式写，可以多台服务器同时并发写。而RDBMS无法支持，即使使用主从模式，通常情况下也只能一台DB作为写操作的DB，因为多台DB进行写将面临非常复杂的数据同步问题。
[0083](4)HBase具有高速插入快速读取的优点。经过对比实验，典型的RDBMS数据库MySQL单表插入速度为每秒6500条，HBase单台机器能够实现lw?3w之间的插入速度，这充分说明HBase插入数据的速度比MySQL高很多。在MySQL单机随机读写能力测试中，单条数据全表随机读取时间是指依据主键去MySQL单表取数据花费的时间；在HBase基本说明与性能测试中，大数据量下查询响应时间是指依照Rowkey到HBase取数据所花费的时间。30ms对5ms，这说明HBase取数据的速度之快也是MySQL望尘莫及的。
[0084]而大型消息系统的消息数据具有以下特点:数据大、结构简单、时间相关，因而结合上述HBase的优点，本实施例采用Hadoop和HBase作为底层存储支撑技术，利用它们的高扩展性以支持海量消息数据高性能存储管理。
[0085]消息数据可以划分为两大类:一类消息数据能够用数字或统一的结构加以表示，称之为结构化数据，如数字、符号；而另一类消息数据无法用数字或统一的结构表示，如文本、图像、声音、网页等，称之为非结构化数据。本发明涉及到的消息数据类型即包括结构化消息数据类型和非结构化消息数据类型。
[0086]由于结构化消息数据和非结构化消息数据的差异化，本实施例提出的基于HBase的大型消息数据管理方法包括以下几个方面:结构化消息数据的存储步骤、非结构化消息数据的存储步骤、结构化消息数据的查询步骤、非结构化消息数据的查询步骤。下面将分别进行描述。
[0087]—、结构化消息数据的存储步骤，如图3所示，包括:
[0088]步骤301、将结构化消息数据按照类型分别建立领域模型。
[0089]在不同场景下，结构化数据的具体类型也会不同，典型场景比如企业ERP、财务系统、医疗HIS数据库、教育一卡通、政府行政审批、其他核心数据库等，因而本步骤中需要首先按照结构化消息数据类型来分别建立相应的领域模型。
[0090]步骤302、在HBase数据库中建立数据库表，设计该数据表的Schema信息。
[0091 ]其中所述Schema信息包括table name(表名称)，families(列簇)，columns(列)，main table rowkey生成规则(主表主键生成规则)，index rowkey生成规则(索引主键生成规则)，index columns(索引列)。
[0092]该Schema信息是常用的一种表征用户所创建的对象(包括表，索引，存储过程)的集合，其属于数据库对象管理的范畴，所以此处不再对其原理和内容进行说明。
[0093]此外，Schema信息中包含的的table name，fami 1 ies，columns，main tablerowkey生成规则，index rowkey生成规则，index columns就是上述用户所创建的对象(包括表，索引，存储过程等)，而且在现有的数据库技术中上述对象均是常用地对象内容，所以此处同样不再对上述对象的内容和原理进行解释说明。
[0094]本实施例正是充分利用Schema信息来为HBase的数据表进行定义，实现大并发的快速写入。
[0095]步骤303、将待存储的结构化消息数据按照领域模型进行转换，然后存入数据库表中单独的列簇。
[0096]上述流程中，通过Schema信息的设计，可以实现结构化消息数据的高效读写，可满足消息系统的需求。
[0097]二、非结构化消息数据的存储步骤，如图4所示，包括:
[0098]步骤401、在HBase数据库中新增一个列簇，将待存储非结构化消息数据存储于该列簇中。
[0099]非结构化消息数据的种类包括:文本、图像、声音、网页、视频等。
[0100]步骤402、在HBase数据库中通过其他列簇存储待存储非结构化消息数据的相关信息，包括这类内容的类型、存储大小、创建时间、修改时间。
[0101]步骤403、在每个列簇存储信息时，以Key(键)、Value(值)的方式存储每行单元格中的数据，形成若干数据块;然后将数据块保存到HBase数据库的HFile文件(格式文件)中，最后将HFile文件保存到后台的Hadoop分布式文件系统中。
[0102]三、结构化消息数据的查询步骤，如图5所示，包括:
[0103]步骤501、实例化HTablePool对象，根据实例化的HTablePool