CN108319654A - 计算系统、冷热数据分离方法及装置、计算机可读存储介质 - Google Patents

计算系统、冷热数据分离方法及装置、计算机可读存储介质 Download PDF

Info

Publication number
CN108319654A
CN108319654A CN201711482651.9A CN201711482651A CN108319654A CN 108319654 A CN108319654 A CN 108319654A CN 201711482651 A CN201711482651 A CN 201711482651A CN 108319654 A CN108319654 A CN 108319654A
Authority
CN
China
Prior art keywords
business datum
database
cold
data
full dose
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.)
Granted
Application number
CN201711482651.9A
Other languages
English (en)
Other versions
CN108319654B (zh
Inventor
廉烨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Priority to CN201711482651.9A priority Critical patent/CN108319654B/zh
Publication of CN108319654A publication Critical patent/CN108319654A/zh
Application granted granted Critical
Publication of CN108319654B publication Critical patent/CN108319654B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2272—Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24568—Data stream processing; Continuous queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明涉及计算系统、冷热数据分离方法及装置、计算机可读存储介质。所述冷热数据分离方法是计算系统中的冷热数据分离方法，所述计算系统包括第一数据库和第二数据库，所述方法的特征在于，包括：提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据的步骤，其中所述第一数据库中的热业务数据被存储在内存中；将所提取的所述全量业务数据导入至所述第二数据库的步骤，其中所述第二数据库中的所述全量业务数据被存储在磁盘中；以及基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的步骤。

Description

计算系统、冷热数据分离方法及装置、计算机可读存储介质
技术领域
本发明属于数据存储领域，涉及计算系统、冷热数据分离方法及装置、计算机可读存储介质。
背景技术
在项目使用中，为了满足高并发的业务场景，常常使用Redis（REmote DIctionaryServer，远程字典服务器）数据库来进行数据存储。Redis数据库是一种速度非常快的高性能的key-value（键-值）数据库并且是基于内存的数据结构存储开源系统，采用C语言编写，数据存在内存中，运行效率极高。因其高性能和可持久化的特点，Redis数据库的使用非常流行。
当使用Redis数据库来存储全量业务数据时，虽然其读写速度快，但是也具有很多缺点：
1）随着业务扩展，业务数据量不断增加，Redis的内存消耗情况不容小觑，成本较为昂贵；
2）在开启持久化功能时，内存的瞬间占用成倍增长，并且磁盘IO异常繁忙，可能导致短暂时间内的读写超时；
3）一旦服务器宕机或进程遭误杀，内存中的数据将全部（未开启持久化功能）或部分（开启持久化功能）丢失。
为了应对内存的过大消耗，也常常使用SSDB（Sequence Similarity DataBase，序列相似性数据库）来进行数据存储。SSDB是一种支持Redis协议的NoSQL数据库并且是基于硬盘存储的，容易扩展。
尽管SSDB数据库能够存储十亿级别列表数据，但是在实际应用中存在以下问题：
1）使用Google的LevelDB作为存储引擎，SSDB的有序列表zset（sorted set，有序集合）是依赖LevelDB按key进行排序的特性实现的，效率较低；
2）LevelDB具有很高的随机写、顺序读/写性能，但是随机读的性能很一般，即，LevelDB不适合应用在读取/查询较多而写入/修改较少的场景中；
3）SSDB在执行删除命令时内存和磁盘不会即时释放，需要等到压缩时才会释放；
4）在某些条件被触发时，SSDB会通过compaction（压缩）命令对已有的记录进行整理压缩来删除掉一些不再有效的KV数据，从而减小数据规模、减少文件数量等，而压缩操作会耗费较多资源（CPU（Central Processing Unit，中央处理单元）、内存），因此在高并发的情况下，压缩操作的发生时机无法预知，资源使用情况不可控；
5）读取记录比较复杂，需要在内存以及各个层级文件中依照新鲜程度依次查找，代价很高。
发明内容
本发明是为了克服上述缺点的一个或多个、或其它缺点而完成的，所采用的技术方案如下。
根据本发明的一个方面，提供一种计算系统，包括：第一数据库，其对应的数据为包括热业务数据和冷业务数据的全量业务数据中的所述热业务数据，并且该热业务数据被存储在内存中；第二数据库，其对应的数据为所述全量业务数据，并且该全量业务数据被存储在磁盘中；全量数据转移组件，其被配置成提取所述全量业务数据并将其导入至所述第二数据库；以及冷业务数据淘汰组件，其被配置成基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以得到所述第一数据库中的所述热业务数据。
进一步地，在根据本发明的一个方面中，还包括：数据恢复组件，其被配置成从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库。
进一步地，在根据本发明的一个方面中，所述全量数据转移组件经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
进一步地，在根据本发明的一个方面中，在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的一个方面中，在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的一个方面中，所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
进一步地，在根据本发明的一个方面中，所述全量业务数据的数据结构为zset并且每一项业务数据以具有key（键）、value（值）、score（分数）这三种值的方式被存储，所述计算系统还包括：联合索引计算组件，其被配置成对全量业务数据中的每一项业务数据的value进行MD5（Message Digest algorithm 5，信息摘要算法5）运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。
根据本发明的另一个方面，提供一种计算系统，包括：内存，在其中存储包括热业务数据和冷业务数据的全量业务数据中的所述热业务数据；磁盘，在其中存储所述全量业务数据；全量数据转移组件，其被配置成提取所述全量业务数据并将其导入至所述磁盘；以及冷业务数据淘汰组件，其被配置成基于预先确定的淘汰机制将导入至所述磁盘之前的所述全量业务数据中的所述冷业务数据删除以得到所述内存中存储的所述热业务数据。
进一步地，在根据本发明的另一个方面中，还包括：数据恢复组件，其被配置成从所述磁盘中提取所需的所述冷业务数据并将其导入至所述内存。
进一步地，在根据本发明的另一个方面中，所述全量数据转移组件经由Kafka队列来提取所述全量业务数据并将其导入至所述磁盘。
进一步地，在根据本发明的另一个方面中，在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的另一个方面中，在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的另一个方面中，所述全量业务数据的数据结构为Redis数据库所支持的zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，所述计算系统还包括：联合索引计算组件，其被配置成对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。
根据本发明的又一个方面，提供一种计算系统中的冷热数据分离方法，所述计算系统包括第一数据库和第二数据库，所述方法包括：提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据的步骤，其中所述第一数据库中的热业务数据被存储在内存中；将所提取的所述全量业务数据导入至所述第二数据库的步骤，其中所述第二数据库中的所述全量业务数据被存储在磁盘中；以及基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的步骤。
进一步地，在根据本发明的又一个方面中，还包括：从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库的步骤。
进一步地，在根据本发明的又一个方面中，在所述提取全量业务数据的步骤中，经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
进一步地，在根据本发明的又一个方面中，在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的又一个方面中，在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的又一个方面中，所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
进一步地，在根据本发明的又一个方面中，所述全量业务数据的数据结构为zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，所述冷热数据分离方法还包括：对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引的步骤。
根据本发明的再一个方面，提供一种计算系统中的冷热数据分离装置，所述计算系统包括第一数据库和第二数据库，所述装置包括：提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据的单元，其中所述第一数据库中的业务数据被存储在内存中；将所提取的所述全量业务数据导入至所述第二数据库的单元，其中所述第二数据库中的业务数据被存储在磁盘中；以及基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的单元。
进一步地，在根据本发明的再一个方面中，还包括：从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库的单元。
进一步地，在根据本发明的再一个方面中，在所述提取全量业务数据的单元中，经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
进一步地，在根据本发明的再一个方面中，在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的再一个方面中，在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
进一步地，在根据本发明的再一个方面中，所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
进一步地，在根据本发明的再一个方面中，所述全量业务数据的数据结构为zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，所述冷热数据分离装置还包括：对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引的单元。
根据本发明的又再一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被计算机执行以实现根据本发明的又一个方面的冷热数据分离方法的步骤。
根据本发明的一个方面，提供一种数据读取方法，所述方法包括以下步骤：判断在所述Redis数据库中是否存在需要读取的业务数据所对应的key；在判断为不存在的情况下，判断是否为快速查询；在判断为不是快速查询的情况下，执行以下操作：根据所述需要读取的业务数据所对应的key来确定所述需要读取的业务数据位于所述MySQL数据库中的哪一张数据表；对所述需要读取的业务数据的value进行MD5运算以获得对应的联合索引；在所确定的数据表中利用所述联合索引来查询所述需要读取的业务数据；从所述MySQL数据库中提取所述需要读取的业务数据；以及将所提取的业务数据导入至所述Redis数据库。
根据本发明的一个方面，提供一种数据读入方法，所述方法包括以下步骤：判断在所述Redis数据库中是否存在待写入的业务数据所对应的key；在判断为不存在的情况下，执行以下操作：在所述MySQL数据库中查询与所述待写入的业务数据所对应的key相关的所有项业务数据；从所述MySQL数据库中提取所述所有项业务数据；将所提取的所述所有项业务数据导入至所述Redis数据库；以及将所述待写入的业务数据插入在所述Redis数据库中所述所有项数据所位于的位置处。
进一步地，在根据本发明的一个方面中，在将所述待写入的业务数据插入到所述Redis数据库中时，对该业务数据设置有效期。
相对于现有技术，本发明可以获得如下有益效果的一个或多个：
1）根据本发明，使用磁盘存储较久未访问的冷数据，节约海量内存，降低成本；
2）根据本发明，由Redis数据库和MySQL数据库构成的缓存层的实现对应用层透明，有助于应用层专注实现业务逻辑；
3）根据本发明，使用Kafka队列作为异步写MySQL的消息队列，能够很好地处理活跃的流式数据，保证写操作的准确性；
4）根据本发明，读性能因热数据命中率上升而显著变优，当命中率达到一定程度时，读写性能几乎不受MySQL数据库影响；
5）根据本发明，将zset中的key和进行MD5运算后的value建立成联合索引，提高了冷数据的访问速度；
6）根据本发明，适合于读操作频繁而写操作相对少的应用场景。
附图说明
图1是根据本发明的一个实施方式的计算系统的示例框图。
图2是根据本发明的一个实施方式的图1所示的计算系统中的数据读取方法的示例流程图。
图3是根据本发明的一个实施方式的图1所示的计算系统中的数据写入方法的示例流程图。
图4是根据本发明的一个实施方式的冷热数据分离方法的示例流程图。
图5是根据本发明的一个实施方式的冷热数据分离装置的示例框图。
具体实施方式
以下将结合附图对本发明涉及的计算系统、冷热数据分离方法及装置、计算机可读存储介质、数据读取方法、数据写入方法作进一步的详细描述。需要注意的是，以下的具体实施方式是示例性而非限制的，其旨在提供对本发明的基本了解，并不旨在确认本发明的关键或决定性的要素或限定所要保护的范围。
下文参考本发明实施例的方法和装置的框图说明、框图和/或流程图来描述本发明。将理解这些流程图说明和/或框图的每个框、以及流程图说明和/或框图的组合可以由计算机程序指令来实现。可以将这些计算机程序指令提供给通用计算机、专用计算机或其它可编程数据处理设备的处理器以构成机器，以便由计算机或其它可编程数据处理设备的处理器执行的这些指令创建用于实施这些流程图和/或框和/或一个或多个流程框图中指定的功能/操作的部件。
可以将这些计算机程序指令存储在计算机可读存储器中，这些指令可以指示计算机或其它可编程处理器以特定方式实现功能，以便存储在计算机可读存储器中的这些指令构成包含实施流程图和/或框图的一个或多个框中指定的功能/操作的指令部件的制作产品。
可以将这些计算机程序指令加载到计算机或其它可编程数据处理器上以使一系列的操作步骤在计算机或其它可编程处理器上执行，以便构成计算机实现的进程，以使计算机或其它可编程数据处理器上执行的这些指令提供用于实施此流程图和/或框图的一个或多个框中指定的功能或操作的步骤。还应该注意在一些备选实现中，框中所示的功能/操作可以不按流程图所示的次序来发生。例如，依次示出的两个框实际可以基本同时地执行或这些框有时可以按逆序执行，具体取决于所涉及的功能/操作。
图1是根据本发明的一个实施方式的计算系统的示例框图。如图1所示，该计算系统10可以包括内存11，在所述内存11中存储有第一数据库的数据，在一个实施例中，所述第一数据库的数据为包括热业务数据和冷业务数据的全量业务数据中的所述热业务数据。
如图1所示，该计算系统10还可以包括磁盘12，在所述磁盘12中存储有第二数据库的数据，在一个实施例中，所述第二数据库的数据为上述全量业务数据。
需要说明的是，在本文的上下文中，术语“冷业务数据”是指较长时间未被访问/使用的业务数据，术语“热业务数据”是指被频繁访问/使用的业务数据，术语“全量业务数据”是包括冷业务数据和热业务数据这两者的业务数据集合。
此外，需要说明的是，尽管第一数据库的除业务数据以外的信息（诸如控制数据）可以存储在内存11之外且第二数据库的除业务数据以外的信息（诸如控制数据）可以存储在磁盘12之外，但是，在本发明的一个实施方式中，第一数据库整体和第二数据库整体均被包括在该计算系统10中。
如图1所示，该计算系统10还可以包括全量数据转移组件13，其被配置成提取全量业务数据并将其导入至第二数据库。
在一个示例中，全量数据转移组件13可以是多线程worker并且可以经由Kafka队列来提取所述全量业务数据并将其导入至第二数据库。具体地，例如，该计算系统10调用Kafka异步写入接口API将所述全量数据异步插入到Kafka消息队列中，多线程worker一次性从Kafka消息队列中读出多条消息并将它们批量导入至第二数据库。
如图1所示，该计算系统10还可以包括冷业务数据淘汰组件14，其被配置成基于预先确定的淘汰机制将导入至第二数据库之前的全量业务数据中的冷业务数据删除以得到第一数据库中的所述热业务数据。
在一个实施例中，在导入至第二数据库之前的业务数据未被进行数据的增删改查操作的调用方设置有效期的情况下，可以周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
可替换地，在导入至第二数据库之前的全量业务数据均未被进行数据的增删改查操作的调用方设置有效期的情况下，也可以响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
在另一个实施例中，在导入至第二数据库之前的业务数据被进行数据的增删改查操作的调用方设置有效期的情况下，可以使用例如第一数据库自带的淘汰机制将过期的业务数据作为所述冷业务数据删除。
此外，在一个实施例中，可以在第一数据库中原始存储有全量业务数据，全量数据转移组件13从所述第一数据库提取所述全量业务数据并将其导入至第二数据库，进而冷业务数据淘汰组件14将所述第一数据库中存储的全量业务数据中的冷业务数据删除以使得仅热业务数据被存储在所述第一数据库中。
可替换地，在另一个实施例中，可以在第一数据库和第二数据库以外的第三方数据库中原始存储有全量业务数据，全量数据转移组件13从所述第三方数据库提取所述全量业务数据并将其导入至第二数据库，进而冷业务数据淘汰组件14将所述第三方数据库中存储的全量业务数据中的冷业务数据删除以便向所述第一数据库仅提供所述全量业务数据中的热业务数据进行存储。
可选地，如图1所示，该计算系统10还可以包括数据恢复组件15，其被配置成从第二数据库中提取所需的冷业务数据并将其导入至所述第一数据库。在一个实施例中，当在第一数据库的热业务数据中不存在业务操作相关的业务数据时，可以从第二数据库的全量业务数据中提取所需的冷业务数据并将其插入回第一数据库。
接下来，以第一数据库采用Redis数据库和第二数据库采用MySQL数据库为例来说明根据本发明的一个实施方式的计算系统。
Redis数据库支持五种数据结构，即，string（字符串）、list（链表）、set（集合）、hash（哈希类型）和zset（sorted set，有序集合）。例如，在Redis数据库采用zset数据结构时，每一项业务数据以具有key、value、score这三种值的方式被存储，其中，不同项业务数据key可以相同，即，在Redis数据库中，一个key可以对应多对value-score并且可以按照score的大小进行排序，由此，在Redis数据库和对应的MySQL数据库中，一个key和一个value可以确定唯一一条数据记录（一项业务数据）并且不同的数据记录（不同项业务数据）可以按照score的大小进行排序。
在一个示例中，在Redis数据库中的每一项业务数据对应于一个终端设备的信息，在Redis数据库采用zset数据结构时，key例如是DEVINFO:D006004655f21249c2a68e2ee85edbe2fcc520171114145519576，该key例如对应5个value，并且value值可以是一个终端设备的json串，score可以是该终端设备的信息的采集时间戳。
如上所述，在一个实施例中，可以在Redis数据库中原始存储有全量业务数据，全量数据转移组件13从Redis数据库提取所述全量业务数据并将其导入至MySQL数据库。在这种情况下，可以对Redis数据库中的所有主节点进行模糊匹配的扫描操作（scan match），获得所有需要导出的key，进而进行zrange操作以获得每一个key对应的所有对value-score，进而对每一个key进行MySQL分表的哈希运算来确定该key与MySQL数据库中的数据表的对应关系，进而以key为最小单元将Redis数据库的所有zset数据导入至MySQL数据库，其中，Redis数据库中的每一项业务数据的key、value、score对应于MySQL数据库中的sql文件的条目rds_key、value、score（如下表1所示）。
<表1>
由于value的长度并无限制，为了提高在MySQL数据库中的查询效率，可选地，在一个实施例中，该计算系统10还可以包括：联合索引计算组件（未示出），其被配置成对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。进而，在以key为最小单位将Redis数据库的所有zset数据导入至MySQL数据库时，将所述联合索引与每一项业务数据的key、value、score一起导入至MySQL数据库。
如上所述，在一个实施例中，可以在Redis数据库中原始存储有全量业务数据，全量数据转移组件13从所述Redis数据库提取所述全量业务数据并将其导入至MySQL数据库，进而冷业务数据淘汰组件14将所述Redis数据库中存储的全量业务数据中的冷业务数据删除以使得仅热业务数据被存储在所述Redis数据库中。
如果在导入至MySQL数据库之前的业务数据未被进行数据的增删改查操作的调用方设置有效期的情况下，可以设置一个固定的过期时间，并且可以周期性地执行serverCron函数、进而触发执行activeExpireCycle函数来检查是否存在在预先设置的过期时间内未被访问的key，如果存在，则以key为最小单位将该key对应的所有项业务数据作为所述冷业务数据删除（即，定时删除方案）；可替换地，也可以在所有读写命令执行之前通过expireIfNeeded函数对所涉及的业务数据的key进行检查，如果该key已经过期，则以key为最小单位将该key对应的所有项业务数据作为所述冷业务数据删除，并按照该key已不存在的方式进行下一步处理（即，惰性删除方案）。
相对地，如果在导入至MySQL数据库之前的业务数据已经被进行数据的增删改查操作的调用方设置有效期的情况下，可以通过设置例如Redis数据库自带的maxmemory-policy来选择一种LRU（Least Recently Used，最近最少使用）方式对较长时间未被访问的key所对应的所有项业务数据作为所述冷业务数据进行删除。LRU方式被列举如下：
1）noeviction：不进行置换，表示即使内存达到上限也不进行置换，所有能引起内存增加的命令都会返回error；
2）allkeys-lru：优先删除最近最不经常使用的key，用以保存新数据；
3）volatile-lru：只从设置失效的key中选择最近最不经常使用的key进行删除，用以保存新数据；
4）allkeys-random：随机从所有key中选择一些key进行删除，用以保存新数据；
5）volatile-random：只从设置失效的key中选择一些key进行删除，用以保存新数据；
6）volatile-ttl：只从设置失效的key中选出存活时间（TTL）最短的key进行删除，用以保存新数据。
接下来，结合图2和图3来说明图1所示的计算系统10中的数据读取方法和数据写入方法。
图2是根据本发明的一个实施方式的图1所示的计算系统10中的数据读取方法的示例流程图。
当有数据读取请求时，计算系统10的应用层调用缓存层（Redis数据库和MySQL数据库）对外服务接口来接收该数据读取请求，响应于此，如图2所示，计算系统10判断在Redis数据库中是否存在需要读取的业务数据所对应的key（步骤S201）。
在判断为存在的情况下，应用层直接从Redis数据库读取所需要的业务数据（步骤S202）。
另一方面，在判断为不存在的情况下，计算系统10判断本次读取查询是否为快速查询（步骤S203）。
在判断为是快速查询的情况下，直接返回Redis数据库中不存在所需数据的查询结果（步骤S204）。
另一方面，在判断为不是快速查询的情况下，可以执行以下操作：
根据所述需要读取的业务数据所对应的key来确定所述需要读取的业务数据位于MySQL数据库中的哪一张数据表（步骤S205）；
对所述需要读取的业务数据的value进行MD5运算以获得对应的联合索引（步骤S206）；
在所确定的数据表中利用所述联合索引来查询所述需要读取的业务数据（步骤S207）；
从所述MySQL数据库中提取所述需要读取的业务数据（步骤S208）；以及
将所提取的业务数据导入至所述Redis数据库（步骤S209）。
进而，应用层可以从Redis数据库读取所需要的业务数据。
图3是根据本发明的一个实施方式的图1所示的计算系统10中的数据写入方法的示例流程图。
当有数据写入请求时，计算系统10的应用层调用缓存层（Redis数据库和MySQL数据库）对外服务接口来接收该数据写入请求，响应于此，如图3所示，计算系统10判断在Redis数据库中是否存在待写入的业务数据所对应的key（步骤S301）。
在判断为存在的情况下，应用层直接将数据写入至Redis数据库中的上述key所位于的位置处（步骤S302）。
另一方面，在判断为不存在的情况下，可以执行以下操作：
在MySQL数据库中查询与待写入的业务数据所对应的key相关的所有项业务数据（步骤S303）；
从MySQL数据库中提取上述所有项业务数据（步骤S304）；
将所提取的上述所有项业务数据导入至所述Redis数据库（步骤S305）；以及
将待写入的业务数据插入在Redis数据库中上述所有项数据所位于的位置处（步骤S306）。
进而，可以按照上文描述的方式根据需要和访问频度将Redis数据库中的业务数据备份至MySQL数据库、然后将Redis数据库中的冷业务数据剔除以便在Redis数据库中仅存储热业务数据。
可选地，在一个实施例中，可以在将待写入的业务数据插入到Redis数据库中时进行数据的增删改查操作的调用方可以对该业务数据设置有效期。
接下来，将结合图4来说明根据本发明的一个实施方式的冷热数据分离方法。
该冷热数据分离方法S100适用于包括第一数据库和第二数据库的计算系统，其中所述第一数据库中的业务数据被存储在内存中，而所述第二数据库中的业务数据被存储在磁盘中。
如图2所示，该冷热数据分离方法S100包括如下步骤：提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据（步骤S101）。在一个示例中，可以经由Kafka队列来提取所述全量业务数据。具体地，例如，计算系统调用Kafka异步写入接口将所述全量数据异步插入到Kafka消息队列中，进而一次性从Kafka消息队列中读出多条消息并将它们批量导入至第二数据库。
进一步地，在一个实施例中，该冷热数据分离方法S100还可以包括如下步骤：将所提取的所述全量业务数据导入至所述第二数据库（步骤S102）。
进一步地，在一个实施例中，该冷热数据分离方法S100还可以包括如下步骤：基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据（步骤S103）。
在一个实施例中，在导入至第二数据库之前的业务数据未被进行数据的增删改查操作的调用方设置有效期的情况下，可以周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
可替换地，在导入至第二数据库之前的全量业务数据均未被进行数据的增删改查操作的调用方设置有效期的情况下，也可以响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
在另一个实施例中，在导入至第二数据库之前的业务数据被进行数据的增删改查操作的调用方设置有效期的情况下，可以使用例如第一数据库自带的淘汰机制将过期的业务数据作为所述冷业务数据删除。
可选地，在一个实施例中，该冷热数据分离方法S100还可以包括如下步骤：从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库。在一个实施例中，当在第一数据库的热业务数据中不存在业务操作相关的业务数据时，可以从第二数据库的全量业务数据中提取所需的冷业务数据并将其插入回第一数据库。
在一个示例中，上述第一数据库可以是Redis数据库，而上述第二数据库可以是MySQL数据库。进而，在该示例中，全量业务数据的数据结构可以是zset并且每一项业务数据以具有key、value、score这三种值的方式被存储。关于该示例的细节和操作，与前文说明的相同，因此不再赘述。相对应地，为了提高在MySQL数据库中的查询效率，可选地，在一个实施例中，该冷热数据分离方法S100还可以包括：对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。进而，在以key为最小单位将Redis数据库的所有zset数据导入至MySQL数据库时，将所述联合索引与每一项业务数据的key、value、score一起导入至MySQL数据库。
最后，结合图5来说明根据本发明的一个实施方式的冷热数据分离装置。
该冷热数据分离装置100适用于包括第一数据库和第二数据库的计算系统，其中所述第一数据库中的业务数据被存储在内存中，而所述第二数据库中的业务数据被存储在磁盘中。
如图5所示，该冷热数据分离装置100包括提取单元101，其用于提取第一数据库中的包括冷业务数据和热业务数据的全量业务数据。在一个示例中，提取单元101可以经由Kafka队列来提取所述全量业务数据。具体地，例如，计算系统调用Kafka异步写入接口API将所述全量数据异步插入到Kafka消息队列中，提取单元101一次性从Kafka消息队列中读出多条消息并将它们批量导入至第二数据库。
进一步地，该冷热数据分离装置100还可以包括导入单元102，其用于将所提取的所述全量业务数据导入至所述第二数据库。
进一步地，该冷热数据分离装置100还可以包括删除单元103，其用于基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的单元。
在一个实施例中，在导入至第二数据库之前的业务数据未被进行数据的增删改查操作的调用方设置有效期的情况下，可以周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
可替换地，在导入至第二数据库之前的全量业务数据均未被进行数据的增删改查操作的调用方设置有效期的情况下，也可以响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
在另一个实施例中，在导入至第二数据库之前的业务数据被进行数据的增删改查操作的调用方设置有效期的情况下，可以使用例如第一数据库自带的淘汰机制将过期的业务数据作为所述冷业务数据删除。
可选地，在一个实施例中，该冷热数据分离装置100还可以包括从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库的单元。在一个实施例中，当在第一数据库的热业务数据中不存在业务操作相关的业务数据时，可以从第二数据库的全量业务数据中提取所需的冷业务数据并将其插入回第一数据库。
在一个示例中，上述第一数据库可以是Redis数据库，而上述第二数据库可以是MySQL数据库。进而，在该示例中，全量业务数据的数据结构可以是zset并且每一项业务数据以具有key、value、score这三种值的方式被存储。关于该示例的细节和操作，与前文说明的相同，因此不再赘述。相对应地，为了提高在MySQL数据库中的查询效率，可选地，在一个实施例中，该冷热数据分离装置100还可以包括对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引的单元。进而，在以key为最小单位将Redis数据库的所有zset数据导入至MySQL数据库时，将所述联合索引与每一项业务数据的key、value、score一起导入至MySQL数据库。
虽然在此之前以计算系统、冷热数据分离方法及装置的实施方式为中心进行了说明，但是本发明不限定于这些实施方式，也可以将本发明实施为以下方式：用于执行上述方法的计算机设备或者用于执行上述方法的计算机程序的方式或者用于实现上述装置的功能的计算机程序的方式或者记录有该计算机程序的计算机可读取的记录介质的方式。
如上所述，本发明也可以被实施为一种计算机可读存储介质，在其中存储有用于使计算机执行图2中所示的冷热数据分离方法的程序。
在此，作为计算机可读存储介质，能采用盘类（例如，磁盘、光盘等）、卡类（例如，存储卡、光卡等）、半导体存储器类（例如，ROM、非易失性存储器等）、带类（例如，磁带、盒式磁带等）等各种方式的记录介质。
通过在这些计算机可读存储介质中记录使计算机执行上述实施方式中的冷热数据分离方法的计算机程序或使计算机实现上述实施方式中的冷热数据分离装置的功能的计算机程序并使其流通，从而能使成本的低廉化以及可携带性、通用性提高。
而且，在计算机上装载上述计算机可读存储介质，由计算机读出在记录介质中记录的计算机程序并储存在存储器中，计算机所具备的处理器（CPU：Central ProcessingUnit（中央处理单元）、MPU：Micro Processing Unit（微处理单元））从存储器读出该计算机程序并执行，由此，能执行上述实施方式中的冷热数据分离方法并能实现上述实施方式中的冷热数据分离装置的功能。
本领域普通技术人员应当了解，本发明不限定于上述的实施方式，本发明可以在不偏离其主旨与范围内以许多其它的形式实施。因此，所展示的示例与实施方式被视为示意性的而非限制性的，在不脱离如所附各权利要求所定义的本发明精神及范围的情况下，本发明可能涵盖各种的修改与替换。

Claims (31)

1.一种计算系统，其特征在于，包括：
第一数据库，其对应的数据为包括热业务数据和冷业务数据的全量业务数据中的所述热业务数据，并且该热业务数据被存储在内存中；
第二数据库，其对应的数据为所述全量业务数据，并且该全量业务数据被存储在磁盘中；
全量数据转移组件，其被配置成提取所述全量业务数据并将其导入至所述第二数据库；以及
冷业务数据淘汰组件，其被配置成基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以得到所述第一数据库中的所述热业务数据。
2.根据权利要求1所述的计算系统，其特征在于，还包括：
数据恢复组件，其被配置成从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库。
3.根据权利要求1所述的计算系统，其特征在于，
所述全量数据转移组件经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
4.根据权利要求1至3的任一项所述的计算系统，其特征在于，
在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
5.根据权利要求1至3的任一项所述的计算系统，其特征在于，
在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
6.根据权利要求1至3的任一项所述的计算系统，其特征在于，
所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
7.根据权利要求6所述的计算系统，其特征在于，
所述全量业务数据的数据结构为zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，
所述计算系统还包括：联合索引计算组件，其被配置成对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。
8.一种计算系统，其特征在于，包括：
内存，在其中存储包括热业务数据和冷业务数据的全量业务数据中的所述热业务数据；
磁盘，在其中存储所述全量业务数据；
全量数据转移组件，其被配置成提取所述全量业务数据并将其导入至所述磁盘；以及
冷业务数据淘汰组件，其被配置成基于预先确定的淘汰机制将导入至所述磁盘之前的所述全量业务数据中的所述冷业务数据删除以得到所述内存中存储的所述热业务数据。
9.根据权利要求8所述的计算系统，其特征在于，还包括：
数据恢复组件，其被配置成从所述磁盘中提取所需的所述冷业务数据并将其导入至所述内存。
10.根据权利要求8所述的计算系统，其特征在于，
所述全量数据转移组件经由Kafka队列来提取所述全量业务数据并将其导入至所述磁盘。
11.根据权利要求7至9的任一项所述的计算系统，其特征在于，
在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
12.根据权利要求7至9的任一项所述的计算系统，其特征在于，
在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
13.根据权利要求7至9的任一项所述的计算系统，其特征在于，
所述全量业务数据的数据结构为Redis数据库所支持的zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，
所述计算系统还包括：联合索引计算组件，其被配置成对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引。
14.一种计算系统中的冷热数据分离方法，所述计算系统包括第一数据库和第二数据库，所述方法的特征在于，包括：
提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据的步骤，其中所述第一数据库中的热业务数据被存储在内存中；
将所提取的所述全量业务数据导入至所述第二数据库的步骤，其中所述第二数据库中的所述全量业务数据被存储在磁盘中；以及
基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的步骤。
15.根据权利要求14所述的冷热数据分离方法，其特征在于，还包括：
从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库的步骤。
16.根据权利要求14所述的冷热数据分离方法，其特征在于，
在所述提取全量业务数据的步骤中，经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
17.根据权利要求14至16的任一项所述的冷热数据分离方法，其特征在于，
在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
18.根据权利要求14至16的任一项所述的冷热数据分离方法，其特征在于，
在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
19.根据权利要求14至16的任一项所述的冷热数据分离方法，其特征在于，
所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
20.根据权利要求19所述的冷热数据分离方法，其特征在于，
所述全量业务数据的数据结构为zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，
所述冷热数据分离方法还包括：对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引的步骤。
21.一种计算系统中的冷热数据分离装置，所述计算系统包括第一数据库和第二数据库，所述装置的特征在于，包括：
提取所述第一数据库中的包括冷业务数据和热业务数据的全量业务数据的单元，其中所述第一数据库中的业务数据被存储在内存中；
将所提取的所述全量业务数据导入至所述第二数据库的单元，其中所述第二数据库中的业务数据被存储在磁盘中；以及
基于预先确定的淘汰机制将导入至所述第二数据库之前的所述全量业务数据中的所述冷业务数据删除以在所述第一数据库中更新存储所述热业务数据的单元。
22.根据权利要求21所述的冷热数据分离装置，其特征在于，还包括：
从所述第二数据库中提取所需的所述冷业务数据并将其导入至所述第一数据库的单元。
23.根据权利要求21所述的冷热数据分离装置，其特征在于，
在所述提取全量业务数据的单元中，经由Kafka队列来提取所述全量业务数据并将其导入至所述第二数据库。
24.根据权利要求21至23的任一项所述的冷热数据分离装置，其特征在于，
在所述淘汰机制中，周期性地检查是否存在在预先设置的固定时间内未被访问的业务数据，如果存在，则将该业务数据作为所述冷业务数据删除。
25.根据权利要求21至23的任一项所述的冷热数据分离装置，其特征在于，
在所述淘汰机制中，响应于业务操作而检查该业务操作涉及的业务数据是否在预先设置的固定时间内未被访问，如果是，则将该业务数据作为所述冷业务数据删除。
26.根据权利要求21至23的任一项所述的冷热数据分离装置，其特征在于，
所述第一数据库是Redis数据库，所述第二数据库是MySQL数据库。
27.根据权利要求26所述的冷热数据分离装置，其特征在于，
所述全量业务数据的数据结构为zset并且每一项业务数据以具有key、value、score这三种值的方式被存储，
所述冷热数据分离装置还包括：对全量业务数据中的每一项业务数据的value进行MD5运算来获得该value对应的哈希值以便与对应的key一起作为数据读取用的联合索引的单元。
28.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被计算机执行以实现根据权利要求14至20的任一项所述的冷热数据分离方法的步骤。
29.一种如权利要求7所述的计算系统中的数据读取方法，所述方法的特征在于，包括以下步骤：
判断在所述Redis数据库中是否存在需要读取的业务数据所对应的key；
在判断为不存在的情况下，判断是否为快速查询；
在判断为不是快速查询的情况下，执行以下操作：
根据所述需要读取的业务数据所对应的key来确定所述需要读取的业务数据位于所述MySQL数据库中的哪一张数据表；
对所述需要读取的业务数据的value进行MD5运算以获得对应的联合索引；
在所确定的数据表中利用所述联合索引来查询所述需要读取的业务数据；
从所述MySQL数据库中提取所述需要读取的业务数据；以及
将所提取的业务数据导入至所述Redis数据库。
30.一种如权利要求7所述的计算系统中的数据读入方法，所述方法的特征在于，包括以下步骤：
判断在所述Redis数据库中是否存在待写入的业务数据所对应的key；
在判断为不存在的情况下，执行以下操作：
在所述MySQL数据库中查询与所述待写入的业务数据所对应的key相关的所有项业务数据；
从所述MySQL数据库中提取所述所有项业务数据；
将所提取的所述所有项业务数据导入至所述Redis数据库；以及
将所述待写入的业务数据插入在所述Redis数据库中所述所有项数据所位于的位置处。
31.根据权利要求30所述的数据读入方法，其特征在于，
在将所述待写入的业务数据插入到所述Redis数据库中时，对该业务数据设置有效期。
CN201711482651.9A 2017-12-29 2017-12-29 计算系统、冷热数据分离方法及装置、计算机可读存储介质 Active CN108319654B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711482651.9A CN108319654B (zh) 2017-12-29 2017-12-29 计算系统、冷热数据分离方法及装置、计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711482651.9A CN108319654B (zh) 2017-12-29 2017-12-29 计算系统、冷热数据分离方法及装置、计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN108319654A true CN108319654A (zh) 2018-07-24
CN108319654B CN108319654B (zh) 2021-12-21

Family

ID=62893484

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711482651.9A Active CN108319654B (zh) 2017-12-29 2017-12-29 计算系统、冷热数据分离方法及装置、计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN108319654B (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299115A (zh) * 2018-11-30 2019-02-01 北京锐安科技有限公司 一种数据存储方法、装置、服务器及存储介质
CN109684416A (zh) * 2018-11-13 2019-04-26 国电南京自动化股份有限公司 一种高并发实时历史数据存储系统
CN109739913A (zh) * 2018-12-24 2019-05-10 北京明朝万达科技股份有限公司 一种基于可配置化的热点数据缓存处理方法及设备
CN109828987A (zh) * 2019-01-21 2019-05-31 深圳乐信软件技术有限公司 一种千万级数据计算方法、装置、电子设备和介质
CN109871367A (zh) * 2019-02-28 2019-06-11 江苏实达迪美数据处理有限公司 一种基于Redis和HBase的分布式冷热数据分离方法
CN109933575A (zh) * 2019-02-28 2019-06-25 鲁东大学 监测数据的存储方法及装置
CN110032571A (zh) * 2019-04-18 2019-07-19 腾讯科技（深圳）有限公司 业务流程处理方法、装置、存储介质及计算设备
CN111914126A (zh) * 2020-07-22 2020-11-10 浙江乾冠信息安全研究院有限公司 用于索引的网络安全大数据的处理方法、设备及存储介质
CN112883124A (zh) * 2021-03-17 2021-06-01 重庆紫光华山智安科技有限公司 数据处理方法、装置、计算机设备及存储介质
CN112950345A (zh) * 2021-03-05 2021-06-11 北京健康之家科技有限公司 业财数据处理方法、装置及计算机设备
CN113051271A (zh) * 2021-03-26 2021-06-29 郑州阿帕斯数云信息科技有限公司 一种冷热数据分离方法、装置及其设备
CN113138987A (zh) * 2021-04-28 2021-07-20 深圳软牛科技有限公司 基于内存数据的数据处理方法和相关设备
CN113177036A (zh) * 2021-04-14 2021-07-27 中国电力工程顾问集团中南电力设计院有限公司 一种监测数据的存储方法、查询方法、显示方法
CN113448966A (zh) * 2021-07-17 2021-09-28 绿漫科技有限公司 一种订单类数据多维度分表系统
CN114077609A (zh) * 2022-01-19 2022-02-22 北京四维纵横数据技术有限公司 数据存储及检索方法，装置，计算机可读存储介质及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103049393A (zh) * 2012-10-23 2013-04-17 北京奇虎科技有限公司 内存空间管理方法和装置
CN103092920A (zh) * 2012-12-26 2013-05-08 新浪网技术(中国)有限公司 半结构化数据的存储方法及存储系统
CN104468641A (zh) * 2013-09-12 2015-03-25 腾讯科技（深圳）有限公司 一种业务数据迁移方法、装置和云存储系统
CN104731794A (zh) * 2013-12-19 2015-06-24 北京华易互动科技有限公司 一种冷热数据分片挖掘存储方法
CN105117180A (zh) * 2015-09-28 2015-12-02 联想(北京)有限公司 一种数据存储方法和装置以及固态硬盘
CN107368436A (zh) * 2017-06-29 2017-11-21 西安交通大学 一种联合地址映射表的闪存冷热数据分离存储方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103049393A (zh) * 2012-10-23 2013-04-17 北京奇虎科技有限公司 内存空间管理方法和装置
CN103092920A (zh) * 2012-12-26 2013-05-08 新浪网技术(中国)有限公司 半结构化数据的存储方法及存储系统
CN104468641A (zh) * 2013-09-12 2015-03-25 腾讯科技（深圳）有限公司 一种业务数据迁移方法、装置和云存储系统
CN104731794A (zh) * 2013-12-19 2015-06-24 北京华易互动科技有限公司 一种冷热数据分片挖掘存储方法
CN105117180A (zh) * 2015-09-28 2015-12-02 联想(北京)有限公司 一种数据存储方法和装置以及固态硬盘
CN107368436A (zh) * 2017-06-29 2017-11-21 西安交通大学 一种联合地址映射表的闪存冷热数据分离存储方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
梁力源: "基于NoSQL存储系统的研究与应用", 《中国优秀硕士学位论文全文数据库信息科级辑》 *
樊重俊等: "《大数据分析与应用》", 31 January 2016 *
董守斌等: "《网络信息检索》", 30 April 2010 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109684416A (zh) * 2018-11-13 2019-04-26 国电南京自动化股份有限公司 一种高并发实时历史数据存储系统
CN109299115A (zh) * 2018-11-30 2019-02-01 北京锐安科技有限公司 一种数据存储方法、装置、服务器及存储介质
CN109739913A (zh) * 2018-12-24 2019-05-10 北京明朝万达科技股份有限公司 一种基于可配置化的热点数据缓存处理方法及设备
CN109828987A (zh) * 2019-01-21 2019-05-31 深圳乐信软件技术有限公司 一种千万级数据计算方法、装置、电子设备和介质
CN109933575B (zh) * 2019-02-28 2021-04-27 鲁东大学 监测数据的存储方法及装置
CN109933575A (zh) * 2019-02-28 2019-06-25 鲁东大学 监测数据的存储方法及装置
CN109871367A (zh) * 2019-02-28 2019-06-11 江苏实达迪美数据处理有限公司 一种基于Redis和HBase的分布式冷热数据分离方法
CN110032571A (zh) * 2019-04-18 2019-07-19 腾讯科技（深圳）有限公司 业务流程处理方法、装置、存储介质及计算设备
CN111914126A (zh) * 2020-07-22 2020-11-10 浙江乾冠信息安全研究院有限公司 用于索引的网络安全大数据的处理方法、设备及存储介质
CN112950345A (zh) * 2021-03-05 2021-06-11 北京健康之家科技有限公司 业财数据处理方法、装置及计算机设备
CN112883124A (zh) * 2021-03-17 2021-06-01 重庆紫光华山智安科技有限公司 数据处理方法、装置、计算机设备及存储介质
CN113051271A (zh) * 2021-03-26 2021-06-29 郑州阿帕斯数云信息科技有限公司 一种冷热数据分离方法、装置及其设备
CN113051271B (zh) * 2021-03-26 2024-01-19 郑州阿帕斯数云信息科技有限公司 一种冷热数据分离方法、装置及其设备
CN113177036A (zh) * 2021-04-14 2021-07-27 中国电力工程顾问集团中南电力设计院有限公司 一种监测数据的存储方法、查询方法、显示方法
CN113138987A (zh) * 2021-04-28 2021-07-20 深圳软牛科技有限公司 基于内存数据的数据处理方法和相关设备
CN113448966A (zh) * 2021-07-17 2021-09-28 绿漫科技有限公司 一种订单类数据多维度分表系统
CN113448966B (zh) * 2021-07-17 2022-06-21 绿漫科技有限公司 一种订单类数据多维度分表系统
CN114077609A (zh) * 2022-01-19 2022-02-22 北京四维纵横数据技术有限公司 数据存储及检索方法，装置，计算机可读存储介质及电子设备

Also Published As

Publication number Publication date
CN108319654B (zh) 2021-12-21

Similar Documents

Publication Publication Date Title
CN108319654A (zh) 计算系统、冷热数据分离方法及装置、计算机可读存储介质
KR102226257B1 (ko) 서비스 데이터를 블록체인 시스템에 기입하기 위한 방법 및 디바이스
CN107038206B (zh) Lsm树的建立方法、lsm树的数据读取方法和服务器
CN103064639B (zh) 数据存储方法及装置
CN104156380B (zh) 一种分布式存储器哈希索引方法及系统
US20160350302A1 (en) Dynamically splitting a range of a node in a distributed hash table
CN108009008A (zh) 数据处理方法和系统、电子设备
US10725907B2 (en) Information processing apparatus for specifying data region of garbage collection, information processing system and information processing method
CN103500089A (zh) 一种适应于Mapreduce计算模型的小文件存储系统
CN106980665A (zh) 数据字典实现方法、装置及数据字典管理系统
WO2013075306A1 (zh) 数据访问方法和装置
CN109614055A (zh) 快照创建方法、装置、电子设备及机器可读存储介质
CN109684271A (zh) 快照数据管理方法、装置、电子设备及机器可读存储介质
CN107798063A (zh) 快照处理方法和快照处理装置
CN106844491B (zh) 一种临时数据的写入、读取方法及写入、读取装置
US20140320498A1 (en) Terminal device, information processing method, and computer program product
CN110187834A (zh) 重删副本的数据处理方法、装置、电子设备
CN109446258A (zh) 一种分布式数据存储方法及系统
US11010091B2 (en) Multi-tier storage
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
CN112711564A (zh) 合并处理方法以及相关设备
US10698865B2 (en) Management of B-tree leaf nodes with variable size values
CN107846327A (zh) 一种网管性能数据的处理方法及装置
US8977814B1 (en) Information lifecycle management for binding content
CN111435331B (zh) 存储卷写数据方法、装置、电子设备及机器可读存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant