CN111639076B - 一种跨平台高效键值存储方法 - Google Patents

Abstract

本发明提供了一种跨平台高效键值存储方法，涉及键值存储技术领域，能够既保证数据准确性，又对内存、空间占用以及读取效率方面进行优化，具有更好的性能；该方法所述方法采用紧凑型数据结构对数据进行存储，以避免数据冗余；存储数据时直接以二进制形式写入数据库文件中，以减少文件占用空间；内存对数据进行读取时采用键值哈希索引+偏移量的方式进行缓存，实现对内存的节省；采用文件锁的方式解决多进程数据并发安全问题。本发明提供的技术方案适用于键值存储和增删改查的过程中。

Description

一种跨平台高效键值存储方法

【技术领域】

本发明涉及键值存储技术领域，尤其涉及一种跨平台高效键值存储方法。

【背景技术】

在程序的开发过程中，无论什么平台，比较常见的一种需求就是持久化的存储键值对。以Android端为例，持久化存储时存在几个问题：

1.初始化消耗问题：SharedPreferences在初始化时会将文件中的所有数据都遍历一遍，并加载到hashmap中，当数据量较大时，这对性能的消耗和内存的占用都是非常巨大的；

2.增删改查效率问题：以Android端为例，可以使用SharedPreferences来进行键值对的存储；但SharedPreferences是以标准的XML格式来存储key-value的，为了文件的可读性，增加了一些冗余的字符。因此，其增删改查的效率相对较低；

3.并发操作数据一致性问题：在SharedPreferences非单例的情况下，其存储数据的时候并不是线程安全的，需要在调用函数时进行一些线程安全的操作，较为繁琐；

4.进程间同步问题(Android独有)：当Android应用内开启了多个进程时，存储key-value的数据同步问题更为突出，原生并没有提供任何类似问题的完整解决方案。

因此，有必要研究一种跨平台高效键值存储方法来应对现有技术的不足，以解决或减轻上述一个或多个问题。

【发明内容】

有鉴于此，本发明提供了一种跨平台高效键值存储方法，既保证了数据准确性，又在空间和时间方面进行了优化，具有更好的性能。

一方面，本发明提供一种跨平台高效键值存储方法，其特征在于，所述方法采用紧凑型数据结构对数据进行存储，以避免数据冗余；存储数据时直接以二进制形式写入数据库文件中，以减少文件占用空间；内存对数据进行读取时采用键值哈希索引+偏移量的方式进行缓存，实现对内存的节省。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，紧凑型数据结构的格式具体为：

|value|key|valueLen|keyLen|keyHash|valueHash|valueType|，

其中，valueType代表数据类型和是否为有效数据，占用8bit，keyHash表示键值哈希值，占用32bit，也用作该数据在索引中的哈希值，valueHash表示value的哈希值，占用8bit，用于保证数据的完整性，keyLen表示键值长度，占用10bit，valueLen表示值的长度，另外keyLen和valueLen表示偏移量；

每条数据之间头尾相连，没有分隔符。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，keyLen代表的长度范围为0-1023。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对数据库文件中的数据进行插入和更新操作时，在索引列表中遍历待操作数据的键值哈希值；

如果存在相同的键值哈希值，则判定为更新逻辑，将原有数据的数据类型标记为已删除，并在数据库文件的末尾增加新的数据，生成新的内存索引；

如果不存在相同的键值哈希值，则判定为插入逻辑，直接在数据库文件的末尾增加新的数据，生成新的内存索引。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对数据库文件中的数据进行删除操作时，通过键值哈希值在索引列表中查找要删除的数据；

当不存在相应的数据时，直接返回删除成功；

当存在相应的数据时，将该数据的数据类型标记为已删除，并在索引列表中删除对应的索引。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对数据库文件中的数据进行查询操作时，通过键值哈希值用倒叙的方式在索引列表中查找待操作数据对应的键值哈希值，以判断数据库文件中是否存在该数据；

当不存在该数据时，向使用者返回该数据不存在；

当存在该数据时，向使用者返回该数据。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，将数据类型标记为已删除时，并未真正删除数据库文件中的相应数据，为了避免造成文件冗余，在冗余数据条数达到预设阈值时或者数据库文件的大小达到规定大小时，触发数据库文件整理操作，删除标记为已删除的数据。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，冗余数据条数达到预设阈值具体为：现有冗余数据条数不小于数据库允许的冗余数据条数的50％。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，数据库文件大小达到规定大小具体为：数据库文件的大小不小于500k。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，对每一个数据库文件设置文件锁，当一个进程请求对某一数据库文件进行操作时，先获取该文件的文件锁；

若当前没有其他进程对该数据库文件进行操作，则可以获取到文件锁，并对数据库文件进行操作；

若当前有其他进程正在对该数据库文件进行操作，则无法获取文件锁，使用者进入等待或者放弃本次请求。

另一方面，本发明提供一种存储介质，存储有软件程序，其特征在于，运行时能够实现如上任一所述的跨平台高效键值存储方法的内容。

与现有技术相比，本发明可以获得包括以下技术效果：本发明采用紧凑型存储二进制数据的方式，有效提高增删改查的效率并解决数据冗余的问题；采用文件锁对数据库文件进行标识，避免多进程同时对同一文件进行操作，造成数据不安全的问题；采用键值哈希值+偏移量的方式进行缓存，无需将key和value读入内存中，起到有效节省内存的作用。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有技术效果。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明一个实施例提供的跨平台高效键值存储解决方案的原理图。

【具体实施方式】

为了更好的理解本发明的技术方案，下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

针对现有技术的不足，本发明提供了一套完整和周密的解决方案，在保证数据准确性的同时，对空间和时间两方面分别做了优化，完成了一个可商用的跨平台高效键值存储解决方案。本发明的方法可以跨平台使用，可以在Android端、iOS端、PC端同时使用，而无需做其他修改或额外工作。

本发明跨平台高效键值存储解决方案，做了以下方面的优化：

1.内存方面

在内存优化方面，本申请使用的是hash索引+偏移量的方案替代了内存缓存方案。原因有二，第一点是由于key-value的具体值存在不确定性，容易引起运行时内存不可预期的增长。而使用hash索引+偏移量的方法，可以有效避免这个问题，因为hash和偏移量的字节数都是固定的，占用内存非常小，大大降低了初始化时占用的内存资源，即便是超大的数据量，其在内存方面的表现也远远优于内存缓存。第二点，常用的数据库，如mysql，同样使用的是索引的方式，但通常使用的并不是hash索引，而是B+树，这是因为B+树的查询时间较为稳定，而hash索引，一旦数据量变大，hash碰撞较多，查询效率就会降低。由于我们的kv存储基本是在移动端使用，数据量较小，几乎不会hash碰撞，通常情况下，时间复杂度可以认为是O(1)，因此采用hash索引的方式是最好的。

2.数据格式

为了避免数据冗余，本发明采用的是紧凑型的存储方式，按照|value|key|valueLen|keyLen|keyHash|valueHash|valueType|的规则，即“值”，“键”，“值长度”，“键长度”，“键哈希值”，“值哈希值”，“值类型”，将这些数据依次写入文件，这些数据组成一个键值对的完整信息；同样的，在读取时，我们认为这样一组数据对应的是一个键值对。由于现实开发中很少有人去查看存储文件，因此我们选择直接向文件中写入二进制数据，虽然牺牲了可读性，但是去除了冗余的字符，减小文件占用空间，大大提高了执行效率。

3.读取方式

在读取数据时(读取指的是查询操作)，本发明采用倒叙读取法。即从文件的最后开始遍历，依次向前，这样做的好处是，由于我们插入数据时是不考虑之前是否存在的，所以在键一样的情况下，后面的值才是有效的。基于这个特点，从后向前遍历的效率是最高的，因为当我们读到key值相同时，key直接跳过value的读取，节省一次io的操作。如果采用前序遍历的方式，则必须将整个文件的数据全部遍历。

