CN111581123A - 基于分类的存储器分配的锁定 - Google Patents

基于分类的存储器分配的锁定 Download PDF

Info

Publication number
CN111581123A
CN111581123A CN201911291410.5A CN201911291410A CN111581123A CN 111581123 A CN111581123 A CN 111581123A CN 201911291410 A CN201911291410 A CN 201911291410A CN 111581123 A CN111581123 A CN 111581123A
Authority
CN
China
Prior art keywords
data
memory
data object
memory pool
pool
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.)
Pending
Application number
CN201911291410.5A
Other languages
English (en)
Inventor
A.穆克吉
M.安德烈
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.)
SAP SE
Original Assignee
SAP SE
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 SAP SE filed Critical SAP SE
Publication of CN111581123A publication Critical patent/CN111581123A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0646—Configuration or reconfiguration
    • 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
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
    • 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
    • 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
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0685—Hybrid storage combining heterogeneous device types, e.g. hierarchical storage, hybrid arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/109—Address translation for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/16—General purpose computing application
    • G06F2212/163—Server or database system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory

Abstract

提供了一种用于改善数据库中的存储器管理的系统和方法。在一个示例中，该方法可以包括接收将数据对象存储在数据库内的请求，基于数据对象的属性从多个类别类型当中确定与数据对象相关联的类别类型，和经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储数据对象，其中该存储包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间换出到磁盘的第二存储器池。锁定的存储器池可以确保更重要的数据项即使在最近最少使用时仍然可用。

Description

