论文部分内容阅读
摘要：该文将研究移动终端大数据的文件存储技术，以电子邮件和短彩信消息文件的存储为实例，提出了一种在移动终端大数据环境下的消息文件存储和操作的算法，实现精确控制读写数据正确位置，避免了重写所有数据，极大减少IO操作负担，提升移动终端大数据读写操作性能。
关键词：移动终端;数据存储
中图分类号：TP3 文献标识码：A
文章编号：1009-3044（2021）30-0037-03
开放科学（资源服务）标识码（OSID）：
互联网数据中心（IDC）报告指出，2012 年全球已经开始进入大数据时代，并在2013 年全面引爆大数据。大数据，最具有代表性的是其“4V”的特点：Volume-數据规模大;Velocity-数据的产生速度很快，处理速度快;Variety-多样性，包括各种不同的类型和编码格式，数据类型繁多;Veracity-真实性，只有真准确的数据才使得对数据的分析有意义。在移动互联大数据时代，用户要求有更好的网络体验，基本需求是能在任意时间、任意地点通过移动指端移动终端接入网络，既是移动大数据的产生者，又是移动大数据的使用者，因此大数据服务一方面将推动管道技术演进，另一方面也推动移动终端的技术演进。
1移动大数据的特性
移动互联大数据导致移动终端从功能型移动终端向智能型移动终端。作为移动大数据的重要输入输出者，用户通过智能移动终端使用移动应用程序，产生各种与用户消费、出行以及娱乐等与生活密切相关的海量数据，这些海量数据如果完全存储在中心服务器上，会导致中心服务器负载过大，网络交互过于频繁，因此利用智能移动终端进行数据存储及性能优化，不仅能够减轻中心服务器端的数据存储及运算负担，还能充分发挥智能移动终端的硬件性能，特别是在离线情况下，通过缓存在智能移动终端的应用数据，仍能为用户及时地提供部分应用服务。移动互联大数据具有以下特性：
1.1 时空性
智能移动终端都具备GPS定位功能，因此数据的时空特性是移动大数据固有的鲜明特征。即使智能移动终端关闭了GPS定位服务功能，仍然可以通过基站位置粗略地推断出用户的位置。多维时空数据包含用户行动信息，在基于位置服务的智能打车、智能驾驶、网络商城、游戏、社交网络等各种应用中具有广泛的潜力。
1.2 个人定制性
从智能移动终端产生的数据始终包含用户身份信息。这些数据通常具有高度个人定制性。通过对这些包含个人信息的移动大数据进行分析和预测，预测出用户的个人行为偏好和习惯，通过专业的推荐系统，为每个用户提供精准的个人定制化服务。如浏览器个性推荐功能，网上购物个性推荐服务等。当然，任何事物都具有双面性，如果移动数据保密性不够，导致用户个人信息泄露，将在很大程度上侵犯用户的隐私并导致用户的生命财产受到侵害，因此数据安全性和保密性值得引起重视。
1.3 实时性
移动互联网的一个典型需求是应用程序服务端需要实时地向用户提供数据交互和服务，即数据必须具有实时性。如网络游戏、社交通讯、智能打车、金融 等应用程序，如果不能实现数据的实时交互，不仅影响用户体验，而且会造成用户的信息交流的延误和财产损失。然而，移动应用服务器端如果承担所有数据的存储、处理和分发，受硬件设备计算能力、存储空间和网络带宽的限制，难以满足海量数据的实时交互需求。因此，充分利用智能移动终端的计算能力和存储空间，存储一部分移动数据，减轻服务器端和网络带宽的负载，是一种可行且高效的解决方案。
2主流大数据框架和技术
为了存储和处理海量大数据，很多企业和高校开发了多种大数据处理框架和平台，主流的框架和技术包括：MapReduce、GFS、BigTable、Spark和Hadoop等技术。
2.1 Hadoop框架
Hadoop是一个包含开源代码的分布式文件系统和一个并行处理的MapReduce框架。HDFS为海量数据提供存储服务，而MapReduce则为海量数据提供计算引擎。HDFS设计思想有以下几点：1）在数据中心，硬件异常应被视作常态;2）流式数据访问：满足批处理而不是交互式处理需求;3）HDFS设计的重点是支持大文件;4）HDFS提供的访问模型是一次写入多次读取的简单数据一致性模型;5）移动计算优于移动数据：读取和计算采取就近原则;6）兼容各种硬件和软件平台。HDFS有其缺陷，不适合的场景包括：1）大量小文件;2）低延迟数据访问;3）多用户写入。
2.2 分布式文件系统HDFS
其中，HDFS为海量数据提供存储服务，而MapReduce则为海量数据提供计算引擎。HDFS设计思想有以下几点：1）在数据中心，硬件异常应被视作常态;2）流式数据访问：满足批处理而不是交互式处理需求;3）HDFS设计的重点是支持大文件;4）HDFS提供的访问模型是一次写入多次读取的简单数据一致性模型;5）移动计算优于移动数据：读取和计算采取就近原则;6）兼容各种硬件和软件平台。HDFS有其缺陷，不适合的场景包括：1）大量小文件;2）低延迟数据访问;3）多用户写入。
2.3 MapReduce模型
MapReduce是Google公司的核心计算模型，它将复杂的运行于大规模集群上的并行计算过程高度地抽象到两个函数：Map和Reduce。这两个函数由用户负责实现，功能是按一定的映射规则将输入的<key，value>对转换成另一个或一批<key，value>对输出。MapReduce的基本运行流程包括：1）作业启动;2）作业初始化;3）作业、任务调度;4）Map任务执行;5）shuffle;Reduce任务执行;7）作业完成。MapReduce作为分布式并行计算框架，主要由JobClient、JobTracker、TaskTracker等组件构成。核心设计思想：分而治之、分合结合、衔接有序、就近处理、可靠容错。 MapReduce的目标是解决海量数据的并行计算问题。它屏蔽了分布式计算框架的细节，将计算高度抽象成map和reduce两函数，其中map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。reduce则对中间结果中相同“键”的所有“值”进行合并，以得到最终结果。
2.4 Spark框架
Spark是在2009年由加州大学伯克利分校的AMPLab开发，提供了一个全面、统一的框架，用于大数据处理的需求。Spark的架构中的基本组件包括：Cluster Manager、Worker、Driver、Executor、SparkContext、RDD、DAG Scheduler、TaskScheduler以及SparkEnv。Spark的运行流程如下：
1）构建Spark Application的运行环境，启动SparkContext;
2）SparkContext向资源管理器（可以是Standalone，Mesos，Yarn）申请运行Executor资源，并启动StandaloneExecutorbackend;
3）Executor向SparkContext申请Task;
4）SparkContext将应用程序分发给Executor;
5）SparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给Task Scheduler，最后由Task Scheduler将Task发送给Executor运行;
6）Task在Executor上运行，运行完释放所有资源。
Spark与Hadoop相比，有如下差异：1）Spark与Hadoop有两个核心模块，分布式存储模块HDFS和分布式计算模块MapReduce;2）Spark本身并没有提供分布式文件系统，因此Spark的分析大多依赖于Hadoop的分布式文件系统HDFS;3）相比于MapReduce，Spark的速度更快并且提供的功能更加丰富。
尽管国内外学者在服务器端大数据存储、大数据处理、数据集共享方面开展了一些研究，并取得了很多研究成果，但是基于移动终端的数据存储，特别是基于移动终端的大数据存储及优化问题，迄今未见有相关报道。
本文将研究移动终端大数据的文件存储技术，以电子邮件和短彩信消息的文件存储为实例，提出了一种移动终端大数据环境下的索引文件偏移量存储算法，实现精确控制读写数据正确位置，避免了重写所有数据，极大减少IO操作负担，提升移动终端大数据读写操作性能，提出移动终端大数据环境下多级索引存储算法，移动终端具体数据和相对位置分离即索引头和位置关系分开存储，实现移动终端环境下大数据存储索引有序。构建一个移动终端通用、高性能、可推广存储模型，充分发挥移动终端性能，有效减轻服务端数据存储、运算负担，降低移动终端和服务器端不必要的數据交互。
3消息文件的存储设计
移动终端大数据环境下，移动终端中一个消息文件不能是一维扁平的存储，因为这样会极大降低海量消息文件的操作性能。因此，我们将消息文件的结构设计成三种组成部分，包括消息体、消息头和消息头索引，如图1所示。其中：
1）消息体：包括消息的具体内容，该部分数据量较大不需要频繁操作和访问。
2）消息头：包括各种消息的头信息：如主题，发件人，收件人，时间等内容，这部分被划分出来的依据为，该项内容会被频繁使用，比如消息列表需要展现该部分数据，并且需要列表告诉滑动，就要求获取数据迅速。
3）消息头索引：该部分为最高层结构，提取出了各个消息之间的相对位置，维护了各种位置序列。
3.1 消息管理方法
移动终端大数据环境下，消息文件管理主要通过系统中维护的几条链表实现，包括：索引头链表、消息头链表和空闲消息头链表，如图2所示。
其中，索引头链表维护消息的前后顺序，比如：时间，状态顺序等，序列化为索引头文件;消息头链表维护着有效消息的头结点，空闲消息头链表维护着无效消息的头结点，两条链表序列化为消息头文件，如果需要删除一条消息，则从消息头链表中移除一个结点，放入空闲消息头链表，如果增加一条消息，则首先在空闲消息头链表中寻找是否有空闲结点，若找到转化为有效结点并加入有效消息头链表中。
3.2消息链表管理方法
由于消息包含不同状态，并且对应着不同的业务逻辑，因此会产生大量链表管理起来非常麻烦，因此消息链表也需要管理起来，这里使用单例模式维护唯一链表指针，并使用工厂模式进行管理，用户只需输入key值便能得到对应链表头指针，无须知道构造细节。而各链表常驻内存，使用惰性初始化，当第一次被使用时进行初始化。
由于消息模块箱子较多，消息数量也较多，一直常驻内存对于某些内存较小低端机负担较大，因此也需要定期置换出部分不使用的链表以释放内存。
3.3 链表管理置换算法—LRU算法
LRU（Least Recently Used）即最近最久未使用页面置换算法，算法的思路就是认为最久未使用链表为最不常用的链表，因此优先级最低将其置换出去，从而换入新的链表进入。
在这里我们的具体算法为：（1）将所有链表头指针存于一个链表管理器中（使用链表实现）;（2）每次新请求对应key值的链表头，则先在管理链表中寻找是否存在，若存在直接返回，若不存在则添加入对应Key值的链表头入该链表管理器中;（3）添加新链表时候需要检查是否超过管理器最大上限，若超过最大上限，则置换出链表管理器末尾最后一个最老链表，并释放掉该链表头指针指向的整条链表。
3.4海量消息文件存储的操作原理
海量消息文件存储中，包括几个重要操作的原理及流程，如：消息增加、消息删除、消息加载等。 1） 消息新增管理
对于新增消息需要找到合适的位置插入且生成有效id号，首先寻找对应的空闲消息头链表是否有空闲结点，若有则摘取一个转到有效链表中，并在对应位置写入消息记录，若无则获得链表最大结点数加1后得到新的id号，然后把生成的新结点添加到链表恰当位置处，具体流程如图3所示。
2） 海量消息文件删除的原理
对于删除操作并不真正将消息记录从文件系统中直接清除掉，而是在对应记录中写入无效标示，这样只需要找到适当位置写入少量字节即可。
看起来每删除一条消息，仿佛在索引文件上挖一个坑，然后用空闲链表idleList将这些坑串联起来，如果新来一条消息，就优先把这样的坑分给它。
3） 消息装载原理
消息文件的装载过程即为一个反序列化过程，从文件系统读取各种数据和关系，转化为数据结构供上层使用的过程。
此为存储的一个反过程，读取分为有序读取和无序读取，如果无序读取只需要加载索引文件，而读取有序消息索引则需要首先读取索引头文件，获得索引头结点，再查询索引结点组装成完整的索引结点信息。
4结论
向单个智能移动终端存储分别存储1000和5000条消息，每存储一条打印出该条消息存储消耗时间，这样可横向可以比较随着消息的增多，性能衰减情况，纵向可以比较新旧两种方式的效率。采用本文提出的文件存储操作方法，与整个消息文件存储的方法进行比对，结果本文提出的文件存儲操作方法在总体时间消耗比后者低，并且操作效率与测试数据规模的相关性低，而第二种方式会随着数据规模增加，效率急剧衰减。
新方案由于实现了性能对数据规模的依赖相关性，因此在时间消耗上不会随着数据规模增加而增加，提升了还是消息文件的存储和操作性能。但其仍存在一些待改进的地方，如在文件系统中增删消息会在多个文件中读写，因此如果在中途发生意外就容易形成数据破坏，而这多个操作是原子的，需要事务来保证，因此在设计的时候需要加入对事务的考虑，若一个事务未来完成，需要进行回滚处理。移动互联大数据环境下，移动终端数据急剧增长，导致网络出现延迟和丢包现象，服务器 端超负荷运行。研究移动终端大数据存储，可提升移动软件应用性能及用户体验质量移动，降低服务器端存储和运算数据量，充分发挥移动终端硬件性能。因此，如何存储这些数量骤升的移动终端数据将成为企业和学术界的研究热点。
参考文献
[1] 陈博，顾旻霞.移动终端HTML5Web应用技术与标准[J].电信网技术，2012（5）：5-9.
[2] Ghemawat S，Gobioff H，Leung S T.The Google file system[C]//Proceedings of the nineteenth ACM symposium on Operating systems principles - SOSP '03.October 19-22，2003.Bolton Landing，NY，USA.New York：ACM Press，2003：29-43.
[3] ZhongL Z，WangB Z，WangZ Y，et al.Research and application of massive data processing technology[C]//20138th International Conference on Computer Science & Education.April26-28，2013，Colombo，SriLanka.IEEE，2013：829-833.
[4] Kaushik R T，Bhandarkar M，Nahrstedt K.Evaluation and analysis of GreenHDFS：a self-adaptive，energy-conserving variant of the hadoop distributed file system[C]//2010 IEEE SecondInternational Conference on Cloud Computing Technology and Science.November30 - December3，2010，Indianapolis，IN，USA.IEEE，2010：274-287.
【通联编辑：朱宝贵】
关键词：移动终端;数据存储
中图分类号：TP3 文献标识码：A
文章编号：1009-3044（2021）30-0037-03
开放科学（资源服务）标识码（OSID）：
互联网数据中心（IDC）报告指出，2012 年全球已经开始进入大数据时代，并在2013 年全面引爆大数据。大数据，最具有代表性的是其“4V”的特点：Volume-數据规模大;Velocity-数据的产生速度很快，处理速度快;Variety-多样性，包括各种不同的类型和编码格式，数据类型繁多;Veracity-真实性，只有真准确的数据才使得对数据的分析有意义。在移动互联大数据时代，用户要求有更好的网络体验，基本需求是能在任意时间、任意地点通过移动指端移动终端接入网络，既是移动大数据的产生者，又是移动大数据的使用者，因此大数据服务一方面将推动管道技术演进，另一方面也推动移动终端的技术演进。
1移动大数据的特性
移动互联大数据导致移动终端从功能型移动终端向智能型移动终端。作为移动大数据的重要输入输出者，用户通过智能移动终端使用移动应用程序，产生各种与用户消费、出行以及娱乐等与生活密切相关的海量数据，这些海量数据如果完全存储在中心服务器上，会导致中心服务器负载过大，网络交互过于频繁，因此利用智能移动终端进行数据存储及性能优化，不仅能够减轻中心服务器端的数据存储及运算负担，还能充分发挥智能移动终端的硬件性能，特别是在离线情况下，通过缓存在智能移动终端的应用数据，仍能为用户及时地提供部分应用服务。移动互联大数据具有以下特性：
1.1 时空性
智能移动终端都具备GPS定位功能，因此数据的时空特性是移动大数据固有的鲜明特征。即使智能移动终端关闭了GPS定位服务功能，仍然可以通过基站位置粗略地推断出用户的位置。多维时空数据包含用户行动信息，在基于位置服务的智能打车、智能驾驶、网络商城、游戏、社交网络等各种应用中具有广泛的潜力。
1.2 个人定制性
从智能移动终端产生的数据始终包含用户身份信息。这些数据通常具有高度个人定制性。通过对这些包含个人信息的移动大数据进行分析和预测，预测出用户的个人行为偏好和习惯，通过专业的推荐系统，为每个用户提供精准的个人定制化服务。如浏览器个性推荐功能，网上购物个性推荐服务等。当然，任何事物都具有双面性，如果移动数据保密性不够，导致用户个人信息泄露，将在很大程度上侵犯用户的隐私并导致用户的生命财产受到侵害，因此数据安全性和保密性值得引起重视。
1.3 实时性
移动互联网的一个典型需求是应用程序服务端需要实时地向用户提供数据交互和服务，即数据必须具有实时性。如网络游戏、社交通讯、智能打车、金融 等应用程序，如果不能实现数据的实时交互，不仅影响用户体验，而且会造成用户的信息交流的延误和财产损失。然而，移动应用服务器端如果承担所有数据的存储、处理和分发，受硬件设备计算能力、存储空间和网络带宽的限制，难以满足海量数据的实时交互需求。因此，充分利用智能移动终端的计算能力和存储空间，存储一部分移动数据，减轻服务器端和网络带宽的负载，是一种可行且高效的解决方案。
2主流大数据框架和技术
为了存储和处理海量大数据，很多企业和高校开发了多种大数据处理框架和平台，主流的框架和技术包括：MapReduce、GFS、BigTable、Spark和Hadoop等技术。
2.1 Hadoop框架
Hadoop是一个包含开源代码的分布式文件系统和一个并行处理的MapReduce框架。HDFS为海量数据提供存储服务，而MapReduce则为海量数据提供计算引擎。HDFS设计思想有以下几点：1）在数据中心，硬件异常应被视作常态;2）流式数据访问：满足批处理而不是交互式处理需求;3）HDFS设计的重点是支持大文件;4）HDFS提供的访问模型是一次写入多次读取的简单数据一致性模型;5）移动计算优于移动数据：读取和计算采取就近原则;6）兼容各种硬件和软件平台。HDFS有其缺陷，不适合的场景包括：1）大量小文件;2）低延迟数据访问;3）多用户写入。
2.2 分布式文件系统HDFS
其中，HDFS为海量数据提供存储服务，而MapReduce则为海量数据提供计算引擎。HDFS设计思想有以下几点：1）在数据中心，硬件异常应被视作常态;2）流式数据访问：满足批处理而不是交互式处理需求;3）HDFS设计的重点是支持大文件;4）HDFS提供的访问模型是一次写入多次读取的简单数据一致性模型;5）移动计算优于移动数据：读取和计算采取就近原则;6）兼容各种硬件和软件平台。HDFS有其缺陷，不适合的场景包括：1）大量小文件;2）低延迟数据访问;3）多用户写入。
2.3 MapReduce模型
MapReduce是Google公司的核心计算模型，它将复杂的运行于大规模集群上的并行计算过程高度地抽象到两个函数：Map和Reduce。这两个函数由用户负责实现，功能是按一定的映射规则将输入的<key，value>对转换成另一个或一批<key，value>对输出。MapReduce的基本运行流程包括：1）作业启动;2）作业初始化;3）作业、任务调度;4）Map任务执行;5）shuffle;Reduce任务执行;7）作业完成。MapReduce作为分布式并行计算框架，主要由JobClient、JobTracker、TaskTracker等组件构成。核心设计思想：分而治之、分合结合、衔接有序、就近处理、可靠容错。 MapReduce的目标是解决海量数据的并行计算问题。它屏蔽了分布式计算框架的细节，将计算高度抽象成map和reduce两函数，其中map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。reduce则对中间结果中相同“键”的所有“值”进行合并，以得到最终结果。
2.4 Spark框架
Spark是在2009年由加州大学伯克利分校的AMPLab开发，提供了一个全面、统一的框架，用于大数据处理的需求。Spark的架构中的基本组件包括：Cluster Manager、Worker、Driver、Executor、SparkContext、RDD、DAG Scheduler、TaskScheduler以及SparkEnv。Spark的运行流程如下：
1）构建Spark Application的运行环境，启动SparkContext;
2）SparkContext向资源管理器（可以是Standalone，Mesos，Yarn）申请运行Executor资源，并启动StandaloneExecutorbackend;
3）Executor向SparkContext申请Task;
4）SparkContext将应用程序分发给Executor;
5）SparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给Task Scheduler，最后由Task Scheduler将Task发送给Executor运行;
6）Task在Executor上运行，运行完释放所有资源。
Spark与Hadoop相比，有如下差异：1）Spark与Hadoop有两个核心模块，分布式存储模块HDFS和分布式计算模块MapReduce;2）Spark本身并没有提供分布式文件系统，因此Spark的分析大多依赖于Hadoop的分布式文件系统HDFS;3）相比于MapReduce，Spark的速度更快并且提供的功能更加丰富。
尽管国内外学者在服务器端大数据存储、大数据处理、数据集共享方面开展了一些研究，并取得了很多研究成果，但是基于移动终端的数据存储，特别是基于移动终端的大数据存储及优化问题，迄今未见有相关报道。
本文将研究移动终端大数据的文件存储技术，以电子邮件和短彩信消息的文件存储为实例，提出了一种移动终端大数据环境下的索引文件偏移量存储算法，实现精确控制读写数据正确位置，避免了重写所有数据，极大减少IO操作负担，提升移动终端大数据读写操作性能，提出移动终端大数据环境下多级索引存储算法，移动终端具体数据和相对位置分离即索引头和位置关系分开存储，实现移动终端环境下大数据存储索引有序。构建一个移动终端通用、高性能、可推广存储模型，充分发挥移动终端性能，有效减轻服务端数据存储、运算负担，降低移动终端和服务器端不必要的數据交互。
3消息文件的存储设计
移动终端大数据环境下，移动终端中一个消息文件不能是一维扁平的存储，因为这样会极大降低海量消息文件的操作性能。因此，我们将消息文件的结构设计成三种组成部分，包括消息体、消息头和消息头索引，如图1所示。其中：
1）消息体：包括消息的具体内容，该部分数据量较大不需要频繁操作和访问。
2）消息头：包括各种消息的头信息：如主题，发件人，收件人，时间等内容，这部分被划分出来的依据为，该项内容会被频繁使用，比如消息列表需要展现该部分数据，并且需要列表告诉滑动，就要求获取数据迅速。
3）消息头索引：该部分为最高层结构，提取出了各个消息之间的相对位置，维护了各种位置序列。
3.1 消息管理方法
移动终端大数据环境下，消息文件管理主要通过系统中维护的几条链表实现，包括：索引头链表、消息头链表和空闲消息头链表，如图2所示。
其中，索引头链表维护消息的前后顺序，比如：时间，状态顺序等，序列化为索引头文件;消息头链表维护着有效消息的头结点，空闲消息头链表维护着无效消息的头结点，两条链表序列化为消息头文件，如果需要删除一条消息，则从消息头链表中移除一个结点，放入空闲消息头链表，如果增加一条消息，则首先在空闲消息头链表中寻找是否有空闲结点，若找到转化为有效结点并加入有效消息头链表中。
3.2消息链表管理方法
由于消息包含不同状态，并且对应着不同的业务逻辑，因此会产生大量链表管理起来非常麻烦，因此消息链表也需要管理起来，这里使用单例模式维护唯一链表指针，并使用工厂模式进行管理，用户只需输入key值便能得到对应链表头指针，无须知道构造细节。而各链表常驻内存，使用惰性初始化，当第一次被使用时进行初始化。
由于消息模块箱子较多，消息数量也较多，一直常驻内存对于某些内存较小低端机负担较大，因此也需要定期置换出部分不使用的链表以释放内存。
3.3 链表管理置换算法—LRU算法
LRU（Least Recently Used）即最近最久未使用页面置换算法，算法的思路就是认为最久未使用链表为最不常用的链表，因此优先级最低将其置换出去，从而换入新的链表进入。
在这里我们的具体算法为：（1）将所有链表头指针存于一个链表管理器中（使用链表实现）;（2）每次新请求对应key值的链表头，则先在管理链表中寻找是否存在，若存在直接返回，若不存在则添加入对应Key值的链表头入该链表管理器中;（3）添加新链表时候需要检查是否超过管理器最大上限，若超过最大上限，则置换出链表管理器末尾最后一个最老链表，并释放掉该链表头指针指向的整条链表。
3.4海量消息文件存储的操作原理
海量消息文件存储中，包括几个重要操作的原理及流程，如：消息增加、消息删除、消息加载等。 1） 消息新增管理
对于新增消息需要找到合适的位置插入且生成有效id号，首先寻找对应的空闲消息头链表是否有空闲结点，若有则摘取一个转到有效链表中，并在对应位置写入消息记录，若无则获得链表最大结点数加1后得到新的id号，然后把生成的新结点添加到链表恰当位置处，具体流程如图3所示。
2） 海量消息文件删除的原理
对于删除操作并不真正将消息记录从文件系统中直接清除掉，而是在对应记录中写入无效标示，这样只需要找到适当位置写入少量字节即可。
看起来每删除一条消息，仿佛在索引文件上挖一个坑，然后用空闲链表idleList将这些坑串联起来，如果新来一条消息，就优先把这样的坑分给它。
3） 消息装载原理
消息文件的装载过程即为一个反序列化过程，从文件系统读取各种数据和关系，转化为数据结构供上层使用的过程。
此为存储的一个反过程，读取分为有序读取和无序读取，如果无序读取只需要加载索引文件，而读取有序消息索引则需要首先读取索引头文件，获得索引头结点，再查询索引结点组装成完整的索引结点信息。
4结论
向单个智能移动终端存储分别存储1000和5000条消息，每存储一条打印出该条消息存储消耗时间，这样可横向可以比较随着消息的增多，性能衰减情况，纵向可以比较新旧两种方式的效率。采用本文提出的文件存储操作方法，与整个消息文件存储的方法进行比对，结果本文提出的文件存儲操作方法在总体时间消耗比后者低，并且操作效率与测试数据规模的相关性低，而第二种方式会随着数据规模增加，效率急剧衰减。
新方案由于实现了性能对数据规模的依赖相关性，因此在时间消耗上不会随着数据规模增加而增加，提升了还是消息文件的存储和操作性能。但其仍存在一些待改进的地方，如在文件系统中增删消息会在多个文件中读写，因此如果在中途发生意外就容易形成数据破坏，而这多个操作是原子的，需要事务来保证，因此在设计的时候需要加入对事务的考虑，若一个事务未来完成，需要进行回滚处理。移动互联大数据环境下，移动终端数据急剧增长，导致网络出现延迟和丢包现象，服务器 端超负荷运行。研究移动终端大数据存储，可提升移动软件应用性能及用户体验质量移动，降低服务器端存储和运算数据量，充分发挥移动终端硬件性能。因此，如何存储这些数量骤升的移动终端数据将成为企业和学术界的研究热点。
参考文献
[1] 陈博，顾旻霞.移动终端HTML5Web应用技术与标准[J].电信网技术，2012（5）：5-9.
[2] Ghemawat S，Gobioff H，Leung S T.The Google file system[C]//Proceedings of the nineteenth ACM symposium on Operating systems principles - SOSP '03.October 19-22，2003.Bolton Landing，NY，USA.New York：ACM Press，2003：29-43.
[3] ZhongL Z，WangB Z，WangZ Y，et al.Research and application of massive data processing technology[C]//20138th International Conference on Computer Science & Education.April26-28，2013，Colombo，SriLanka.IEEE，2013：829-833.
[4] Kaushik R T，Bhandarkar M，Nahrstedt K.Evaluation and analysis of GreenHDFS：a self-adaptive，energy-conserving variant of the hadoop distributed file system[C]//2010 IEEE SecondInternational Conference on Cloud Computing Technology and Science.November30 - December3，2010，Indianapolis，IN，USA.IEEE，2010：274-287.
【通联编辑：朱宝贵】