4.文件整理

在数据的写入和修改操作上，本发明采用的方案是：无论之前是否存在该值，都追加数据至文件的末尾。这样做的原因是，由于不需要考虑之前的数据，从而能够以磁盘空间占用为代价，极大的提升写入速度。为了精益求精，我们会在无效数据超过50％并且文件大小超过500k以后，对文件进行重整理，删除失效的数据，重排有效数据，从而达到节省磁盘空间、增加文件打开和读写速度等目的。

5.数据加密

本申请为使用者提供了chacha20的加密方式，使用者仅需要传入秘钥即可，我们会分别在写入和读取时对数据进行加密和解密的操作。同时，我们也提供了自定义加密的方式，如果开发者不喜欢使用自带的chacha20加密方式，可以选择自己加密，将加密后的数据传入，我们会对加密后的数据进行处理并同样以二进制的方式写入文件中，解密同理。

6.进程间的数据并发安全问题

这个问题是Android端独有的。当app开启了多个进程时，由于进程之间的内存无法共享，导致一个进程的操作，无法被另一个进程得知。本发明采用文件锁的方式来解决这个问题，对每一个文件设置一个文件锁，当一个进程针对该文件去操作数据时，首先尝试去获取文件锁，如果获取到了，说明没有其它进程正在修改数据，则可以安心进行增删改查操作。如果没有获取到，使用者可以选择等待，直到另一个进程释放了文件锁，或者选择放弃本次增删改查的操作。利用这种方式，可以解决进程间的数据并发安全问题，让数据安全有序的写入到内存和文件中。

本发明跨平台高效键值存储解决方案的工作步骤包括：

步骤一：初始化

初始化过程中，数据库会根据数据文件中已存在的数据生成索引，被标识为移除的数据不生成索引，索引存储在内存中，不单独形成文件。索引节点的形式为键值对数据中键值的哈希值和数据所在文件中相对于文件头的偏移量，为减少内存占用，keyHash采用32bit长度，offset使用64bit长度，索引采用红黑树结构，时间复杂度为O(logN)，经过测试，ffkv在启动速度和内存占用上对比竞品有一定的优势。另外，数据库文件与索引同步，数据库的增删改查都需要通过索引来实现，由于使用了索引机制，查找效率高，同时对于数据的修改，会通过mmap同步修改文件，mmap能够减少数据拷贝次数，提高文件读写效率，同时保证数据在异常状况下不丢失。

数据库初始化需要使用者提供数据库文件路径，该路径下没有文件时，会自动创建新的文件。数据库提供加密功能，默认为chacha20加密方式，同时支持使用者自定义加密，初始化时需要指定加密方式。

数据库文件结构经过优化设计，在保证数据可靠性的前提下减少空间占用，单个数据结构如下：

|value|key|valueLen|keyLen|keyHash|valueHash|valueType|，其中valueType代表存储数据的类型和是否为有效数据，占用8bit，keyHash表示键值hash值，占用32bit，valueHash表示value的hash值，占用8bit，keyLen表示键值长度，占用10bit，表示0-1023长度，能够覆盖大部分使用场景，valueLen表示值的长度，单个数据单元除去key和value之后一共88bit，11个字节，其中keyHash可以作为索引的哈希值，valueHash保证数据的完整，keyLen和valueLen表示长度，确定键值的存储位置，每条数据之间头尾相连，没有分隔符，进一步减少空间占用。

数据库支持多种数据格式存储，包括bool，float，double，int，long，string，二进制数据。

步骤二：插入和更新数据

首先对数据组成特定数据存储格式，在索引列表中查找键值哈希值，如果存在相同的键值，则认为是更新逻辑，将原有值标记为已删除，在文件末尾增加新的数据，生成新的内存索引，如果没有相同的键值，则认为是增加逻辑，在内存中生成新的索引，在文件末尾增加新的数据。

步骤三：删除数据

首先在索引列表中查找数据，当不存在键值数据时，直接返回删除成功，当存在键值时，将所在键值对的数据类型标记为移除，在索引列表中移除索引。

步骤四：查找数据

首先在索引列表中查找数据，当不存在键值数据时，告知使用者不存在，当存在键值时，将键值对应的数据返回给使用者。

步骤五：文件重整理

在删除和更新数据时，由于对数据只是做了标识，并没有真正的删除文件中的数据，一段时间后会形成文件冗余，在删除成功之后，数据库在满足数据库存文件冗余条数到达50％，并且数据库文件超过500k的情况下，触发数据库文件整理，将无效的数据删除。

本发明解决了这些问题。

1.针对增删改查效率不高和数据冗余的问题，我们采用的是紧凑型存储二进制数据的方式，每一个key-value都对应着一小组数据，这些以二进制的方式进行写入和读出，没有任何冗余的字符，不会额外占用空间，大幅度增加了读写的效率。

2.在多进程的并发数据安全方面，我们文件锁的方式，当一个进程准备修改数据之前，首先尝试获取文件锁，如果获取到，说明没有其它进程正在修改数据。在修改完数据以后，会释放文件锁，这样可以保证多进程间的数据并发时的安全问题，杜绝了不同进程同时修改同一个数据这一现象的发生。

3.初始化阻塞和内存问题。

在初始化时，我们采用的方案是缓存key的hash值和偏移量，并不会将真正的key和value读入到内存中，这样，每读一个数据就减少了一次读value的操作。另外，我们存储hash和偏移量，分别用固定的4字节和8字节来存储，这样，一定不会存在不确定性的内存增长问题，即便key或value的真实值占用内存非常大，我们也仅仅用12个字节就完成了对这个key-value的缓存，如果真正需要读这个值得时候，利用O(1)的时间复杂度即可找到真实的key-value，达到节省内存的目的。

4.遍历方式问题。

由于最新的数据都被追加到文件的末尾，因此我们读取时采用的遍历方式为后续遍历，一旦读取到已经存在的key时，将跳过当前key-value的读取环节，继续读取下一个key-value。当存在较多重复的key时，这种遍历方式可以大幅度增加读取效率。

5.文件重整理时机问题。

文件重整理的是一个耗时的工作。MMKV文件重整理内嵌在删除的操作中，一旦删除一组key，便会触发该操作，由于大多数开发者不会关心删除的具体工作，很可能在不经意间多次触发重整理函数，造成线程阻塞，内存消耗等问题。我们对这个时机做了优化，在数据的增删改查过程中，我们会记录无效数据的比例，一旦这个比例超过总数据量的50％，并且数据文件的大小超过500kb，才会触发重整理的工作。当达不到这个条件时，失效的数据不会对性能造成太大的影响，当达到这个条件时，我们会触发重整理的工作，删除失效数据，从而达到节省磁盘空间，增加文件打开和读写的效率。

本发明相对于现有的持久化存储技术具有的优势阐述：

现有的持久化存储技术，以Android为例，有原生的SharedPreferences，也有微信的开源项目MMKV，这两个技术各有缺点。

a、原生的SharedPreferences的缺点包括：

a.1、增删改查效率问题：原生的SharedPreferences使用的存储方式是xml，虽然具有很好的可读性，但是严重影响了读写效率。本发明采用的是紧凑型存储二进制数据的方式，每一个key-value都对应着一小组数据，索引采用红黑树结构，时间复杂度仅为O(logN)，大幅度增加了读写的效率。

a.2、数据冗余问题：xml格式需要一些特殊字符来实现，因此会导致数据冗余，增加磁盘占用空间。本发明使用的二进制存储方式直接意味着没有任何冗余的字符，不会额外占用空间，避免了数据冗余的问题。

a.3、多进程数据并发安全问题：原生并没有提供任何多进程并发相关的完整解决方案，并且现有的一些三方库的性能也不是很好。本发明使用文件锁的方式，当一个进程准备修改数据之前，首先尝试获取文件锁，如果获取到，说明没有其它进程正在修改数据；在修改完数据以后，会释放文件锁，这样可以保证多进程间的数据并发时的安全问题，杜绝了不同进程同时修改同一个数据这一现象的发生。

b、微信开源项目MMKV的缺点：

b.1、初始化阻塞问题：初始化时，MMKV将所有的key-value都加载到内存当中，一旦数据量十分庞大，加载这些数据的耗时将会很长，造成线程阻塞。在初始化时，本发明采用的方案是缓存key的hash值和偏移量，并不会将真正的key和value读入到内存中，这样，每读一个数据就减少了一次读value的操作。当数据较多时，本发明方案的优势十分明显。

b.2、内存问题：无论key-value是什么，MMKV都会加载到内存当中，这有可能会造成内存不可预期的增长问题，一旦使用者存储了内存占用庞大的value值，会给app造成内存紧张甚至内存溢出的风险。同时，加载所有的key-value，无非是为了读取速度加快，但是很有可能并不是所有的值都会被用到，因此这对内存资源是一种浪费。本发明存储hash和偏移量，分别用固定的4字节和8字节来存储，这样，一定不会存在不确定性的内存增长问题，即便key或value的真实值占用内存非常大，我们也仅仅用12个字节就完成了对这个key-value的缓存，如果真正需要读这个值得时候，利用O(1)的时间复杂度即可找到真实的key-value，达到节省内存的目的。