基于分类的存储器分配的锁定
技术领域
本公开的实施例涉及基于分类的存储器分配的锁定。
背景技术
内存中(in-memory)数据库(例如，主存储器数据库等)是数据库管理系统，其依赖于用于计算机数据存储的主存储器(例如，随机存取存储器等)而不是仅仅依赖于硬盘。当数据库具有大的存储器库并且数据集大小合理时，内存中数据库可以很少或从未进入磁盘。然而，对于较大的数据集，内存中存储可能会变满，需要将数据交换到磁盘。通常，数据库经由最近最少使用(least recently used，LRU)的模型交换数据页，该模型考虑了自上次访问数据以来已经过去的时间量。在这种场景下，最近最少使用的数据(即最早的数据)被交换到磁盘。然而，LRU模型不考虑交换到磁盘的数据类型。因此，当重要数据被换出时，数据库的整体性能可能会降低，这需要在后续使用期间从磁盘加载数据。因此，需要一种用于确定需要换出哪些数据的改进机制。
发明内容
根据本公开的实施例，一种计算系统包括：处理器，被配置为接收将数据对象存储在数据库内的请求，并且基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和存储，被配置为经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，其中，所述处理器被配置为将第一类别类型的数据对象分配给锁定到所述存储中的主存储器的第一存储器池，并将第二类别类型的数据对象分配给所述存储中随时间被换出到磁盘的第二存储器池。
根据本公开的实施例，一种方法包括：接收将数据对象存储在数据库内的请求；基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，其中，所述存储包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
根据本公开的实施例，一种存储指令的非暂时性计算机可读介质，该指令在被执行时使得计算机执行方法，该方法包括：接收将数据对象存储在数据库内的请求；基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，其中，所述存储包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
附图说明
参考以下结合附图的详细描述，示例实施例的特征和优点以及实现这些特征和优点的方式将变得更加显而易见。
图1A是示出根据示例实施例的数据库系统架构的图。
图1B是示出根据示例实施例的用于与数据库系统一起使用的存储器系统架构的图。
图2是示出根据示例实施例的多类别内存中架构(multi-category in-memoryarchitecture)的图。
图3是示出根据示例实施例的多类别内存中架构的另一示例的图。
图4是示出根据示例实施例的从内存中架构换出数据的过程的图。
图5是示出根据示例性实施例的基于数据类别将数据分配给存储器的方法的图。
图6是示出根据示例性实施例的在本文示例中使用的计算系统的图。
在整个附图和详细描述中，除非另有说明，否则相同的附图标记将被理解为指代相同的元件、特征和结构。为了清楚、说明和/或方便，这些元件的相对大小和描述可以被放大或调整。
具体实施方式
在以下描述中，阐述了具体细节，以便提供对各种示例实施例的透彻理解。应当理解，对实施例的各种修改对于本领域技术人员来说将是显而易见的，并且在不脱离本公开的精神和范围的情况下，本文定义的一般原理可以应用于其他实施例和应用。此外，在以下描述中，出于解释的目的，阐述了许多细节。然而，本领域普通技术人员应该理解，可以在不使用这些具体细节的情况下实践实施例。在其他实例下，没有示出或描述众所周知的结构和过程，以免不必要的细节模糊描述。因此，本公开不旨在限于所示的实施例，而是符合与本文公开的原理和特征一致的最宽范围。
存储器管理控制计算机或虚拟机的存储器资源如何共享。对于数据库，存储器管理由操作系统执行。当数据库用完主存储器(即，随机存取存储器)时，操作系统可以将存储器页移至硬盘，以释放主存储器，用于存储来自其他过程的数据。数据的移动被称为存储器交换(memory swap)。过于依赖存储器到磁盘的交换会削弱数据库的性能，因为主存储器(例如，RAM)比磁盘存储器操作快得多。特别是，当交换页面时，操作系统必须等待磁盘跟上。此外，工作负载越依赖交换的文件，它对性能的负面影响就越大。
在数据库内高度存储器争用(high memory contention)的情况下，通常会基于先前的使用模式(诸如最近最少使用的模式)将主存储器中的数据页面交换到磁盘。在一些情况下，这种级别的复杂程度可能就足够了。然而，对于诸如内存中数据库的系统软件，换出更常用的数据可能导致性能显著下降。例如，存储在主存储器中的数据对象可能是最近最少使用的数据对象，因此即使最近使用了另一使用频率明显较低的数据对象，该最近最少使用的数据对象也要受到交换。然而，传统数据库无法区分两个数据对象之间可用性的重要性。相反，传统的数据库换出最近最少使用的数据库，而不管它对整个系统的重要性。
包括数据库表的大多数数据结构包括不同类别的存储器。例如，数据可以包括多版本并发控制(multiversion concurrency control，MVCC)数据、增量差分(delta)数据、字典数据、索引数据、主数据等。示例实施例结合存储器锁定方案实施数据分类，以将更重要的类别的数据固定(pin)在主存储器内，同时允许不太重要的类别的数据被交换到磁盘或另一中间形式的存储器，诸如固态磁盘(solid-state disk，SSD)、非易失性存储器快速(non-volatile memory express，NVMe)等。也就是说，数据库操作系统可以锁定主存储器内的某些类别的数据，以防止这些类别的数据被换出，而不是从主存储器中换出最近最少使用的页面。作为示例，数据类别可以包括更频繁地需要的数据，诸如MVCC数据、增量数据等。随着时间的推移，数据库可以学习这些数据类型，并且这些数据类型会因系统而异。通过将数据分类到重要性的层(tier)中，并基于这些层进行交换，操作系统的存储器管理的整体性能可以显著提高。
图1A示出了根据示例实施例的数据库100的系统架构。应当理解，实施例不限于架构100或不限于数据库架构，然而，出于示例的目的示出了图1A。参考图1A，架构100包括数据存储110、数据库管理系统(database management system，DBMS)120、服务器130、服务135、客户端140和应用145。通常，在服务器130内执行的服务135接收来自在客户端140上执行的应用145的请求，并基于存储在数据存储110内的数据向应用145提供结果。例如，服务器130可以执行服务135并向应用145提供服务135。服务135可以包括服务器侧(server-side)可执行程序代码(例如，编译代码、脚本等)，其通过向客户端140提供用户界面、从应用145接收请求(例如，拖放操作)、基于请求从数据存储110检索取得数据、处理从数据存储110接收的数据以及向应用145提供经处理的数据，来向应用145提供功能。
在一个非限制性示例中，客户端140可以执行应用145，以基于存储在数据存储110中的底层数据，经由显示在客户端140上的用户界面来执行视觉分析，以查看诸如图表、图形、表格等的分析信息。应用145可以基于经由客户端140接收的输入向服务135之一传递分析信息。可以基于请求生成结构化查询语言(structured query language，SQL)脚本，并将其转发给DBMS120。DBMS 120可以执行SQL脚本，以基于数据存储110的数据返回结果集，并且应用145基于结果集创建报告/可视化。作为另一示例，分析数据可以由用户输入，并从应用145直接提供给DBMS 120或数据存储110。
根据各种实施例，应用145和/或服务135可以用于标识和组合用于训练机器学习模型的特征。来自各种源的原始数据可以存储在数据存储110中。在该示例中，应用145和/或服务135可以从原始数据中提取核心特征，并且还可以从核心特征中导出特征。这些特征可以作为数据库表存储在数据存储110内。例如，特征可以被分配给它自己的具有一列或多列数据的表。在一个示例中，特征可以被观察为数值。此外，应用145和/或服务135可以基于垂直联合功能合并或以其他方式组合特征。在该示例中，应用145和/或服务135可以将来自多个数据库表的特征组合成单个表，然后将该单个表存储在数据存储110中。
在服务器130上执行的服务135可以使用数据库管理接口，诸如但不限于开放数据库连接(Open Database Connectivity，ODBC)和Java数据库连接(Java DatabaseConnectivity，JDBC)接口，来与DBMS 120通信。这些类型的服务135可以使用SQL和SQL脚本来管理和查询存储在数据存储110中的数据。DBMS 120服务于从存储在数据存储110中的数据库文件中查询、取得、创建、修改(更新)和/或删除数据的请求，并且还执行管理性(administrative)和管理功能。这些功能可以包括快照(snapshot)和备份管理、索引、优化、垃圾收集和/或任何其他已知的或变得已知的数据库功能。
服务器130可以与DBMS 120分离或紧密集成。紧密集成的服务器130可以完全在数据库平台上执行服务135，而不需要附加的服务器。例如，服务器130可以提供一组全面的嵌入式服务，这些服务为基于Web的应用提供端到端(end-to-end)支持。服务135可以包括轻量级web服务器、对开放数据协议的可配置支持、服务器侧JavaScript执行以及对SQL和SQLScript的访问。服务器130可以使用管理和查询存储在数据存储110中的数据库文件的服务135来提供应用服务(例如，经由功能库)。应用服务可用于向客户端140暴露数据库数据模型及其表、视图和数据库过程。除了暴露数据模型之外，服务器130可以托管诸如搜索服务等的系统服务。
数据存储110可以是已知的或变得已知的任何(多个)查询-响应数据源，包括但不限于SQL关系数据库管理系统。数据存储110可以包括关系数据库、多维数据库、可扩展标记语言(Extensible Markup Language，XML)文档或者存储结构化和/或非结构化数据的任何其他数据存储系统，或者与它们相关联。数据存储110的数据可以分布在几个关系数据库、维度数据库和/或其他数据源当中。实施例不限于任何数量或类型的数据源。
在一些实施例中，数据存储110的数据可以包括具有常规表格数据、基于行的数据、基于列的数据、基于对象的数据等中的一个或多个的文件。根据各个方面，文件可以是存储数据集的数据库表。此外，可以在索引中索引和/或选择性地复制数据，以允许对其进行快速搜索和取得。数据存储110可以支持多租户，以通过提供多个以编程方式彼此隔离的逻辑数据库系统来分别支持多个不相关的客户端。此外，数据存储110可以支持多个用户，这些用户与相同客户端相关联，并且共享对存储在数据存储110中的公共数据库文件的访问。
根据各种实施例，数据项(例如，数据记录、数据条目等)可以在数据存储110内被存储、修改、删除等。作为示例，可以基于来自任何应用145、服务135等的指令来创建、写入、修改或删除数据项。每个数据项可以由操作系统或数据库100的其他程序分配全球唯一标识符(globally unique identifier，GUID)。GUID用于从存储在数据库100内的所有其他数据项当中唯一地标识数据项。GUID可以以多个方式创建，包括但不限于随机的、基于时间的、基于硬件的、基于内容的、它们的组合等。
架构100可以包括定义映射到数据存储110的逻辑实体的对象的元数据。元数据可以存储在数据存储110和/或单独的储存库(未示出)中。元数据可以包括关于维度名称(例如，国家、年份、产品等)、维度层次结构(例如，国家、州、城市等)、度量名称(例如，利润、单位、销售等)和任何其他合适的元数据的信息。根据一些实施例，元数据包括关联用户、查询、查询模式和可视化的信息。信息可以在系统操作期间被收集，并且可以被用于响应于接收到的查询并基于查询和从其接收到查询的用户来确定要呈现的可视化。
每个客户端140可以包括执行应用145的程序代码的一个或多个设备，用于呈现用户界面以允许与应用服务器130交互。应用145的用户界面可以包括适合于报告、数据分析和/或基于数据存储110的数据的任何其他功能的用户界面。取决于由服务器130生成的用户界面代码的类型，用户界面的呈现可以包括任何程度或类型的渲染(render)。例如，客户端140可以执行Web浏览器，以经由HTTP、HTTPS协议和/或WebSocket从应用服务器130请求和接收Web页面(例如，以HTML格式)，并且可以根据已知协议渲染和呈现Web页面。
一个或多个客户端140还可以或可替换地通过在虚拟机内执行独立的可执行文件(例如.exe文件)或代码(例如，JAVAapplet)来呈现用户界面。客户端140可以执行应用145，应用145执行存储在数据存储110中的底层数据文件的合并操作。此外，客户端140可以执行本文描述的冲突解决方法和过程，以解决存储在数据存储110中的数据文件的不同版本之间的数据冲突。用户界面可用于显示底层数据记录等。
图1B示出了根据示例实施例的用于与数据库系统一起使用的存储器系统架构150。作为示例，架构150可以表示图1A所示的数据存储110的架构，然而，架构150不限于经由数据存储来实施，而是可以是包括在诸如内存中数据库的数据库内的另一存储器源或设备。数据库可以以存储器池(memory pool)的形式分配主存储器。根据各种实施例，每个存储器池可以与不同类别的数据相关联。在图1B的示例中，存储器池包括空闲池(free pool)151、数据库管理数据152、列表(column table)153、行表154和系统表155。架构150还可以包括过程的代码和堆栈156，该过程包括程序代码的副本和过程堆栈的副本。
数据库可以包括运行在操作环境中的过程。操作系统可能负责为所有过程保留存储器。当数据库启动时，操作系统可以为程序代码(有时称为文本)、程序堆栈以及代码和堆栈156中的静态数据保留存储器。当由SAPHANA存储器管理器请求时，操作系统可以动态地保留附加的数据存储器。动态分配的存储器包括堆存储器(heap memory)和共享存储器。内存中数据库可以仔细管理和跟踪其存储器的消耗。为此，数据库可以通过从操作系统请求存储器来管理其自己的数据存储器池，可能是在使用它之前。存储器池用于存储所有内存中数据和系统表、线程堆栈、临时计算以及管理数据库所需的所有其他数据结构。
列存储是数据库的一部分，其管理存储器中按列组织的数据。创建为列表153的表存储在这里。存储器架构150还包括用于附加存储的行表154和系统表155。列存储(其包括列表153)可以针对读取操作进行优化，但也针对写入操作提供良好的性能。这可以通过两种数据结构来实现，包括主存储和增量存储。主存储包含数据的主要部分。这里，高效的数据压缩被用于节省存储器和加速搜索和计算。然而，对主存储中的压缩数据进行写入操作将会很昂贵。因此，写入操作可能不会直接修改主存储中的压缩数据。相反，所有更改都可以写入被称为增量存储的独立数据结构。增量存储仅使用基本压缩，并且针对写入访问进行了优化。在这种情况下，读取操作可以在两种结构(主存储和增量存储)上执行，而写入操作仅影响增量存储。增量存储中收集的更改可以经由称为增量合并的过程移动到读取优化的主存储。
数据库可以在使用时按列将列表加载到主存储器中，这可以称为延迟加载(1azyloading)。从不使用的列可能永远不会加载到主存储器中，从而避免浪费。当表增长或临时计算需要更多存储器时，存储器管理器(操作系统)可以从存储器池151获得附加的存储器。当池151不能满足请求时，存储器管理器将通过从操作系统请求更多的存储器来增加池大小，直到达到预定义的分配限制。存储器是有限的资源。
一旦达到分配限制并且池耗尽，存储器管理器必须放弃存储的数据来创建可分配的存储器。在相关技术中，缓冲器和高速缓存可以被释放，并且列存储表可以基于最近最少使用的顺序逐列卸载。当表在几个主机上分区时，这是按照每个主机管理的。然而，“最近最少使用”的模型并没有说明交换的是哪种类型的数据。因此，当某些类型的数据被换出时，数据库的存储器性能可能遭受退化。
图2示出了根据示例实施例的多类别内存中架构200，并且图3示出了根据另一示例实施例的多类别内存中架构300。参考图2，诸如数据库应用的过程202可以经由操作系统210从池中查询一块存储器，并将页面放入被调用的池中。该池可以对应于存储在数据库的主存储器220内的多个池当中的池。每个池可以与不同类别的数据相关联。不同的分类可能决定操作系统是将数据交换到磁盘，还是将数据锁定到物理主存储器。
在图2的示例中，主存储器220被示为具有对应于两种不同数据类别的两个存储器池222和224。在该示例中，第一存储器池222对应于第一数据类别，并且第二存储器池224对应于第二数据类别。例如，对存储器性能更重要的数据，诸如MVCC数据、增量数据等，可以被分类在第一类别中，而其余的数据，诸如索引数据、字典数据、主数据等，可以被分类在第二类别中。根据各种实施例，操作系统210可以将存储在第一存储器池222中的所有数据锁定到主存储器220的物理存储器。同时，当操作系统210需要在主存储器220中腾出空间时，操作系统210可以从第二存储器池224中换出最近最少使用的数据。为了容纳存储器池222的锁定，操作系统210可以向第一存储器池222分配比分配给第二存储器池224更多的物理存储器。
数据库可以固有地为不同类型的数据实施数据池。例如，数据库可以具有用于增量数据的(多个)单独的存储器池、用于主数据的(多个)单独的存储器池等。数据库可以标志池，以指示池是否应该锁定到存储器中，或者池是否应该换出到磁盘中。例如，标志可以包括将池标记为锁定、交换等的标识符。在图2的示例中，第一存储器池222(更重要的)可以对应于增量数据池、MVCC数据等，而第二存储器池224(不太重要)可以对应于主数据。MVCC数据对数据库非常重要，因为每个查询都需要访问它(应该在尽可能快的存储器中)。同时，从数据监控中捕获的数据可能再也不会被访问，并且不需要在最快的存储器中，不管它是否是存储在存储器中的最近使用的数据。
什么被考虑是“重要的”可以由系统管理员、默认等来确定，并且可以对其进行修改。MVCC数据可以包括控制对数据库的并发访问的信息，以在多个用户试图查看、读取、写入相同数据时提供时间点(point-in-time)一致的视图。MVCC数据可以被标记为分配给第一存储器池222。增量数据可以包括存储在增量差分中的数据，与只能被读取的主数据相比，增量差分中数据能够被写入以及读取。增量数据可以被分配给第一存储器池222。其他类型的数据也可以分配给第一存储器池222，然而，这两种类型是出于示例的目的而描述的。同时，诸如字典数据、索引数据、高速缓存数据、缓冲数据等其他数据类型可以被分配给第二数据池224。在某些情况下，来自相同查询的数据可能分布在不同的池中。
在图2的示例中，存储在第一存储器池222中的数据被锁定到主存储器，而存储在第二存储器池224中的数据可以被换出到硬盘230。在争用的存储器(contentious memory)中，从磁盘230读取数据和向磁盘230换出数据几乎可以连续发生。数据可能非常频繁地去往磁盘230并从磁盘230返回。然而，访问磁盘230比访问存储在主存储器220中的数据慢几个数量级。因此，当操作系统210从磁盘230获取数据时，它将数据存储在被分类为第一池222和第二池224的存储器池之一中。然后，当操作系统210需要在主存储器220中腾出空间时，它将从第二池224而不是第一池222取出数据，而不管第一池222中的数据是否是最不频繁使用的数据。换句话说，操作系统210将被阻止调度存储在第一池222中的数据。
从数据库的主存储器中换出数据通常是基于LRU(最近最少使用)算法完成的。因此，当存储器空间已满且操作系统需要空间容纳新项目时，最旧的数据项将从主存储器中换出。然而，该方案(LRU)不考虑被换出的内容，而是简单地考虑数据的存储/访问时间。然而，大多数数据库已经将数据类型分配给不同的存储器池。示例实施例通过将这些数据池标记为锁定的或交换的来利用这些数据池，从而将存储器池分类为更重要和不太重要。基于多少个存储器类别，数据库可以具有对应数量的存储器池。
在高度争用的情况下，数据库需要明智地使用存储器。通过将存储器分配到正确的池中，系统可以通过更好的存储器速度/性能来实现整体性能提升。这种提升的原因是，被换出的页面只是那些系统所了解的最少使用的内容的页面，即使它们可能不是主存储器中最近使用的页面。数据库可以确保最重要的数据项保留在最高性能的存储器(主存储器)中。最重要的可能是从访问存储器频率的经验中确定的。一些存储器(诸如MVCC存储器、增量存储器等)总是被访问。然而，主存储器相关的东西并不重要，并且可以被交换。通常，第一次被推入主存储器的东西再也不会被访问。因此，即使它是较年轻的数据页面之一，也不需要保存在主存储器中。
分类也是可扩展的。在图2的示例中，有两个类别的数据和对应的存储器池，然而，在图3中，有三个类别的数据和三个对应的存储器池。还应该理解，可以使用多于三个类别的存储器池。在图3的示例中，第一存储器池322保持锁定在主存储器320内，而第二存储器池324和第三存储器池326被换出。在该示例中，部分交换空间(存储器池326)由硬盘340支持，而中间层数据(存储器324)由比硬盘更快的存储支持，例如固态磁盘(SSD)、非易失性存储器快速(NMVe)等。这里，每个池都可以被附加标志，以标识该池是换出到磁盘、换出到SSD/NVMe，还是锁定在主存储器中。
数据库软件可以具有关于不同块的存储器的相对重要性的详细知识级别。例如，可以开发数据库软件，以使其意识到移动以交换增量或MVCC相关的存储器和命中页面错误的成本远远高于交换与主数据相关的存储器(main related memory)的成本。大多数数据库软件已经转向使用存储器池，其中相关存储器是从相关存储器池中分配的。作为示例，主数据可以被分配给主存储器池，MVCC数据可以被分配给MVCC数据池，并且增量数据可以被分配给增量存储器池。在此示例中，数据库可以使用标记机制将MVCC和增量数据池标记为层1(锁定到主存储器)，并将(多个)主数据池标记为层2(可交换到磁盘等)。这允许数据库为高度争用的增量和MVCC数据结构分配锁定的存储器，而从支持常规交换的存储器分配主存储器。在高存储器争用的情况下，这导致比使用Linux存储器管理器更有效地利用有价值且有限的存储器资源。这个想法很容易扩展到两层以上的存储器和存储器池(诸如图4所示的示例)。该系统可以单独使用，也可以与缓冲管理器结合使用，以最有效地使用不同的存储器层，从而提供比默认情况更好的TCO。
图4示出了根据示例实施例的从内存中架构换出数据的过程400。参考图4，主存储器410包括三个存储器池412、414和416，它们已经用三个不同的锁定和交换参数进行了标志。特别地，存储器池412被锁定到主存储器410的物理存储器。此外，存储器池414被标记，使得它被交换到诸如SSD或NVMe 420的中速存储器。此外，存储器池416被标记，使得它被交换到磁盘430。
在该示例中，操作系统可以设置来自存储器池414的数据和来自存储器池416的数据之间的交换优先级。例如，来自存储器池414的数据可以首先从主存储器410换出，因为它被交换到比磁盘430更快的存储器(NVMe 420)。当操作系统已经填满NVMe 420时，操作系统然后可以从存储器池416交换到磁盘430。
在图4的示例中，最近最少使用的数据对象(例如，页面、块、表等)被标记为时间12，而最近使用的数据对象标记为时间1。也就是说，数据对象的使用顺序在时间1到时间12之间顺序列出，其中时间12是最近最少使用的。在传统的数据库系统中，操作系统会交换最近最少使用的数据对象(时间12)。然而，在该示例中，时间12的数据对象是存储在锁定到物理存储器的存储器池412内的增量数据对象。因此，数据对象(时间12)不会被交换。数据对象(时间11)也是如此，因为它存储在存储器池412中，所以也被锁定到主存储器。
存储器池414和存储器池416两者都可以以任何顺序被换出。例如，操作系统可以首先从存储器池414或首先从存储器池416换出数据。在该示例中，操作系统可以从存储器池414和416当中的存储器池416中换出最近最少使用的数据对象(时间10)，然后操作系统可以从存储器池414将数据对象402(时间8)换出到NVMe 420，然而，实施例不限于此。操作系统可以通过将数据对象从存储器池414换出到NVMe 420并将数据对象从存储器池416换出到磁盘430来继续为主存储器410腾出空间。
图5示出了根据示例实施例的基于数据的类别将数据分配给存储器的方法500。例如，方法500可以由数据库节点、云平台、服务器、计算系统(用户设备)、设备/节点的组合等来执行。参考图5，在510中，该方法可以包括接收将数据对象存储在数据库内的请求。例如，数据对象可以包括页面、块、表格等。该请求可以从过程、应用、操作系统等接收。
在520中，该方法可以包括基于数据对象的属性从多个类别类型当中确定与数据对象相关联的类别类型。此外，在530中，该方法可以包括经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储数据对象。根据各种实施例，主存储器可以包括与多个不同的锁定或交换特征相关联的多个存储器池。例如，一个存储器池(和其中分类的数据)可以被锁定到主存储器，而当需要主存储器空间时，至少一个其他存储器池(和其中分类的数据)可以被交换到磁盘。在该示例中，该方法可以包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
在一些实施例中，确定可以包括响应于数据对象与多版本并发控制(MVCC)数据、差分缓冲数据等相关联，确定数据对象的类别类型是第一类别类型。在一些实施例中，确定可以包括响应于数据对象包括来自磁盘的数据，确定数据对象的类别类型是第二类别类型。这里，第二类别类型的数据可以包括字典数据、高速缓存数据、缓冲数据、索引数据、列存储数据、行存储数据、系统数据等。此外，当需要主存储器空间时，该方法可以进一步包括将数据对象从第二存储器池换出到磁盘，而将其他数据对象保持在第一存储器池中，即使第一存储器池中的数据对象相对于来自第二存储器池的数据对象最近最少被使用。例如，第一存储器池可以固定到物理存储器，并且第二存储器池中的数据可以用虚拟存储器来管理，该虚拟存储器由比第一存储器池更少的物理存储器支持。
在所描述的示例中，多个类别可以对应于数据库可用性中的多个重要性级别。默认情况下，这些类别可以由系统操作员等来确定。存储器池是为各种类型的数据(诸如增量数据、主数据等)自然创建的。数据库可以标志这些存储器池，以指示存储在存储器池中的数据是应该被交换到磁盘还是锁定到主存储器而不被换出。在一些实施例中，类别可以包括分配给第三存储器池的至少第三类别，该第三存储器池被换出到非易失性存储器快速(NMVe)和固态磁盘(SSD)中的一个或多个。
图6示出了根据示例性实施例的可用于本文描述的任何方法和过程的计算系统600。例如，计算系统600可以是数据库节点、服务器、云平台等。在一些实施例中，计算系统600可以分布在多个计算设备上，诸如多个数据库节点。参考图6，计算系统600包括网络接口610、处理器620、输入/输出630和存储设备640，诸如内存中存储等。尽管在图6中未示出，但是计算系统600也可以包括或电连接到其他组件，诸如显示器、(多个)输入单元、接收器、发射器、永久磁盘等。处理器620可以控制计算系统600的其他组件。
网络接口610可以通过诸如互联网、专用网络、公共网络、企业网络等的网络发送和接收数据。网络接口610可以是无线接口、有线接口或其组合。处理器620可以包括一个或多个处理设备，每个处理设备包括一个或多个处理核心。在一些示例中，处理器620是多核处理器或多个多核处理器。此外，处理器620可以是固定的或者是可重新配置的。输入/输出630可以包括接口、端口、电缆、总线、板、线等，用于向计算系统600输入数据和从计算系统600输出数据。例如，数据可以输出到计算系统600的嵌入式显示器、外部连接的显示器、连接到云的显示器、另一设备等。网络接口610、输入/输出630、存储640或其组合可以与在其他设备上执行的应用交互。
存储设备640不限于特定的存储设备，并且可以包括任何已知的存储设备，诸如RAM、ROM、硬盘等，并且可以包括或不包括在数据库系统、云环境、web服务器等内。存储640可以存储软件模块或其他指令，处理器620可以执行这些软件模块或指令来执行图5所示的方法。根据各种实施例，存储640可以包括具有多个表、分区和子分区的数据存储。存储640可用于存储数据库记录、项目、条目等。
根据各种实施例，处理器620可以接收将数据对象存储在数据库内的请求。该请求可以从数据库的过程接收，该过程可以与应用程序、用户界面、服务器等相关联。处理器620可以基于数据对象的属性从多个类别类型当中确定与数据对象相关联的类别类型。例如，属性可以包括诸如MVCC、增量数据、主数据(索引、字典等)、高速缓存数据、缓冲数据等的数据的数据类型。存储640可以经由对应于多个相应类别的多个存储器池当中的对应于所确定类别的存储器池来存储数据对象。这里，存储640可以包括其中具有多个存储器池的主存储器。处理器620可以将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
例如，处理器620可以响应于数据对象包括MVCC数据、增量数据等，确定数据对象的类别类型是第一类别类型。作为另一示例，处理器620可以响应于数据对象包括来自磁盘的数据，诸如高速缓存数据、缓冲数据、字典数据、索引数据等，确定数据对象的类别类型是第二类别类型。在一些实施例中，处理器620可以将第二数据对象从第二存储器池换出到磁盘，而在第一存储器池中保留较旧的第三数据对象。作为另一示例，当第二存储器池(或第三存储器池)由诸如固态磁盘或NMVe的中速类型的存储器支持时，处理器620可以在将数据换出到磁盘之前将数据从第二或第三存储器池换出到中间存储器，这可以在从交换出的数据中取得数据时有助于数据库的性能。在这些示例中，第一存储器池可以被固定到物理存储器，并且第二存储器池中的数据由比第一存储器池更少的物理存储器支持的虚拟存储器来管理。
基于前述说明书将会理解，本公开的上述示例可以使用计算机编程或工程技术来实施，包括计算机软件、固件、硬件或其任意组合或子集。根据本公开的讨论示例，具有计算机可读代码的任何这样的结果程序可以在一个或多个非暂时性计算机可读介质中体现或提供，从而制造计算机程序产品，即制造物品。例如，非暂时性计算机可读介质可以是但不限于固定驱动器、软盘、光盘、磁带、闪存、外部驱动器、半导体存储器，诸如只读存储器(ROM)、随机存取存储器(RAM)和/或任何其他非暂时性发送和/或接收介质，诸如互联网、云存储、物联网(Intemet of Things，IoT)或其他通信网络或链路。包含计算机代码的制造物品可以通过直接从一种介质执行代码、将代码从一种介质复制到另一种介质或者通过网络传输代码来制造和/或使用。
计算机程序(也称为程序、软件、软件应用程序、“应用(app)”或代码)可以包括用于可编程处理器的机器指令，并且可以以高级过程和/或面向对象的编程语言和/或汇编/机器语言来实施。如本文所使用的，术语“机器可读介质”和“计算机可读介质”是指用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、装置、云存储、物联网和/或设备(例如，磁盘、光盘、存储器、可编程逻辑设备(programmable logic devic，PLD))，包括接收机器指令作为机器可读信号的机器可读介质。然而，“机器可读介质”和“计算机可读介质”不包括暂时信号。术语“机器可读信号”是指可用于向可编程处理器提供机器指令和/或任何其他种类的数据的任何信号。
本文的过程的上述描述和例示不应被考虑为暗示执行过程步骤的固定顺序。相反，过程步骤可以以任何可时间的顺序执行，包括同时执行至少一些步骤。尽管已经结合具体示例描述了本公开，但是应当理解，在不脱离所附权利要求中阐述的本公开的精神和范围的情况下，可以对所公开的实施例进行对本领域技术人员显而易见的各种更改、替换和变更。