b.3、遍历方式：MMKV追加数据会追加到文件末尾，但是读取数据时是从前向后读的，这样，一旦key值有重复，后面的值会覆盖前面的值，也就是说前面的数据就白读取了，这会影响到读取的效率(由于最新的数据都被追加到文件的末尾，因此本发明读取时采用的遍历方式为后续遍历，一旦读取到已经存在的key时，将跳过当前key-value的读取环节，继续读取下一个key-value。当存在较多重复的key时，这种遍历方式可以大幅度增加读取效率。

b.4、整理文件的时机：当使用mmkv移除一组key的时候，会触发重整理文件的条件，从而开始一整套整理文件的流程。在频繁的删除时，这会对app造成阻塞、内存消耗过大等问题。文件重整理是一个耗时的工作。MMKV文件重整理内嵌在删除的操作中，一旦删除一组key，便会触发该操作，由于大多数开发者不会关心删除的具体工作，很可能在不经意间多次触发重整理函数，造成线程阻塞，内存消耗等问题。本发明对这个时机做了优化，在数据的增删改查过程中，本发明会记录无效数据的比例，一旦这个比例超过总数据量的50％，并且数据文件的大小超过500kb，才会触发重整理的工作；当达不到这个条件时，失效的数据不会对性能造成太大的影响，当达到这个条件时，会触发重整理的工作，删除失效数据，从而达到节省磁盘空间，增加文件打开和读写的效率。

本发明数据增删改查的方式，使得写入效率比原生快200多倍，与微信MMKV写入效率是同一数量级，但是内存占用要少50％左右。

b.5、数据存储格式采用紧凑型，是以|value|key|valueLen|keyLen|keyHash|valueHash|valueType|的格式来保存的，这种存储格式，没有任何的数据冗余，每个数据都有其自身的作用。valueType代表存储数据的类型和是否为有效数据，占用8bit，keyHash表示键值hash值，占用32bit，valueHash表示value的hash值，占用8bit，keyLen表示键值长度，占用10bit，表示0-1023长度，能够覆盖大部分使用场景，valueLen表示值的长度，单个数据单元除去key和value之后一共88bit，11个字节，其中keyHash可以作为索引的哈希值，valueHash保证数据的完整，keyLen和valueLen表示长度，确定键值的存储位置，每条数据之间头尾相连，没有分隔符，进一步减少空间占用。这种存储方式，能够保证读写速度与微信的MMKV是同一数量级，但是文件占用空间的大小仅仅是MMKV的60％。

以上对本申请实施例所提供的一种跨平台高效键值存储方法，进行了详细介绍。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

如在说明书及权利要求书当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求书并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求书当中所提及的“包含”、“包括”为一开放式用语，故应解释成“包含/包括但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求书所界定者为准。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求书的保护范围内。

Claims (7)

1.一种跨平台高效键值存储方法，其特征在于，所述方法采用紧凑型数据结构对数据进行存储，以避免数据冗余；存储数据时直接以二进制形式写入数据库文件中，以减少文件占用空间；内存对数据进行读取时采用键值哈希索引+偏移量的方式进行缓存，实现对内存的节省；

紧凑型数据结构的格式具体为：

|value|key|valueLen|keyLen|keyHash|valueHash|valueType|，

其中，valueType代表数据类型和是否为有效数据，占用8bit，keyHash表示键值哈希值，占用32bit，也用作该数据在索引中的哈希值，valueHash表示value的哈希值，占用8bit，用于保证数据的完整性，keyLen表示键值长度，占用10bit，valueLen表示值的长度，另外keyLen和valueLen表示偏移量；

存储hash和偏移量，分别用固定的4字节和8字节来存储；

每条数据之间头尾相连，无其他符号；对数据库文件中的数据进行插入和更新操作时，在索引列表中遍历待操作数据的键值哈希值；

如果存在相同的键值哈希值，则判定为更新逻辑，将原有数据的数据类型标记为已删除，并在数据库文件的末尾增加新的数据，生成新的内存索引；

如果不存在相同的键值哈希值，则判定为插入逻辑，直接在数据库文件的末尾增加新的数据，生成新的内存索引；

对数据库文件中的数据进行查询操作时，通过键值哈希值用倒叙的方式在索引列表中查找待操作数据对应的键值哈希值，以判断数据库文件中是否存在该数据；

当不存在该数据时，向使用者返回该数据不存在；

当存在该数据时，向使用者返回该数据。

2.根据权利要求1所述的跨平台高效键值存储方法，其特征在于，对数据库文件中的数据进行删除操作时，通过键值哈希值在索引列表中查找要删除的数据对应的键值哈希值，以判断数据库文件中是否存在该数据；

当不存在该数据时，直接返回删除成功；

当存在该数据时，将该数据的数据类型标记为已删除，并在索引列表中删除对应的索引。

3.根据权利要求1或2所述的跨平台高效键值存储方法，其特征在于，将数据类型标记为已删除时，并未真正删除数据库文件中的相应数据，为了避免造成文件冗余，在冗余数据条数达到预设阈值时或者数据库文件的大小达到规定大小时，触发数据库文件整理操作，删除标记为已删除的数据。

4.根据权利要求3所述的跨平台高效键值存储方法，其特征在于，冗余数据条数达到预设阈值具体为：现有冗余数据条数不小于数据库允许的冗余数据条数的50％。

5.根据权利要求3所述的跨平台高效键值存储方法，其特征在于，数据库文件大小达到规定大小具体为：数据库文件的大小不小于500k。

6.根据权利要求1所述的跨平台高效键值存储方法，其特征在于，对每一个数据库文件设置文件锁，当一个进程请求对某一数据库文件进行操作时，先获取该文件的文件锁；

若当前没有其他进程对该数据库文件进行操作，则可以获取到文件锁，并对数据库文件进行操作；

若当前有其他进程正在对该数据库文件进行操作，则无法获取文件锁，使用者进入等待或者放弃本次请求。

7.一种存储介质，存储有软件程序，其特征在于，运行时能够实现如权利要求1-6任一所述的跨平台高效键值存储方法的内容。