Claims (20)

1.一种计算系统，包括：
处理器，被配置为接收将数据对象存储在数据库内的请求，并且基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和
存储，被配置为经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，
其中，所述处理器被配置为将第一类别类型的数据对象分配给锁定到所述存储中的主存储器的第一存储器池，并将第二类别类型的数据对象分配给所述存储中随时间被换出到磁盘的第二存储器池。
2.根据权利要求1所述的计算系统，其中，所述处理器被配置为响应于所述数据对象包括多版本并发控制(MVCC)数据，确定所述数据对象的类别类型是所述第一类别类型。
3.根据权利要求1所述的计算系统，其中，所述处理器被配置为响应于所述数据对象包括差分缓冲数据，确定所述数据对象的类别类型是所述第一类别类型。
4.根据权利要求1所述的计算系统，其中，所述处理器被配置为响应于所述数据对象包括来自磁盘的数据，确定所述数据对象的类别类型是所述第二类别类型。
5.根据权利要求1所述的计算系统，其中，所述处理器还被配置为将第二数据对象从所述第二存储器池换出到所述磁盘，而在所述第一存储器池中保留较旧的第三数据对象。
6.根据权利要求1所述的计算系统，其中，所述多个类别对应于数据库可用性的多个重要性级别。
7.根据权利要求1所述的计算系统，其中，所述处理器还被配置为将第三类别类型的数据对象分配给第三存储器池，所述第三存储器池被换出到非易失性存储器快速(NVMe)和固态磁盘(SSD)中的一个或多个。
8.根据权利要求1所述的计算系统，其中，所述第一存储器池中的数据被固定到物理存储器，并且所述第二存储器池中的数据用比所述第一存储器池更少的物理存储器支持的虚拟存储器来管理。
9.一种方法，包括：
接收将数据对象存储在数据库内的请求；
基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和
经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，其中，所述存储包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
10.根据权利要求9所述的方法，其中，所述确定包括响应于所述数据对象包括多版本并发控制(MVCC)数据，确定所述数据对象的类别类型是所述第一类别类型。
11.根据权利要求9所述的方法，其中，所述确定包括响应于所述数据对象包括差分缓冲数据，确定所述数据对象的类别类型是所述第一类别类型。
12.根据权利要求9所述的方法，其中，所述确定包括响应于所述数据对象包括来自磁盘的数据，确定所述数据对象的类别类型是第二类别类型。
13.根据权利要求9所述的方法，还包括将第二数据对象从所述第二存储器池换出到所述磁盘，而在所述第一存储器池中保持较旧的第三数据对象。
14.根据权利要求9所述的方法，其中，所述多个类别对应于数据库可用性的多个重要级别。
15.根据权利要求9所述的方法，其中，所述存储还包括将第三类别类型的数据对象分配给第三存储器池，所述第三存储器池被换出到非易失性存储器快速(NVMe)和固态磁盘(SSD)中的一个或多个。
16.根据权利要求9所述的方法，其中，所述第一存储器池中的数据被固定到物理存储器，并且所述第二存储器池中的数据用比所述第一存储器池更少的物理存储器支持的虚拟存储器来管理。
17.一种存储指令的非暂时性计算机可读介质，所述指令在被执行时使得计算机执行方法，所述方法包括：
接收将数据对象存储在数据库内的请求；
基于所述数据对象的属性，从多个类别类型当中确定与所述数据对象相关联的类别类型；和
经由对应于多个相应类别的多个存储器池当中的对应于所确定的类别的存储器池来存储所述数据对象，其中，所述存储包括将第一类别类型的数据对象分配给锁定到主存储器的第一存储器池，并将第二类别类型的数据对象分配给随时间被换出到磁盘的第二存储器池。
18.根据权利要求17所述的非暂时性计算机可读介质，其中，所述确定包括响应于所述数据对象包括多版本并发控制(MVCC)数据，确定所述数据对象的类别类型是第一类别类型。
19.根据权利要求17所述的非暂时性计算机可读介质，其中，所述确定包括响应于所述数据对象包括来自磁盘的数据，确定所述数据对象的类别类型是第二类别类型。
20.根据权利要求17所述的非暂时性计算机可读介质，其中，所述存储还包括将第三类别类型的数据对象分配给第三存储器池，所述第三存储器池被换出到非易失性存储器快速(NVMe)和固态磁盘(SSD)中的一个或多个。
CN201911291410.5A 2019-02-15 2019-12-13 基于分类的存储器分配的锁定 Pending CN111581123A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/277,250 US10877675B2 (en) 2019-02-15 2019-02-15 Locking based on categorical memory allocation
US16/277,250 2019-02-15

Publications (1)

Publication Number Publication Date
CN111581123A true CN111581123A (zh) 2020-08-25

Family

ID=69104212

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911291410.5A Pending CN111581123A (zh) 2019-02-15 2019-12-13 基于分类的存储器分配的锁定

Country Status (3)

Country Link
US (1) US10877675B2 (zh)
EP (1) EP3696688B1 (zh)
CN (1) CN111581123A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022213875A1 (zh) * 2021-04-08 2022-10-13 华为技术有限公司 一种内存扩展方法以及相关设备

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH045739A (ja) * 1990-04-24 1992-01-09 Toshiba Corp ディスク・キャッシュ制御方式
JPH08171515A (ja) * 1994-12-19 1996-07-02 Nec Corp ディスクキャッシュにおけるメモリ管理方式
US5680573A (en) * 1994-07-12 1997-10-21 Sybase, Inc. Method of buffering data objects in a database
US6763347B1 (en) * 2001-10-19 2004-07-13 Nick Zhang Indexing management for hierarchical main memory
US20060294304A1 (en) * 2005-06-24 2006-12-28 Research In Motion Limited System and method for managing memory in a mobile device
CN101114508A (zh) * 2006-07-25 2008-01-30 株式会社东芝 信息记录装置及其控制方法
CN101539841A (zh) * 2008-03-21 2009-09-23 株式会社日立制作所 高可用性以及低容量的动态存储区域分配
CN102209952A (zh) * 2009-02-20 2011-10-05 株式会社日立制作所 存储系统和用于操作存储系统的方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10108622B2 (en) * 2014-03-26 2018-10-23 International Business Machines Corporation Autonomic regulation of a volatile database table attribute
US10067969B2 (en) * 2015-05-29 2018-09-04 Nuodb, Inc. Table partitioning within distributed database systems
US10031853B2 (en) * 2016-09-15 2018-07-24 International Business Machines Corporation Unified in-memory cache

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH045739A (ja) * 1990-04-24 1992-01-09 Toshiba Corp ディスク・キャッシュ制御方式
US5680573A (en) * 1994-07-12 1997-10-21 Sybase, Inc. Method of buffering data objects in a database
JPH08171515A (ja) * 1994-12-19 1996-07-02 Nec Corp ディスクキャッシュにおけるメモリ管理方式
US6763347B1 (en) * 2001-10-19 2004-07-13 Nick Zhang Indexing management for hierarchical main memory
US20060294304A1 (en) * 2005-06-24 2006-12-28 Research In Motion Limited System and method for managing memory in a mobile device
CN101114508A (zh) * 2006-07-25 2008-01-30 株式会社东芝 信息记录装置及其控制方法
CN101539841A (zh) * 2008-03-21 2009-09-23 株式会社日立制作所 高可用性以及低容量的动态存储区域分配
CN102209952A (zh) * 2009-02-20 2011-10-05 株式会社日立制作所 存储系统和用于操作存储系统的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CARSTEN MEYER.ETC: "Dynamic and Transparent Data Tiering for InMemory Databases in Mixed Workload Environments", 《INTERNATIONAL WORKSHOP ON ACCELERATING DATA MANAGEMENT SYSTEMS USING MODERN PROCESSOR AND STORAGE ARCHITECTURES》, 31 August 2015 (2015-08-31), pages 1 - 11 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022213875A1 (zh) * 2021-04-08 2022-10-13 华为技术有限公司 一种内存扩展方法以及相关设备

Also Published As

Publication number Publication date
US20200264786A1 (en) 2020-08-20
US10877675B2 (en) 2020-12-29
EP3696688B1 (en) 2022-03-16
EP3696688A1 (en) 2020-08-19

Similar Documents

Publication Publication Date Title
US11288252B2 (en) Transactional key-value store
US9767131B2 (en) Hierarchical tablespace space management
JP7410181B2 (ja) ハイブリッド・インデックス作成方法、システム、プログラム
US11023453B2 (en) Hash index
US9779104B2 (en) Efficient database undo / redo logging
CN105630409B (zh) 使用存储器内阵列和盘上页结构的双重数据存储
CN106575297B (zh) 使用盲更新操作的高吞吐量数据修改
US10127260B2 (en) In-memory database system providing lockless read and write operations for OLAP and OLTP transactions
US20180011892A1 (en) Foster twin data structure
US9639542B2 (en) Dynamic mapping of extensible datasets to relational database schemas
US20170351543A1 (en) Heap data structure
US20170185645A1 (en) Database caching in a database system
US10521117B2 (en) Unified table delta dictionary memory size and load time optimization
US10248693B2 (en) Multi-layered row mapping data structure in a database system
US10289709B2 (en) Interleaved storage of dictionary blocks in a page chain
US11100083B2 (en) Read only bufferpool
US11714794B2 (en) Method and apparatus for reading data maintained in a tree data structure
EP3696688B1 (en) Locking based on categorical memory allocation
US20230068358A1 (en) Using self-maintaining structure information for faster data access
US10997164B2 (en) Unified table delta dictionary lazy materialization

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